Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1605839 > unrolled thread

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY() Cyrill Gorcunov <gorcunov@gmail.com> - 2017-03-21 18:30 +0100
    Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY() Andy Lutomirski <luto@amacapital.net> - 2017-03-21 18:50 +0100
      [Q] Figuring out task mode Cyrill Gorcunov <gorcunov@gmail.com> - 2017-03-21 19:10 +0100
        Re: [Q] Figuring out task mode Andy Lutomirski <luto@amacapital.net> - 2017-03-22 01:00 +0100
      Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY() Cyrill Gorcunov <gorcunov@gmail.com> - 2017-03-21 19:50 +0100
        Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY() hpa@zytor.com - 2017-03-21 20:00 +0100
          Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY() Cyrill Gorcunov <gorcunov@gmail.com> - 2017-03-21 20:20 +0100
            Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY() hpa@zytor.com - 2017-03-21 20:30 +0100
        Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY() Cyrill Gorcunov <gorcunov@gmail.com> - 2017-03-21 20:30 +0100
      Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY() hpa@zytor.com - 2017-03-21 20:00 +0100
      Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY() Andy Lutomirski <luto@amacapital.net> - 2017-03-21 20:40 +0100
        Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY() Cyrill Gorcunov <gorcunov@gmail.com> - 2017-03-21 20:40 +0100

#1605839 — Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On Tue, Mar 21, 2017 at 07:37:12PM +0300, Dmitry Safonov wrote:
...
> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
> index d6b784a5520d..d3d4d9abcaf8 100644
> --- a/arch/x86/kernel/process_64.c
> +++ b/arch/x86/kernel/process_64.c
> @@ -519,8 +519,14 @@ void set_personality_ia32(bool x32)
>  		if (current->mm)
>  			current->mm->context.ia32_compat = TIF_X32;
>  		current->personality &= ~READ_IMPLIES_EXEC;
> -		/* in_compat_syscall() uses the presence of the x32
> -		   syscall bit flag to determine compat status */
> +		/*
> +		 * in_compat_syscall() uses the presence of the x32
> +		 * syscall bit flag to determine compat status.
> +		 * On the bitness of syscall relies x86 mmap() code,
> +		 * so set x32 syscall bit right here to make
> +		 * in_compat_syscall() work during exec().
> +		 */
> +		task_pt_regs(current)->orig_ax |= __X32_SYSCALL_BIT;
>  		current->thread.status &= ~TS_COMPAT;

Hi! I must admit I didn't follow close the overall series (so can't
comment much here :) but I have a slightly unrelated question -- is
there a way to figure out if task is running in x32 mode say with
some ptrace or procfs sign?

[toc] | [next] | [standalone]

#1605857

On Tue, Mar 21, 2017 at 10:17 AM, Cyrill Gorcunov <gorcunov@gmail.com> wrote:
> On Tue, Mar 21, 2017 at 07:37:12PM +0300, Dmitry Safonov wrote:
> ...
>> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
>> index d6b784a5520d..d3d4d9abcaf8 100644
>> --- a/arch/x86/kernel/process_64.c
>> +++ b/arch/x86/kernel/process_64.c
>> @@ -519,8 +519,14 @@ void set_personality_ia32(bool x32)
>>               if (current->mm)
>>                       current->mm->context.ia32_compat = TIF_X32;
>>               current->personality &= ~READ_IMPLIES_EXEC;
>> -             /* in_compat_syscall() uses the presence of the x32
>> -                syscall bit flag to determine compat status */
>> +             /*
>> +              * in_compat_syscall() uses the presence of the x32
>> +              * syscall bit flag to determine compat status.
>> +              * On the bitness of syscall relies x86 mmap() code,
>> +              * so set x32 syscall bit right here to make
>> +              * in_compat_syscall() work during exec().
>> +              */
>> +             task_pt_regs(current)->orig_ax |= __X32_SYSCALL_BIT;
>>               current->thread.status &= ~TS_COMPAT;
>
> Hi! I must admit I didn't follow close the overall series (so can't
> comment much here :) but I have a slightly unrelated question -- is
> there a way to figure out if task is running in x32 mode say with
> some ptrace or procfs sign?

You should be able to figure out of a *syscall* is x32 by simply
looking at bit 30 in the syscall number.  (This is unlike i386, which
is currently not reflected in ptrace.)

Do we actually have an x32 per-task mode at all?  If so, maybe we can
just remove it on top of Dmitry's series.

[toc] | [prev] | [next] | [standalone]

#1605872 — [Q] Figuring out task mode

/I renamed the mail's subject/

On Tue, Mar 21, 2017 at 10:45:57AM -0700, Andy Lutomirski wrote:
> >> +             task_pt_regs(current)->orig_ax |= __X32_SYSCALL_BIT;
> >>               current->thread.status &= ~TS_COMPAT;
> >
> > Hi! I must admit I didn't follow close the overall series (so can't
> > comment much here :) but I have a slightly unrelated question -- is
> > there a way to figure out if task is running in x32 mode say with
> > some ptrace or procfs sign?
> 
> You should be able to figure out of a *syscall* is x32 by simply
> looking at bit 30 in the syscall number.  (This is unlike i386, which
> is currently not reflected in ptrace.)

Yes, syscall number will help but from criu perpspective (until
Dima's patches are merged into mainlie) we need to figure out
if we can dump x32 tasks without running parasite code inside,
ie via plain ptrace call or some procfs output. But looks like
it's impossible for now.

> Do we actually have an x32 per-task mode at all?  If so, maybe we can
> just remove it on top of Dmitry's series.

Don't think so, x32 should be set upon exec and without Dima's series
it is immutable I think.

[toc] | [prev] | [next] | [standalone]

#1606097 — Re: [Q] Figuring out task mode

On Tue, Mar 21, 2017 at 11:05 AM, Cyrill Gorcunov <gorcunov@gmail.com> wrote:
> /I renamed the mail's subject/
>
> On Tue, Mar 21, 2017 at 10:45:57AM -0700, Andy Lutomirski wrote:
>> >> +             task_pt_regs(current)->orig_ax |= __X32_SYSCALL_BIT;
>> >>               current->thread.status &= ~TS_COMPAT;
>> >
>> > Hi! I must admit I didn't follow close the overall series (so can't
>> > comment much here :) but I have a slightly unrelated question -- is
>> > there a way to figure out if task is running in x32 mode say with
>> > some ptrace or procfs sign?
>>
>> You should be able to figure out of a *syscall* is x32 by simply
>> looking at bit 30 in the syscall number.  (This is unlike i386, which
>> is currently not reflected in ptrace.)
>
> Yes, syscall number will help but from criu perpspective (until
> Dima's patches are merged into mainlie) we need to figure out
> if we can dump x32 tasks without running parasite code inside,
> ie via plain ptrace call or some procfs output. But looks like
> it's impossible for now.
>
>> Do we actually have an x32 per-task mode at all?  If so, maybe we can
>> just remove it on top of Dmitry's series.
>
> Don't think so, x32 should be set upon exec and without Dima's series
> it is immutable I think.

What I mean is: why should the kernel care about per-task X32 state
*at all*?  On top of Dmitry's series, TIF_X32 appears to be used to
determine which vDSO to map, which mm layout to use, *and nothing
else*.  Want to write a trivial patch to get rid of it entirely?

Ideally we could get rid of mm->context.ia32_compat, too.  The only
interesting use it has is MPX, and we should probably instead track
mm->context.mpx_layout and determine *that* from the prctl() bitness.

[toc] | [prev] | [next] | [standalone]

#1605902

On Tue, Mar 21, 2017 at 09:09:40PM +0300, Dmitry Safonov wrote:
> 
> I guess the question comes from that we're releasing CRIU 3.0 with
> 32-bit C/R and some other cool stuff, but we don't support x32 yet.
> As we don't want release a thing that we aren't properly testing.
> So for a while we should error on dumping x32 applications.

yes

> I think, the best way for now is to check physicall address of vdso
> from /proc/.../pagemap. If it's CONFIG_VDSO=n kernel, I guess we could
> also add check for %ds from ptrace's register set. For x32 it's set to
> __USER_DS, while for native it's 0 (looking at start_thread() and
> compat_start_thread()). The application can simply change it without
> any consequence - so it's not very reliable, we could only warn at
> catching it, not rely on this.

indeed, thanks!

[toc] | [prev] | [next] | [standalone]

#1605914

On March 21, 2017 11:40:58 AM PDT, Cyrill Gorcunov <gorcunov@gmail.com> wrote:
>On Tue, Mar 21, 2017 at 09:09:40PM +0300, Dmitry Safonov wrote:
>> 
>> I guess the question comes from that we're releasing CRIU 3.0 with
>> 32-bit C/R and some other cool stuff, but we don't support x32 yet.
>> As we don't want release a thing that we aren't properly testing.
>> So for a while we should error on dumping x32 applications.
>
>yes
>
>> I think, the best way for now is to check physicall address of vdso
>> from /proc/.../pagemap. If it's CONFIG_VDSO=n kernel, I guess we
>could
>> also add check for %ds from ptrace's register set. For x32 it's set
>to
>> __USER_DS, while for native it's 0 (looking at start_thread() and
>> compat_start_thread()). The application can simply change it without
>> any consequence - so it's not very reliable, we could only warn at
>> catching it, not rely on this.
>
>indeed, thanks!

I proposed to the ptrace people a virtual register for this and a few other things, but it got bikeshed to death.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[toc] | [prev] | [next] | [standalone]

#1605926

On Tue, Mar 21, 2017 at 11:51:09AM -0700, hpa@zytor.com wrote:
> >
> >indeed, thanks!
> 
> I proposed to the ptrace people a virtual register for this and a few other things, but it got bikeshed to death.

Any mail reference left? Would like to read it.

[toc] | [prev] | [next] | [standalone]

#1605936

On March 21, 2017 12:07:13 PM PDT, Cyrill Gorcunov <gorcunov@gmail.com> wrote:
>On Tue, Mar 21, 2017 at 11:51:09AM -0700, hpa@zytor.com wrote:
>> >
>> >indeed, thanks!
>> 
>> I proposed to the ptrace people a virtual register for this and a few
>other things, but it got bikeshed to death.
>
>Any mail reference left? Would like to read it.

Not sure...
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[toc] | [prev] | [next] | [standalone]

#1605935

On Tue, Mar 21, 2017 at 10:19:01PM +0300, Dmitry Safonov wrote:
> > 
> > indeed, thanks!
> 
> Also, even more simple-minded: for now we could just check binary magic
> from /proc/.../exe, for now stopping on x32 binaries.

File may not exist and elfheader wiped out as well.

[toc] | [prev] | [next] | [standalone]

#1605916

On March 21, 2017 10:45:57 AM PDT, Andy Lutomirski <luto@amacapital.net> wrote:
>On Tue, Mar 21, 2017 at 10:17 AM, Cyrill Gorcunov <gorcunov@gmail.com>
>wrote:
>> On Tue, Mar 21, 2017 at 07:37:12PM +0300, Dmitry Safonov wrote:
>> ...
>>> diff --git a/arch/x86/kernel/process_64.c
>b/arch/x86/kernel/process_64.c
>>> index d6b784a5520d..d3d4d9abcaf8 100644
>>> --- a/arch/x86/kernel/process_64.c
>>> +++ b/arch/x86/kernel/process_64.c
>>> @@ -519,8 +519,14 @@ void set_personality_ia32(bool x32)
>>>               if (current->mm)
>>>                       current->mm->context.ia32_compat = TIF_X32;
>>>               current->personality &= ~READ_IMPLIES_EXEC;
>>> -             /* in_compat_syscall() uses the presence of the x32
>>> -                syscall bit flag to determine compat status */
>>> +             /*
>>> +              * in_compat_syscall() uses the presence of the x32
>>> +              * syscall bit flag to determine compat status.
>>> +              * On the bitness of syscall relies x86 mmap() code,
>>> +              * so set x32 syscall bit right here to make
>>> +              * in_compat_syscall() work during exec().
>>> +              */
>>> +             task_pt_regs(current)->orig_ax |= __X32_SYSCALL_BIT;
>>>               current->thread.status &= ~TS_COMPAT;
>>
>> Hi! I must admit I didn't follow close the overall series (so can't
>> comment much here :) but I have a slightly unrelated question -- is
>> there a way to figure out if task is running in x32 mode say with
>> some ptrace or procfs sign?
>
>You should be able to figure out of a *syscall* is x32 by simply
>looking at bit 30 in the syscall number.  (This is unlike i386, which
>is currently not reflected in ptrace.)
>
>Do we actually have an x32 per-task mode at all?  If so, maybe we can
>just remove it on top of Dmitry's series.

We do, for things like signal delivery mostly.  We have tried relying on it as little as possible, intentionally.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[toc] | [prev] | [next] | [standalone]

#1605941

On Tue, Mar 21, 2017 at 11:09 AM, Dmitry Safonov <dsafonov@virtuozzo.com> wrote:
> On 03/21/2017 08:45 PM, Andy Lutomirski wrote:
>>
>> On Tue, Mar 21, 2017 at 10:17 AM, Cyrill Gorcunov <gorcunov@gmail.com>
>> wrote:
>>>
>>> On Tue, Mar 21, 2017 at 07:37:12PM +0300, Dmitry Safonov wrote:
>>> ...
>>>>
>>>> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
>>>> index d6b784a5520d..d3d4d9abcaf8 100644
>>>> --- a/arch/x86/kernel/process_64.c
>>>> +++ b/arch/x86/kernel/process_64.c
>>>> @@ -519,8 +519,14 @@ void set_personality_ia32(bool x32)
>>>>               if (current->mm)
>>>>                       current->mm->context.ia32_compat = TIF_X32;
>>>>               current->personality &= ~READ_IMPLIES_EXEC;
>>>> -             /* in_compat_syscall() uses the presence of the x32
>>>> -                syscall bit flag to determine compat status */
>>>> +             /*
>>>> +              * in_compat_syscall() uses the presence of the x32
>>>> +              * syscall bit flag to determine compat status.
>>>> +              * On the bitness of syscall relies x86 mmap() code,
>>>> +              * so set x32 syscall bit right here to make
>>>> +              * in_compat_syscall() work during exec().
>>>> +              */
>>>> +             task_pt_regs(current)->orig_ax |= __X32_SYSCALL_BIT;
>>>>               current->thread.status &= ~TS_COMPAT;
>>>
>>>
>>> Hi! I must admit I didn't follow close the overall series (so can't
>>> comment much here :) but I have a slightly unrelated question -- is
>>> there a way to figure out if task is running in x32 mode say with
>>> some ptrace or procfs sign?
>>
>>
>> You should be able to figure out of a *syscall* is x32 by simply
>> looking at bit 30 in the syscall number.  (This is unlike i386, which
>> is currently not reflected in ptrace.)
>
>
> The process could be stopped with PTRACE_SEIZE and I think, it'll not
> have x32 syscall bit at that moment.
>
> I guess the question comes from that we're releasing CRIU 3.0 with
> 32-bit C/R and some other cool stuff, but we don't support x32 yet.
> As we don't want release a thing that we aren't properly testing.
> So for a while we should error on dumping x32 applications.

I'm curious: shouldn't x32 CRIU just work?  What goes wrong?

--Andy

[toc] | [prev] | [next] | [standalone]

#1605942

On Tue, Mar 21, 2017 at 12:31:51PM -0700, Andy Lutomirski wrote:
...
> > I guess the question comes from that we're releasing CRIU 3.0 with
> > 32-bit C/R and some other cool stuff, but we don't support x32 yet.
> > As we don't want release a thing that we aren't properly testing.
> > So for a while we should error on dumping x32 applications.
> 
> I'm curious: shouldn't x32 CRIU just work?  What goes wrong?

Anything ;) We didn't tried as far as I know but i bet
somthing will be broken for sure.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web