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]

Message-ID: <57146ECA.5000901@zytor.com>
Date:	Sun, 17 Apr 2016 22:21:14 -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:18, Andy Lutomirski wrote:
> On Sun, Apr 17, 2016 at 9:50 PM, H. Peter Anvin <hpa@...or.com> 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.

> 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.

> 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...

	-hpa