linux-kernel - Re: [PATCH v16 4/5] random: introduce generic vDSO getrandom() implementation

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: <d3f7e1c5-5945-48c0-b263-e09979a987a3@infradead.org>
Date: Fri, 31 May 2024 12:15:16 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: "Jason A. Donenfeld" <Jason@...c4.com>, linux-kernel@...r.kernel.org,
 patches@...ts.linux.dev, tglx@...utronix.de
Cc: linux-crypto@...r.kernel.org, linux-api@...r.kernel.org, x86@...nel.org,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>,
 Carlos O'Donell <carlos@...hat.com>, Florian Weimer <fweimer@...hat.com>,
 Arnd Bergmann <arnd@...db.de>, Jann Horn <jannh@...gle.com>,
 Christian Brauner <brauner@...nel.org>,
 David Hildenbrand <dhildenb@...hat.com>
Subject: Re: [PATCH v16 4/5] random: introduce generic vDSO getrandom()
 implementation

On 5/28/24 5:19 AM, Jason A. Donenfeld wrote:
> +/**
> + * __cvdso_getrandom_data - Generic vDSO implementation of getrandom() syscall.
> + * @rng_info:		Describes state of kernel RNG, memory shared with kernel.
> + * @buffer:		Destination buffer to fill with random bytes.
> + * @len:		Size of @buffer in bytes.
> + * @flags:		Zero or more GRND_* flags.
> + * @opaque_state:	Pointer to an opaque state area.
> + *
> + * This implements a "fast key erasure" RNG using ChaCha20, in the same way that the kernel's
> + * getrandom() syscall does. It periodically reseeds its key from the kernel's RNG, at the same
> + * schedule that the kernel's RNG is reseeded. If the kernel's RNG is not ready, then this always
> + * calls into the syscall.
> + *
> + * @opaque_state *must* be allocated using the vgetrandom_alloc() syscall.  Unless external locking
> + * is used, one state must be allocated per thread, as it is not safe to call this function
> + * concurrently with the same @opaque_state. However, it is safe to call this using the same
> + * @opaque_state that is shared between main code and signal handling code, within the same thread.
> + *
> + * Returns the number of random bytes written to @buffer, or a negative value indicating an error.

    * Returns:

> + */

-- 
#Randy
https://people.kernel.org/tglx/notes-about-netiquette
https://subspace.kernel.org/etiquette.html