linux-kernel - System call number masking

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-next>] [day] [month] [year] [list]

Message-ID: <1460654550.4560.9.camel@decadent.org.uk>
Date:	Thu, 14 Apr 2016 18:22:30 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Andy Lutomirski <luto@...nel.org>
Cc:	x86@...nel.org, LKML <linux-kernel@...r.kernel.org>
Subject: System call number masking

I'm updating my x32-as-boot-time-option patch for 4.6, and I noticed a
subtle change in system call number masking on x86_64 as a result of
moving the slow path into C.

Previously we would mask out the upper 32 bits before doing anything
with the system call number, both on the slow and fast paths, if and
only if x32 was enabled.

Now we always mask out the upper 32 bits on the slow path, so it's not
quite consistent with the fast path if x32 is disabled.  A system call
that would be rejected by the fast path can succeed on the slow path.
I don't know whether this causes any problems, but it seems
undesirable.

But it's also undesirable that the behaviour of system call numbers not
assigned to x32 also varies depending on whether x32 is enabled.
Should we always mask out the upper 32 bits on the fast path?

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of incompetence.

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)