MIME-Version: 1.0
References: <alpine.DEB.2.21.2301302011150.55843@angie.orcam.me.uk>
 <874jrptmk9.ffs@tglx> <alpine.DEB.2.21.2302140456360.6368@angie.orcam.me.uk>
In-Reply-To: <alpine.DEB.2.21.2302140456360.6368@angie.orcam.me.uk>
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Tue, 14 Feb 2023 14:39:41 +0100
Message-ID: <CAHmME9r2pF-ncO5Mb7FbgW_1S_0ZrqgG-7TNa5hxieHk_8j90g@mail.gmail.com>
Subject: Re: [PATCH v3] x86: Use `get_random_u8' for kernel stack offset randomization
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>,
        Kees Cook <keescook@chromium.org>, x86@kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Feb 14, 2023 at 6:12 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> 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?).

I imagine tglx wants real life performance numbers rather than a
microbench of the rng. So the thing to do would be to exercise
arch_exit_to_user_mode() a bunch. Does this trigger on every syscall,
even invalid ones? If so, you could make a test like:

    #include <sys/syscall.h>
    #include <unistd.h>

    int main(int argc, char *argv[])
    {
     for (int i = 0; i < (1 << 26); ++i)
      syscall(0xffffffff);
     return 0;
    }

And then see if the timing changes across your patch.

Jason