linux-kernel - Re: [PING][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]

Date:   Tue, 14 Feb 2023 12:43:10 -0800
From:   "H. Peter Anvin" <hpa@...or.com>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>,
        Thomas Gleixner <tglx@...utronix.de>
CC:     Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Kees Cook <keescook@...omium.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PING][PATCH v3] x86: Use `get_random_u8' for kernel stack offset randomization

On February 13, 2023 8:54:53 PM PST, "Maciej W. Rozycki" <macro@...am.me.uk> wrote:
>On Mon, 13 Feb 2023, Thomas Gleixner wrote:
>
>> >> For x86 kernel stack offset randomization uses the RDTSC instruction, 
>> >> which according to H. Peter Anvin is not a secure source of entropy:
>> >> 
>> >> "RDTSC isn't a super fast instruction either, but what is *way* more
>> >> significant is that this use of RDTSC is NOT safe: in certain power states
>> >> it may very well be that stone number of lower bits of TSC contain no
>> >> entropy at all."
>> >
>> >  Ping for:
>> > <https://lore.kernel.org/all/alpine.DEB.2.21.2301302011150.55843@angie.orcam.me.uk/>.
>> 
>> I'm waiting for you to address Peter Anvins feedback.
>
> Do you mean this part:
>
>On Tue, 31 Jan 2023, H. Peter Anvin wrote:
>
>> Well, what I said was that masking out the low bits of TSC is not a valid use to
>> extract a random(-ish) number this way, because the lower bits may be affected
>> by quantization. Something like a circular multiply using a large prime with a
>> good 0:1 balance can be used to mitigate that.
>> 
>> However, the second part is that subsequent RDTSCs will be highly correlated,
>> and so a CSPRNG is needed if you are actually trying to get reasonable security
>> this way – and, well, we already have one of those.
>
>?  Well, I inferred, perhaps incorrectly, from the second paragraph that 
>Peter agrees with my approach (with the CSPRNG being what `get_random_u8' 
>and friends get at).
>
>> You also cite him
>> w/o providing a link to the conversation, so any context is missing.
>
> Sorry about that.  I put the change heading for the previous iterations 
>in the change log, but I agree actual web links would've been better:
><https://lore.kernel.org/all/alpine.DEB.2.21.2301081919550.65308@angie.orcam.me.uk/>,
><https://lore.kernel.org/all/alpine.DEB.2.21.2301082113350.65308@angie.orcam.me.uk/>.
>
> Please let me know if you need anything else.  Thank you for your review.
>
>  Maciej

No, I do indeed agree. We're talking something that is a part of an operation that is already fairly expensive. Now, if RDRAND is available on the hardware then that could be used if someone really wants it to go faster... but get_random_*() seems saner than doing ad hoc hacks.