Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Linus Torvalds <torvalds@linux-foundation.org>
Cc:     linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
        x86@kernel.org, Nadia Heninger <nadiah@cs.ucsd.edu>,
        Thomas Ristenpart <ristenpart@cornell.edu>,
        Theodore Ts'o <tytso@mit.edu>,
        Vincenzo Frascino <vincenzo.frascino@arm.com>,
        Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
        Florian Weimer <fweimer@redhat.com>
Subject: Re: [PATCH RFC v1] random: implement getrandom() in vDSO
In-Reply-To: <YuXCpyULk6jFgGV5@zx2c4.com>
References: <20220729145525.1729066-1-Jason@zx2c4.com>
 <CAHk-=wiLwz=9h9LD1-_yb1+T+u59a2EjTmMvCiGj4A-ZsPN1wA@mail.gmail.com>
 <YuXCpyULk6jFgGV5@zx2c4.com>
Date:   Mon, 01 Aug 2022 21:30:20 +0200
Message-ID: <87zggnsqwj.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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