linux-kernel - Re: [RFC PATCH 0/4] random: a simple vDSO mechanism for reseeding userspace CSPRNGs

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]

Date:   Fri, 13 Jan 2023 18:22:26 -0800
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Yann Droneaud <ydroneaud@...eya.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     "Theodore Ts'o" <tytso@....edu>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Vincenzo Frascino <vincenzo.frascino@....com>, x86@...nel.org,
        linux-crypto@...r.kernel.org, linux-api@...r.kernel.org,
        linux-kernel@...r.kernel.org, Florian Weimer <fweimer@...hat.com>,
        Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>,
        "Carlos O'Donell" <carlos@...hat.com>
Subject: Re: [RFC PATCH 0/4] random: a simple vDSO mechanism for reseeding
 userspace CSPRNGs

On 1/12/23 11:55, Yann Droneaud wrote:
> Hi
> 
> 12 janvier 2023 à 18:07 "Jason A. Donenfeld" <Jason@...c4.com> a écrit:
>   
>> 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_TIMESTAMP):
>   -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 start,
> providing room for implementing improved behavior in future kernel versions.
> 
>> 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.
> 

Why would anything more than a 64-bit counter be ever necessary? It only 
needs to be incremented.

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 multiple libraries to step on each other.

Export the cookie from the vdso and volià, a very cheap check around any 
user space randomness buffer will work:

	static clone_cookie_t last_cookie;
	clone_cookie_t this_cookie;

	this_cookie = get_clone_cookie();
	do {
		while (this_cookie != last_cookie) {
			last_cookie = this_cookie;
			reinit_randomness();
			this_cookie = get_clone_cookie();
		}

		extract_randomness_from_buffer();
		this_cookie = get_clone_cookie();
	} while (this_cookie != last_cookie);

	last_cookie = this_cookie;

	-hpa