linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Yann Droneaud" <ydroneaud@opteya.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: "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>,
	"H. Peter Anvin" <hpa@zytor.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>
Subject: Re: [RFC PATCH 0/4] random: a simple vDSO mechanism for reseeding userspace CSPRNGs
Date: Thu, 12 Jan 2023 19:55:34 +0000	[thread overview]
Message-ID: <ae35afa5b824dc76c5ded98efcabc117e6dd3d70@opteya.com> (raw)
In-Reply-To: <CAHmME9oXB8=jUz98tv6k1xS+ELaRmgartoT6go_1axhH1L-HJg@mail.gmail.com>

Hi

12 janvier 2023 à 18:07 "Jason A. Donenfeld" <Jason@zx2c4.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.

Regards.

-- 
Yann Droneaud
OPTEYA

  parent reply	other threads:[~2023-01-12 20:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-12 17:02 [RFC PATCH 0/4] random: a simple vDSO mechanism for reseeding userspace CSPRNGs Yann Droneaud
2023-01-12 17:02 ` [RFC PATCH 1/4] random: introduce getrandom() GRND_TIMESTAMP Yann Droneaud
2023-01-13  0:32   ` Peter Lafreniere
2023-01-12 17:02 ` [RFC PATCH 2/4] random: introduce generic vDSO getrandom(,, GRND_TIMESTAMP) fast path Yann Droneaud
2023-01-12 17:02 ` [RFC PATCH 3/4] x86: vdso: Wire up getrandom() vDSO implementation Yann Droneaud
2023-01-12 17:02 ` [RFC PATCH 4/4] testing: add a getrandom() GRND_TIMESTAMP vDSO demonstration/benchmark Yann Droneaud
2023-01-12 17:07 ` [RFC PATCH 0/4] random: a simple vDSO mechanism for reseeding userspace CSPRNGs Jason A. Donenfeld
2023-01-12 19:55 ` Yann Droneaud [this message]
2023-01-14  2:22   ` H. Peter Anvin
2023-01-16 19:49     ` Andy Lutomirski
2023-01-17  8:35       ` H. Peter Anvin
2023-01-19 11:19     ` Yann Droneaud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae35afa5b824dc76c5ded98efcabc117e6dd3d70@opteya.com \
    --to=ydroneaud@opteya.com \
    --cc=Jason@zx2c4.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=bp@alien8.de \
    --cc=carlos@redhat.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=fweimer@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tytso@mit.edu \
    --cc=vincenzo.frascino@arm.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).