linux-kernel - RE: [PATCH next] x86: mask_user_address() return base of guard page for kernel addresses

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: <728cccd6a6d942d0b9249e7991fdce13@AcuMS.aculab.com>
Date: Mon, 2 Dec 2024 08:43:50 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Linus Torvalds' <torvalds@...uxfoundation.org>
CC: "x86@...nel.org" <x86@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>, "Ingo
 Molnar" <mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
	"Andrew Cooper" <andrew.cooper3@...rix.com>, Josh Poimboeuf
	<jpoimboe@...nel.org>, "bp@...en8.de" <bp@...en8.de>
Subject: RE: [PATCH next] x86: mask_user_address() return base of guard page
 for kernel addresses

From: Linus Torvalds
> Sent: 01 December 2024 20:03
> 
> On Sun, 1 Dec 2024 at 10:12, David Laight <David.Laight@...lab.com> wrote:
> >
> > I've built and run a kernel with it - so not broken!
> 
> I worry that 'cmov' could be predicted - making the whole sequence
> pointless. It would be a stupid thing for a CPU core to do, but it
> would be simple.
> 
> Of course, 'sbb' could be done using predicting the carry flag too.
> There's a lot of ways to screw this up.

About the only register that it would make any sense to 'predict'
is the flags register.
That is going to affect cmov and sbb the same.

> Intel at some point explicitly said
> 
>  "Other instructions such as CMOVcc, AND, ADC, SBB and SETcc can also
> be used to prevent bounds
>   check bypass by constraining speculative execution on current family
> 6 processors (Intel® Core™,
>   Intel® Atom™, Intel® Xeon® and Intel® Xeon Phi™ processors).
> However, these instructions may not
>   be guaranteed to do so on future Intel processors"
> 
> so none of these are safe according to that.
> 
> Maybe there were newer updates on this, but in the meantime I'd rather
> have just *one* pattern, not switch between multiple possibly
> problematic ones. And sbb has been that traditional one.

I had some more thoughts while failing to sleep :-)

The current code relies on the cmp, sbb and or/and not being predicted.
This basically requires that all alu instructions not being predicted.
If that isn't true then pretty much any memory access could speculatively
access almost any memory address.

The 'may not be guaranteed' part might be because someone has mooted
the (probably brain-dead) idea of speculatively executing alu instructions
instead of implementing pipeline stalls.
Most alu forwarding (result to next instruction) and stalls can be
determined during the decode clocks (they affect the instruction
scheduling on current x86 cpu).
Perhaps it might help with variable length instructions (like memory reads)
but they are the very ones where you don't want to use wrong values from.

Mind you the hardware engineers have done other horrid things to increase
cpu clock speed to get some benchmarks run faster without considering the
full effect on other software - which is why we are in this mess.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)