linux-kernel - Re: propagating vmgenid outward and upward

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yh5fbe71BTT6xc8h@kroah.com>
Date:   Tue, 1 Mar 2022 19:01:17 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        qemu-devel@...gnu.org, linux-hyperv@...r.kernel.org,
        linux-crypto@...r.kernel.org, graf@...zon.com,
        mikelley@...rosoft.com, adrian@...ity.io, lersek@...hat.com,
        berrange@...hat.com, linux@...inikbrodowski.net, jannh@...gle.com,
        mst@...hat.com, rafael@...nel.org, len.brown@...el.com,
        pavel@....cz, linux-pm@...r.kernel.org, colmmacc@...zon.com,
        tytso@....edu, arnd@...db.de
Subject: Re: propagating vmgenid outward and upward

On Tue, Mar 01, 2022 at 04:42:47PM +0100, Jason A. Donenfeld wrote:
> The easy way, and the way that I think I prefer, would be to just have a
> sync notifier_block for this, just like we have with
> register_pm_notifier(). From my perspective, it'd be simplest to just
> piggy back on the already existing PM notifier with an extra event,
> PM_POST_VMFORK, which would join the existing set of 7, following
> PM_POST_RESTORE. I think that'd be coherent. However, if the PM people
> don't want to play ball, we could always come up with our own
> notifier_block. But I don't see the need. Plus, WireGuard *already*
> uses the PM notifier for clearing keys, so code-wise for my use case,
> that'd amount adding another case for PM_POST_VMFORK, in addition to the
> currently existing PM_HIBERNATION_PREPARE and PM_SUSPEND_PREPARE cases,
> which all would be treated the same way. Ezpz. So if that sounds like an
> interesting thing to the PM people, I think I'd like to propose a patch
> for that, possibly even for 5.18, given that it'd be very straight-
> forward.

A notifier block like this makes sense, but why tie onto the PM_ stuff?
This isn't power management issues, it's a system-wide change that I am
sure others will want to know about that doesn't reflect any power
changes.

As much as I hate adding new notifiers in the kernel, that might be all
you need here.

thanks,

greg k-h