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

[Jason A. Donenfeld]

On Tue, Mar 1, 2022 at 7:50 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>
> 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.

Will do. Sorry for the noise.