Re: [PATCH RFC v1] random: implement getrandom() in vDSO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux