Message-ID: <1460654550.4560.9.camel@decadent.org.uk>
Subject: System call number masking
From: Ben Hutchings <ben@decadent.org.uk>
To: Andy Lutomirski <luto@kernel.org>
Cc: x86@kernel.org, LKML <linux-kernel@vger.kernel.org>
Date: Thu, 14 Apr 2016 18:22:30 +0100
Content-Type: multipart/signed; micalg="pgp-sha512";
	protocol="application/pgp-signature"; boundary="=-+GPiYEyKNUx2omFZwbQE"
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2036
Lines: 52


--=-+GPiYEyKNUx2omFZwbQE
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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. =C2=A0A 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.

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

--=-+GPiYEyKNUx2omFZwbQE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJXD9HWAAoJEOe/yOyVhhEJiooP/RpARsypGu7ahPtPZM9kCAge
OXElslDVkI+J723N++QPX3Q6VANECowUIPtp8FU2imrlmeV8o08ycoCz1qHz2zw8
BPkHjr8pAIVFRa1Hxp5VIupzEZGbTAMB+O6RgtjwZ71xMkIunGe+djbt54DPXFuo
LxBTyQyZ5OyKMiyFJWJDWw7z/CzEkCdyeQTfHErW8Ustz+rdLuMO3dyt4dTAR/NI
ErI7xn9QCKII5BOxYSjUGyUFwmcVz8Mi6YFU3SjellI8dpaQasv6wx1f91vu7Ojc
rJdgNei/5f8yXP55dXhmnAL3CcHiC1NUauSAwsfvXygUAocZQ3DLAOtNMmu+Zgkx
ozU94gMqp1Qts12FfGr1VYW46ilElitfuWW1XgdNm1JGfKdZEoqk8PETQI63nrCg
L7cBunTpDtLOJ86fNLhvlGowwIutaU4Jw/zQEmtnR+KFI99csVLDBx8S44yOVgER
L9vBFaz7Caoso3/6fwbtHsOYJGPBJSjQ1sbR0WISi3gwzDuBe2dZV85I9R2f65dq
oLJrihYxsiHhyHkCaYZt49pszNuzJ6BhLtc0ijtExVPsbV1bxj6jgai2XcZKKPol
POn3GQ5hxx+zjEvLIRLe4fNmumhVlNhQDuS7EbtasaqXcse8HqSGX1LlPEfwSlJS
iVcfjc73Ul9TdEhQoHff
=Urwp
-----END PGP SIGNATURE-----

--=-+GPiYEyKNUx2omFZwbQE--