Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [PATCH RFC v1] random: implement getrandom() in vDSO | Date | Mon, 01 Aug 2022 21:30:20 +0200 |
| |
Jason!
On Sun, Jul 31 2022 at 01:45, Jason A. Donenfeld wrote: > Thanks a bunch for chiming in. Indeed this whole thing is kind of crazy, > so your input is particularly useful here. > > On Sat, Jul 30, 2022 at 08:48:42AM -0700, Linus Torvalds wrote: >> It's just too specialized, and the people who care about performance >> can - and do - do special things anyway. > > To be clear, I really would rather not do this. I'm not really looking > for more stuff to do, and I don't tend to write (public) code "just > 'cuz". My worry is that by /not/ doing it, footguns will proliferate. > The glibc thing was what finally motivated me to want to at least sketch > out a potential action to make this kind of (apparently common) urge of > writing a userspace RNG safer.
But the user space tinkering will continue no matter what. They might then just use the vdso to get access to the ready/generation bits. I've seen "better" VDSO implementations to access time. :)
> So, anyway, if I do muster a v2 of this (perhaps just to see the idea > through), the API might split in two to something like: > > void *getrandom_allocate_states([inout] size_t *number_of_states, [out] size_t *length_per_state); > ssize_t getrandom(void *state, void *buffer, size_t len, unsigned long flags);
I'm not seeing any reason to have those functions at all.
The only thing which would be VDSO worthy here is the access to random_state->ready and random_state->generation as that's the information which is otherwise not available to userspace.
So you can just have:
int random_check_and_update_generation(u64 *generation);
Everything else is library material, really.
Thanks,
tglx
| |