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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 17 Apr 2016 22:45:24 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Ben Hutchings <ben@...adent.org.uk>,
	Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the
 fast path

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.

	-hpa