Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <alpine.DEB.2.21.2301082113350.65308@angie.orcam.me.uk>
 <Y72CByxvewQv78YH@zx2c4.com> <alpine.DEB.2.21.2301120129020.65308@angie.orcam.me.uk>
In-Reply-To: <alpine.DEB.2.21.2301120129020.65308@angie.orcam.me.uk>
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Fri, 13 Jan 2023 16:33:52 +0100
Message-ID: <CAHmME9p9emE9WXBJyxCuCF64GqTPKqhMEJO9kpts-OdE8_2=pg@mail.gmail.com>
Subject: Re: [PATCH v2] x86: Disable kernel stack offset randomization for !TSC
To:     "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Maciej,

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