Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the fast path

[Andy Lutomirski]

On Sun, Apr 17, 2016 at 10:21 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> On 04/17/16 22:18, Andy Lutomirski wrote:
>> On Sun, Apr 17, 2016 at 9:50 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>>> On 04/17/16 17:47, Ben Hutchings wrote:
>>>> We've always masked off the top 32 bits when x32 is enabled, but
>>>> hopefully no-one relies on that.  Now that the slow path is in C, we
>>>> check all the bits there, regardless of whether x32 is enabled.  Let's
>>>> make the fast path consistent with it.
>>>
>>> We have always masked off the top 32 bits *period*.
>>>
>>> We have had some bugs where we haven't, because someone has tried to
>>> "optimize" the code and they have been quite serious.  The system call
>>> number is an int, which means the upper 32 bits are undefined on call
>>> entry: we HAVE to mask them.
>>
>> I'm reasonably confident that normal kernels (non-x32) have not masked
>> those bits since before I started hacking on the entry code.
>>
>
> I'm reasonably confident they have, because we have had security bugs
> TWICE when someone has tried to "optimize" the code.  The masking was
> generally done with a movl instruction, which confused people.
>
>> So the type of the syscall nr is a bit confused.  If there was an
>> installed base of programs that leaved garbage in the high bits, we
>> would have noticed *years* ago.  On the other hand, the 32-bit ptrace
>> ABI and the seccomp ABI both think it's 32-bits.
>
> Incorrect.  We have seen these failures in real life.

What kind of failure?  Programs that accidentally set rax to
0xbaadf00d00000003 get -ENOSYS in most cases, not close().  If we'd
broken programs like this, I assume we would have had to fix it a long
time ago.

>
>> If we were designing the x86_64 ABI and everything around it from
>> scratch, I'd suggest that that either the high bits must be zero or
>> that the number actually be 64 bits (which are more or less the same
>> thing).  That would let us use the high bits for something interesting
>> in the future.
>
> Not really all that useful.  What we have is a C ABI.

And we've already stolen a bit once for x32.  Maybe we'll want more.
For example, if we added a cancellable bit, if x86_32 didn't want it,
we could steal a high bit for ie.

>
>> In practice, we can probably still declare that the thing is a 64-bit
>> number, given that most kernels in the wild currently fail syscalls
>> that have the high bits set.
>
> They don't, and we can prove it...

I'm confused.

  asm volatile ("syscall" :
                "=a" (ret) :
                "a" (SYS_getpid | 0xbaadf00d00000000ULL) :
                "memory", "cc", "rcx", "r11");

gets -ENOSYS on the kernel I'm running on my laptop and on Fedora 23's
stock kernel.

I'm not terribly worried about nasty security issues in here because
all the nasty stuff is in C now.

What kernel had the other behavior?  In 2.6.11, I see:

ENTRY(system_call)
        CFI_STARTPROC
        swapgs
        movq    %rsp,%gs:pda_oldrsp
        movq    %gs:pda_kernelstack,%rsp
        sti
        SAVE_ARGS 8,1
        movq  %rax,ORIG_RAX-ARGOFFSET(%rsp)
        movq  %rcx,RIP-ARGOFFSET(%rsp)
        GET_THREAD_INFO(%rcx)
        testl $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT),threadinfo_flags(%rcx)
        jnz tracesys
        cmpq $__NR_syscall_max,%rax

--Andy