From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Sender: linus971@gmail.com In-Reply-To: References: <151586744180.5820.13215059696964205856.stgit@dwillia2-desk3.amr.corp.intel.com> <151586748981.5820.14559543798744763404.stgit@dwillia2-desk3.amr.corp.intel.com> From: Linus Torvalds Date: Tue, 16 Jan 2018 14:41:35 -0800 Message-ID: Content-Type: multipart/alternative; boundary="94eb2c05fbaeeed4530562ec6edd" Subject: [kernel-hardening] Re: [PATCH v3 8/9] x86: use __uaccess_begin_nospec and ASM_IFENCE in get_user paths To: Dan Williams Cc: Linux Kernel Mailing List , linux-arch@vger.kernel.org, Andi Kleen , Kees Cook , kernel-hardening@lists.openwall.com, Greg Kroah-Hartman , the arch/x86 maintainers , Ingo Molnar , Al Viro , "H. Peter Anvin" , Thomas Gleixner , Andrew Morton , Alan Cox List-ID: --94eb2c05fbaeeed4530562ec6edd Content-Type: text/plain; charset="UTF-8" On Jan 16, 2018 14:23, "Dan Williams" wrote: That said, for get_user specifically, can we do something even cheaper. Dave H. reminds me that any valid user pointer that gets past the address limit check will have the high bit clear. So instead of calculating a mask, just unconditionally clear the high bit. It seems worse case userspace can speculatively leak something that's already in its address space. That's not at all true. The address may be a kernel address. That's the whole point of 'set_fs()'. That's why we compare against the address limit variable, not against some constant number. Linus --94eb2c05fbaeeed4530562ec6edd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Jan 16, 2018 14:23, "Dan Williams" <dan.j.williams@intel.com> wrote:

That said, for get_user specifically, can we do something even
cheaper. Dave H. reminds me that any valid user pointer that gets past
the address limit check will have the high bit clear. So instead of
calculating a mask, just unconditionally clear the high bit. It seems
worse case userspace can speculatively leak something that's already in its address space.
<= br>
That's not at all true.

The address may be a kernel address. That= 9;s the whole point of 'set_fs()'.

That's why we compare against the address limit vari= able, not against some constant number.

=C2=A0 =C2=A0 =C2=A0Linus
--94eb2c05fbaeeed4530562ec6edd--