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

[Jason A. Donenfeld]

Hi Maciej,

On Thu, Jan 12, 2023 at 2:34 AM Maciej W. Rozycki <macro@xxxxxxxxxxx> 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