Re: [PATCH] PM: notify of PM_POST_VMFORK events from vmgenid

[Rafael J. Wysocki]

On Tue, Mar 1, 2022 at 7:19 PM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
>
> Hi Rafael,
>
> On Tue, Mar 1, 2022 at 6:36 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
> >
> > On Tue, Mar 1, 2022 at 6:31 PM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
> > >
> > > There's an additional virtual power state that various crypto-oriented
> > > drivers may benefit from being notified of, such as WireGuard: right
> > > after a virtual machine has forked. In WireGuard's case, the PM notifier
> > > there that clears keys pre-suspend will be adjusted to also clear them
> > > post-vmfork. This trivial commit wires up the machinery for that change,
> > > which builds on the recently added vmgenid driver in the random.git
> > > tree.
> >
> > Well, what does power management have to do with WireGuard'?
>
> I guess a bit more background would be in order. If I post a v2 of
> this, I'll include that there. But for now:
>
> WireGuard has ephemeral session keys. They're not supposed to exist
> for longer than a few minutes for a crypto property called "forward
> secrecy". In order to ensure this, WireGuard currently registers a PM
> notifier that fires before suspend/hibernate, which memzeros the
> various keys. That's all well and fine and works.
>
> There's now another power-ish event that WireGuard also cares about:
> when a virtual machine has been forked. In this case, too, the
> reaction is the same - memzero the various keys, only for a different
> reason: rather than forward secrecy, the property we want here is that
> a key+nonce tuple is never used on more than one plaintext.
>
> The argument of this patchset is that VM forking is kind of like a
> power event, so why not re-use the same notifier for that.

IMV the problem with this approach is that WireGuard is not the only
user of PM (suspend/hibernate) notifiers and the other users of them
will have no idea about what to do with PM_POST_VMFORK which from
their perspective has nothing to do with suspend and/or hibernation.

> However, if you disagree, I could move ahead with a separate notification
> mechanism not involving the PM notifier.

Yes, please.