Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall

[Andy Lutomirski]

On Thu, May 2, 2019 at 8:09 AM Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
>
> * Andy Lutomirski <luto@xxxxxxxxxx> wrote:
>
> > Or we decide that calling get_random_bytes() is okay with IRQs off and
> > this all gets a bit simpler.
>
> BTW., before we go down this path any further, is the plan to bind this
> feature to a real CPU-RNG capability, i.e. to the RDRAND instruction,
> which excludes a significant group of x86 of CPUs?

It's kind of the opposite.  Elena benchmarked it, and RDRAND's
performance was truly awful here.

>
> Because calling tens of millions of system calls per second will deplete
> any non-CPU-RNG sources of entropy and will also starve all other users
> of random numbers, which might have a more legitimate need for
> randomness, such as the networking stack ...

There's no such thing as "starving" other users in this context.  The
current core RNG code uses a cryptographic RNG that has no limits on
the number of bytes extracted.  If you want the entropy-accounted
stuff, you can use /dev/random, which is separate.

> 8 gigabits/sec sounds good throughput in principle, if there's no
> scalability pathologies with that.

The latency is horrible.

>
> It would also be nice to know whether RDRAND does buffering *internally*,

Not in a useful way :(

> Any non-CPU source of randomness for system calls and plans to add
> several extra function calls to every x86 system call is crazy talk I
> believe...

I think that, in practice, the only real downside to enabling this
thing will be the jitter in syscall times. Although we could decide
that the benefit is a bit dubious and the whole thing isn't worth it.
But it will definitely be optional.