linux-kernel - Re: [PATCH v3] x86: Use `get_random_u8' for kernel stack offset randomization

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2302140456360.6368@angie.orcam.me.uk>
Date:   Tue, 14 Feb 2023 05:12:29 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Thomas Gleixner <tglx@...utronix.de>,
        "Jason A. Donenfeld" <Jason@...c4.com>
cc:     Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Kees Cook <keescook@...omium.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] x86: Use `get_random_u8' for kernel stack offset
 randomization

On Mon, 13 Feb 2023, Thomas Gleixner wrote:

> On Mon, Jan 30 2023 at 21:30, Maciej W. Rozycki wrote:
> >
> > Therefore switch to our generic entropy source and use `get_random_u8' 
> > instead, which according to Jason A. Donenfeld is supposed to be fast 
> > enough:
> >
> > "Generally it's very very fast, as most cases wind up being only a
> > memcpy -- in this case, a single byte copy. So by and large it should
> > be suitable. It's fast enough now that most networking things are able
> > to use it. And lots of other places where you'd want really high
> > performance. So I'd expect it's okay to use here too. And if it is too
> > slow, we should figure out how to make it faster. But I don't suspect
> > it'll be too slow."
> 
> Please provide numbers on contemporary hardware.

 Jason, is this something you could help me with to back up your claim?  

 My access to modern x86 gear is limited and I just don't have anything I 
can randomly fiddle with (I guess an Intel Core 2 Duo T5600 processor back 
from 2008 doesn't count as "contemporary", does it?).

> Up to that point, it's easy enough to just disable that randomization on
> 32bit.

 I think for 32-bit we could just go with `get_random_u8' unconditionally, 
but if you'd rather I disabled the feature altogether such as in v1 or v2, 
then I'm happy to resubmit whichever version seems the best, or make yet a 
different one.  Please mind the security implications of RDTSC raised in 
the discussion though.  Thanks for your feedback.

  Maciej