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