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

[Thomas Gleixner <tglx@linutronix.de>]

On Tue, Aug 02 2022 at 15:59, Jason A. Donenfeld wrote:
> On Tue, Aug 02, 2022 at 03:46:27PM +0200, Thomas Gleixner wrote:
>> Right now the Linux VDSO functions are 1:1 replacements for system calls
>> and not adding a magic pile of functionality which is otherwise not
>> available.
>> 
>> What you are proposing is to have an implementation which is not
>> available via a regular syscall. Which means you are creating a VDSO
>> only syscall which still has the same problem as any other syscall in
>> terms of API design and functionality which needs to be supported
>> forever.
>
> Wait, what? That's not correct. The WHOLE point is that vdso getrandom()
> will generate bytes in the same way as the ordinary syscall, without
> differences. Same function name, same algorithm. But just faster,
> because vDSO. I explicitly don't want to dip into introducing something
> different. That's the big selling point: that vDSO getrandom() and
> syscall getrandom() are the same thing. If you trust one, you can trust
> the other. If you expect properties of one, you get that from the other.
> If you know the API of one, you can use the other.

Seriously no. All existing VDSO functions have exactly the same function
signature and semantics as their syscall counterparts. So they are drop
in equivalent.

But:

  ssize_t getrandom(void *, void *, size_t, unsigned int);

is very much different than

  ssize_t getrandom(void *, size_t, unsigned int);

Different signature and different semantics.

So you have to go through the whole process of a new ABI whether you
like it or not.

It does not matter whether they both produce random numbers. If your
argument would hold true, then you can also claim that openat(2) and
openat2(2) are the same thing because they both open a file.

Thanks,

        tglx