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: <87zggmqo0w.ffs@tglx>
Date:   Wed, 03 Aug 2022 00:27:43 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        X86 ML <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

Jason!

On Tue, Aug 02 2022 at 17:26, Jason A. Donenfeld wrote:
> On Tue, Aug 2, 2022 at 5:14 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>> Seriously no.
>
> Why so serious all at once? :-)

Because you triggered the 'now it gets serious' button with your "it's
the same" sentiment.

>> 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.
>
> Different signature, but basically the same semantics.

Not at all. The concept of 'basically same semantics' is a delusion. It
does not exist. Either it's the same or it's not.

I really want to see your reaction on a claim that some RNG
implementation is basically the same as the existing one. I'm sure you
buy that without complaints.

>> So you have to go through the whole process of a new ABI whether you
>> like it or not.
>
> Ahh, in that sense. Yea, I'd rather not have to do that too, with the
> additional opaque handle passed as the first argument. It'd be nice if
> there were some private place where I could store the necessary state,
> but I'm not really sure where that might be at the moment. If you have
> any ideas, please let me know.

That's exactly the problem. VDSO is a stateless syscall wrapper which
has to be self contained for obvious reasons.

My previous statement:

    Everything else is library material, really.

is based on that fact and not on the unwillingness to add magic muck to
the VDSO.

The unwillingness part is just the question:

    Is there a sensible usecase?

Assumed that there is a sensible usecase, there is a way out and that's
exactly the library part. You can make that VDSO interface versioned and
provide a library in tools/random/ which goes in lockstep with the VDSO
changes.

If the RNG tinkerers abuse that, then so be it. You can't do anything
about it whatever you try. They can abuse your magic vdso functionality
too.

That's very much the same as we have with e.g. perf. The old perf binary
still works, but it does not have access to the latest and greatest
features.

You can do very much the same in a kernel supplied helper library which
either can cope with the version change or falls back to
sys_getrandom().

Vs. the storage problem. That yells TLS, but that makes your process
wide sharing moot, which might not be the worst of all things IMO.

Thanks,

        tglx