linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lennart Poettering <mzxreary@0pointer.de>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
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: Tue, 3 May 2022 11:32:26 +0200	[thread overview]
Message-ID: <YnD2qu8eVn5ix5H7@gardel-login> (raw)
In-Reply-To: <YnDxK/O2E6LUhP/2@zx2c4.com>

On Di, 03.05.22 11:08, Jason A. Donenfeld (Jason@zx2c4.com) wrote:

> Hey Lennart,
>
> On Tue, May 03, 2022 at 09:42:40AM +0200, Lennart Poettering wrote:
> > For this MAC address usecase it's entirely sufficient to be able to
> > distinguish if the system was closed at all, i.e. if the counter is
> > zero or is non-zero. Because that would already be great for a policy
> > of "hash it in a stable way from /etc/machine-id, if counter == 0" +
> > "use random MAC once counter > 0".
>
> Hm, are you sure that's actually what you want? It turns out this
> vmgenid notification from the hypervisor might not be sufficiently
> granular for this use case:
>
> - vmgenid changes when you fork a new snapshot, so now you have two VMs
> - vmgenid also changes when you rewind to 2 minutes ago
>
> The first is what I assume you care about for this networkd business.
> The second is probably not what any networkd user expects.

So first of all, it appears to me that rewinding a VM is something people
would do for debugging things, i.e. not how things are done on
deployment.

> >From the perspective of randomness, both of these events imply the same
> thing. The situation is BAD; reseed immediately. From the perspective of
> MAC addresses, though, these events would imply different behavior,
> right? So it seems like vmgenid might need an additional field for this
> use case. Relatedly, VMware has that prompt where you select about your
> VM whether, "I moved it" or "I copied it." Presumably something like
> that would play a part in what is decided as part of this hypothetical
> second field.

networkd doesn't change MAC addresses in the middle of everything, but
only when a network interface is downed and upped again. This for
example happens when a link beat goes away and comes back. In the
rewind-2min case i'd assume the link beat would probably be restored
to what it was 2min ago (and thus stay online), but in the clone case
it would probably drop momentarily and be restored than, to tell
software to reacquire dhcp and so on.

or in other words: if the hypervisor wants the system to
reconfigure/reacquire its network there are explicit ways already, and
they work afaics. what's missing tehre is simply a reasonable way to
ensure that we won't end up sticking to the same fixed MAC address
when we set things up in order to acquire a new DHCP lease.

So I am not too concerned.

Lennart

--
Lennart Poettering, Berlin

  reply	other threads:[~2022-05-03  9:32 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
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 [this message]
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=YnD2qu8eVn5ix5H7@gardel-login \
    --to=mzxreary@0pointer.de \
    --cc=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=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 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).