linux-kernel - Re: [PATCH 2/2] random: add fork_event sysctl for polling VM forks

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]

Date:   Mon, 2 May 2022 17:40:02 +0200
From:   Lennart Poettering <mzxreary@...inter.de>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Theodore Ts'o <tytso@....edu>,
        Alexander Graf <graf@...zon.com>,
        Colm MacCarthaigh <colmmacc@...zon.com>,
        Torben Hansen <htorben@...zon.co.uk>,
        Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH 2/2] random: add fork_event sysctl for polling VM forks

On Mo, 02.05.22 16:06, Jason A. Donenfeld (Jason@...c4.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.

(Ideally that counter file would even be mmapable...)

does this file really belong below the `kernel.random` sysctl
hierarchy? shouldn't this rather be something like
/sys/kernel/vmclone_event or so?

Most people see sysctl as a place to tweak settings with. But this
sysctl you proposed here cannot be written, and (so far…) not even be
read! So it sounds like a weird thing to place into /proc/sys/.

Note that in userspace there's a whole infrastructure for managing
sysctls, but this one doesn't look like it would be managable at all
by userspace with these tools.

Lennart

--
Lennart Poettering, Berlin