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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <878ro6smmm.ffs@tglx>
Date:   Tue, 02 Aug 2022 17:14:57 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
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

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