On Fri, Jul 29, 2022 at 3:32 PM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
>
> Two statements:
>
> 1) Userspace wants faster cryptographically secure numbers of
> arbitrary size, big or small.
>
> 2) Userspace is currently unable to safely roll its own RNG with the
> same security profile as getrandom().
So I'm really not convinced that this kind of thing is something the
kernel should work that hard to help.
And that state allocation in particular looks very random in all the
wrong ways, with various "if I run out of resources I'll just do a
system call" things.
Which just makes me go "just do the system call".
People who are _that_ sensitive to performance can't use this anyway,
unless they know the exact rules of "ok, I only need X state buffers"
(ok, the buckets are probably the more real "sometimes it might fail"
thing). So they basically need to know about the implementation
details - even if it's only about that kind of "only a limited number
of states" thing.
Not to mention that I don't think your patch can work anyway, with
things like "cmpxchg()" not being something you can do in the vdso
because it might have the kernel instrumentation in it.
So this all smells really fragile to me, and honestly, unlike the vdso
things we _do_ have, I don't think I've ever seen getrandom() be a
huge deal performance-wise.
It's just too specialized, and the people who care about performance
can - and do - do special things anyway.
Your patch fundamentally seems to be about "make it easy to not have
to care, and still get high performance", but that's _such_ a small
use-case (the intersection between "don't care" and "really really
need high performance" would seem to be basically NIL).
Linus
