From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Lennart Poettering <mzxreary@0pointer.de>
Cc: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
Dominik Brodowski <linux@dominikbrodowski.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Theodore Ts'o <tytso@mit.edu>, Alexander Graf <graf@amazon.com>,
Colm MacCarthaigh <colmmacc@amazon.com>,
Torben Hansen <htorben@amazon.co.uk>,
Jann Horn <jannh@google.com>
Subject: Re: [PATCH 2/2] random: add fork_event sysctl for polling VM forks
Date: Mon, 2 May 2022 18:12:03 +0200 [thread overview]
Message-ID: <YnAC00VtU8MGb7vO@zx2c4.com> (raw)
In-Reply-To: <Ym/7UlgQ5VjjC76P@gardel-login>
On Mon, May 02, 2022 at 05:40:02PM +0200, Lennart Poettering wrote:
> On Mo, 02.05.22 16:06, Jason A. Donenfeld (Jason@zx2c4.com) wrote:
>
> > In order to inform userspace of virtual machine forks, this commit adds
> > a "fork_event" sysctl, which does not return any data, but allows
> > userspace processes to poll() on it for notification of VM forks.
> >
> > It avoids exposing the actual vmgenid from the hypervisor to userspace,
> > in case there is any randomness value in keeping it secret. Rather,
> > userspace is expected to simply use getrandom() if it wants a fresh
> > value.
>
> Wouldn't it make sense to expose a monotonic 64bit counter of detected
> VM forks since boot through read()? It might be interesting to know
> for userspace how many forks it missed the fork events for. Moreover it
> might be interesting to userspace to know if any fork happened so far
> *at* *all*, by checking if the counter is non-zero.
"Might be interesting" is different from "definitely useful". I'm not
going to add this without a clear use case. This feature is pretty
narrowly scoped in its objectives right now, and I intend to keep it
that way if possible. (And yes, I realize that is likely considerably
different from your development philosophy.)
>
> (Ideally that counter file would even be mmapable...)
You missed the last year of discussion about this and why we have wound
up here as a first step. Check the archives for extensive discussion.
Jason
next prev parent reply other threads:[~2022-05-02 16:12 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-02 14:06 [PATCH 1/2] sysctl: read() must consume poll events, not poll() Jason A. Donenfeld
2022-05-02 14:06 ` [PATCH 2/2] random: add fork_event sysctl for polling VM forks Jason A. Donenfeld
2022-05-02 15:40 ` Lennart Poettering
2022-05-02 16:12 ` Jason A. Donenfeld [this message]
2022-05-02 16:51 ` Lennart Poettering
2022-05-02 17:59 ` Alexander Graf
2022-05-02 18:29 ` Jason A. Donenfeld
2022-05-02 18:57 ` Alexander Graf
2022-05-02 20:03 ` Jason A. Donenfeld
2022-05-03 8:29 ` Lennart Poettering
2022-05-03 11:55 ` Jason A. Donenfeld
2022-05-03 12:33 ` Lennart Poettering
2022-05-02 18:04 ` Jason A. Donenfeld
2022-05-02 18:34 ` Alexander Graf
2022-05-02 18:46 ` Jason A. Donenfeld
2022-05-02 18:56 ` Alexander Graf
2022-05-02 19:27 ` Jason A. Donenfeld
2022-05-02 19:41 ` Alexander Graf
2022-05-04 15:45 ` Michael Kelley (LINUX)
2022-05-02 18:44 ` Jason A. Donenfeld
2022-05-03 7:42 ` Lennart Poettering
2022-05-03 9:08 ` Jason A. Donenfeld
2022-05-03 9:32 ` Lennart Poettering
2022-05-03 10:07 ` Jason A. Donenfeld
2022-05-03 12:42 ` Lennart Poettering
2022-05-11 0:40 ` Simo Sorce
2022-05-11 1:18 ` Jason A. Donenfeld
2022-05-11 12:59 ` Simo Sorce
2022-05-11 13:19 ` Alexander Graf
2022-05-11 13:19 ` Jason A. Donenfeld
2022-05-11 14:32 ` Simo Sorce
2022-05-11 13:20 ` Alexander Graf
2022-05-02 15:30 ` [PATCH 1/2] sysctl: read() must consume poll events, not poll() Jason A. Donenfeld
2022-05-02 15:43 ` Lennart Poettering
2022-05-03 11:27 ` Jason A. Donenfeld
2022-05-12 17:40 ` Luis Chamberlain
2022-05-12 18:29 ` Eric W. Biederman
2022-05-12 18:32 ` Jason A. Donenfeld
2022-05-12 18:22 ` Lucas De Marchi
2022-05-12 18:27 ` Jason A. Donenfeld
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=YnAC00VtU8MGb7vO@zx2c4.com \
--to=jason@zx2c4.com \
--cc=colmmacc@amazon.com \
--cc=graf@amazon.com \
--cc=gregkh@linuxfoundation.org \
--cc=htorben@amazon.co.uk \
--cc=jannh@google.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=mzxreary@0pointer.de \
--cc=tytso@mit.edu \
/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.