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:45 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> On 04/17/16 22:39, Andy Lutomirski wrote:
>>>
>>> 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.
>>
>
> I think we're worrying about the wrong thing here... we skipped bit 31
> to avoid signedness issues, and with bit 30 for x32 we now "only" have
> 20 bits that haven't been used for anything at all.
>
>>>
>>>> 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
>>
>
> I can't remember what versions.  What I do know is that this was a bug
> which was introduced, fixed, re-introduced, and fixed again, and both
> resulted in CVEs.  The fact that you're seeing the cmpq indicates that
> it at least was not one of the security-buggy kernels.
>
> I do agree we should make the behavior consistent, and follow the
> documented behavior of treating the syscall argument as an int.
>

I think I prefer the "reject weird input" behavior over the "accept
and normalize weird input" if we can get away with it, and I'm fairly
confident that we can get away with "reject weird input" given that
distro kernels do exactly that already.

So I like Ben's patch.

--Andy

>         -hpa
>
>



-- 
Andy Lutomirski
AMA Capital Management, LLC