All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
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>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH RFC v2] random: implement getrandom() in vDSO
Date: Mon, 01 Aug 2022 10:48:01 +0200	[thread overview]
Message-ID: <871qu0qri6.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20220731013125.2103601-1-Jason@zx2c4.com> (Jason A. Donenfeld's message of "Sun, 31 Jul 2022 03:31:25 +0200")

* Jason A. Donenfeld:

> API-wise, vDSO getrandom has a pair of functions:
>
>   ssize_t getrandom(void *state, void *buffer, size_t len, unsigned int flags);
>   void *getrandom_alloc([inout] size_t *num, [out] size_t *size_per_each);
>
> In the first function, the return value and the latter 3 arguments are
> the same as ordinary getrandom(), while the first argument is a pointer
> to some state allocated with getrandom_alloc(). getrandom_alloc() takes
> the desired number of states, and returns an array of states, the number
> actually allocated, and the size in bytes of each one, enabling a libc
> to use one per thread. We very intentionally do *not* leave state
> allocation up to the caller. There are too many weird things that can go
> wrong, and it's important that vDSO does not provide too generic of a
> mechanism. It's not going to store its state in just any old memory
> address. It'll do it only in ones it allocates.

I still don't see why this couldn't be per-thread state (if you handle
fork generations somehow).

I also think it makes sense to introduce batching for the system call
implementation first, and tie that to the vDSO acceleration.  I expect a
large part of the benefit comes from the batching, not the system call
avoidance.

Thanks,
Florian


  reply	other threads:[~2022-08-01  8:48 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-29 14:55 [PATCH RFC v1] random: implement getrandom() in vDSO Jason A. Donenfeld
2022-07-29 20:19 ` Florian Weimer
2022-07-29 22:06   ` Jason A. Donenfeld
2022-07-30 15:48 ` Linus Torvalds
2022-07-30 23:45   ` Jason A. Donenfeld
2022-07-31  0:23     ` Jason A. Donenfeld
2022-07-31  1:31       ` [PATCH RFC v2] " Jason A. Donenfeld
2022-08-01  8:48         ` Florian Weimer [this message]
2022-08-01 12:49           ` Jason A. Donenfeld
2022-08-01 13:29             ` Jason A. Donenfeld
2022-08-01 13:00         ` Jason A. Donenfeld
2022-08-01 20:48         ` Thomas Gleixner
2022-08-01 23:41           ` Jason A. Donenfeld
2022-08-02  0:12             ` Jason A. Donenfeld
2022-08-01 19:30     ` [PATCH RFC v1] " Thomas Gleixner
2022-08-01 23:16       ` Jason A. Donenfeld
2022-08-02 13:46         ` Thomas Gleixner
2022-08-02 13:59           ` Jason A. Donenfeld
2022-08-02 15:14             ` Thomas Gleixner
2022-08-02 15:26               ` Jason A. Donenfeld
2022-08-02 22:27                 ` Thomas Gleixner
2022-08-04 15:23                   ` Jason A. Donenfeld
2022-08-04 16:08                     ` Jeffrey Walton
2022-08-04 23:11                     ` Thomas Gleixner
2022-08-17  8:20                   ` Peter Zijlstra
2022-08-05  8:36               ` Florian Weimer

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=871qu0qri6.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=Jason@zx2c4.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nadiah@cs.ucsd.edu \
    --cc=ristenpart@cornell.edu \
    --cc=torvalds@linux-foundation.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.