linux-kernel - Re: [PATCH v2] x86: Disable kernel stack offset randomization for !TSC

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: <CAHmME9p9emE9WXBJyxCuCF64GqTPKqhMEJO9kpts-OdE8_2=pg@mail.gmail.com>
Date:   Fri, 13 Jan 2023 16:33:52 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] x86: Disable kernel stack offset randomization for !TSC

Hi Maciej,

On Thu, Jan 12, 2023 at 2:34 AM Maciej W. Rozycki <macro@...am.me.uk> wrote:
>
> On Tue, 10 Jan 2023, Jason A. Donenfeld wrote:
>
> > > Index: linux-macro/arch/x86/include/asm/entry-common.h
> > > ===================================================================
> > > --- linux-macro.orig/arch/x86/include/asm/entry-common.h
> > > +++ linux-macro/arch/x86/include/asm/entry-common.h
> > > @@ -5,6 +5,7 @@
> > >  #include <linux/randomize_kstack.h>
> > >  #include <linux/user-return-notifier.h>
> > >
> > > +#include <asm/cpufeature.h>
> > >  #include <asm/nospec-branch.h>
> > >  #include <asm/io_bitmap.h>
> > >  #include <asm/fpu/api.h>
> > > @@ -85,7 +86,8 @@ static inline void arch_exit_to_user_mod
> > >      * Therefore, final stack offset entropy will be 5 (x86_64) or
> > >      * 6 (ia32) bits.
> > >      */
> > > -   choose_random_kstack_offset(rdtsc() & 0xFF);
> > > +   if (cpu_feature_enabled(X86_FEATURE_TSC))
> > > +           choose_random_kstack_offset(rdtsc() & 0xFF);
> >
> > What would happen if you just called `get_random_u8()` here?
>
>  Thank you for your input.  I've had a look at the function and it seems a
> bit heavyweight compared to a mere single CPU instruction, but I guess why
> not.  Do you have any performance figures (in terms of CPU cycles) for the
> usual cases?  Offhand I'm not sure how I could benchmark it myself.

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.

Resist calls to use RDRAND directly (it's much much slower, and not
universally available) or to roll your own opencoded bespoke RNG.

Jason