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;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [RFC PATCH 0/4] random: a simple vDSO mechanism for reseeding userspace CSPRNGs
Date:   Mon, 16 Jan 2023 11:49:42 -0800
Message-Id: <15F7D57C-8CC6-4CAE-8B7E-6F480B5F4133@amacapital.net>
References: <585ddb35-adc5-f5cf-4db3-27571f394108@zytor.com>
Cc:     Yann Droneaud <ydroneaud@opteya.com>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Theodore Ts'o <tytso@mit.edu>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Vincenzo Frascino <vincenzo.frascino@arm.com>, x86@kernel.org,
        linux-crypto@vger.kernel.org, linux-api@vger.kernel.org,
        linux-kernel@vger.kernel.org, Florian Weimer <fweimer@redhat.com>,
        Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
        Carlos O'Donell <carlos@redhat.com>
In-Reply-To: <585ddb35-adc5-f5cf-4db3-27571f394108@zytor.com>
To:     "H. Peter Anvin" <hpa@zytor.com>
Precedence: bulk


> On Jan 13, 2023, at 7:16 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>=20
> =EF=BB=BFOn 1/12/23 11:55, Yann Droneaud wrote:
>> Hi
>> 12 janvier 2023 =C3=A0 18:07 "Jason A. Donenfeld" <Jason@zx2c4.com> a =C3=
=A9crit:
>> =20
>>> Sorry Yann, but I'm not interested in this approach, and I don't think
>>> reviewing the details of it are a good allocation of time. I don't
>>> want to lock the kernel into having specific reseeding semantics that
>>> are a contract with userspace, which is what this approach does.
>> This patch adds a mean for the kernel to tell userspace: between the
>> last time you call us with getrandom(timestamp,, GRND_TIMESTAMP),
>> something happened that trigger an update to the opaque cookie given
>> to getrandom(timestamp, GRND_TIMESTAMP). When such update happen,
>> userspace is advised to discard buffered random data and retry.
>> The meaning of the timestamp cookie is up to the kernel, and can be
>> changed anytime. Userspace is not expected to read the content of this
>> blob. Userspace only acts on the length returned by getrandom(,, GRND_TIM=
ESTAMP):
>>  -1 : not supported
>>   0 : cookie not updated, no need to discard buffered data
>>  >0 : cookie updated, userspace should discard buffered data
>> For the cookie, I've used a single u64, but two u64 could be a better sta=
rt,
>> providing room for implementing improved behavior in future kernel versio=
ns.
>>> Please just let me iterate on my original patchset for a little bit,
>>> without adding more junk to the already overly large conversation.
>> I like the simplicity of my so called "junk". It's streamlined, doesn't
>> require a new syscall, doesn't require a new copy of ChaCha20 code.
>> I'm sorry it doesn't fit your expectations.
>=20
> Why would anything more than a 64-bit counter be ever necessary? It only n=
eeds to be incremented.

This is completely broken with CRIU or, for that matter, with VM forking.

>=20
> Let user space manage keeping track of the cookie matching its own buffers=
. You do NOT want this to be stateful, because that's just begging for multi=
ple libraries to step on each other.
>=20
> Export the cookie from the vdso and voli=C3=A0, a very cheap check around a=
ny user space randomness buffer will work:
>=20
>    static clone_cookie_t last_cookie;
>    clone_cookie_t this_cookie;
>=20
>    this_cookie =3D get_clone_cookie();
>    do {
>        while (this_cookie !=3D last_cookie) {
>            last_cookie =3D this_cookie;
>            reinit_randomness();
>            this_cookie =3D get_clone_cookie();
>        }
>=20
>        extract_randomness_from_buffer();
>        this_cookie =3D get_clone_cookie();
>    } while (this_cookie !=3D last_cookie);
>=20
>    last_cookie =3D this_cookie;
>=20
>    -hpa