[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YuktqQS7Rb0IbJNh@zx2c4.com>
Date: Tue, 2 Aug 2022 15:59:05 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
x86@...nel.org, Nadia Heninger <nadiah@...ucsd.edu>,
Thomas Ristenpart <ristenpart@...nell.edu>,
Theodore Ts'o <tytso@....edu>,
Vincenzo Frascino <vincenzo.frascino@....com>,
Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>,
Florian Weimer <fweimer@...hat.com>
Subject: Re: [PATCH RFC v1] random: implement getrandom() in vDSO
Hi Thomas,
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.
There might be other valid objections to this whole thing, but "this is
different from the syscall" really isn't one of them. It's the same
ideaspace that motivated gettimeofday() and such.
Jason
Powered by blists - more mailing lists