random: add fork_event sysctl for polling VM forks

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.

For example, the following snippet can be used to print a message every
time a VM forks, after the RNG has been reseeded:

  struct pollfd fd = { .fd = open("/proc/sys/kernel/random/fork_event", O_RDONLY)  };
  assert(fd.fd >= 0);
  for (;;) {
    assert(poll(&fd, 1, -1) > 0);
    puts("vm fork detected");
  }

Various programs and libraries that utilize cryptographic operations
depending on fresh randomness can invalidate old keys or take other
appropriate actions when receiving that event. While this is racier than
allowing userspace to mmap/vDSO the vmgenid itself, it's an incremental
step forward that's not as heavyweight.

Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Alexander Graf <graf@amazon.com>
Cc: Jann Horn <jannh@google.com>
Cc: Colm MacCarthaigh <colmmacc@amazon.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
 Documentation/admin-guide/sysctl/kernel.rst |  6 ++++--
 drivers/char/random.c                       | 21 +++++++++++++++++++++
 2 files changed, 25 insertions(+), 2 deletions(-)

Hey again,

On Wed, Apr 20, 2022 at 02:15:45AM +0200, Jason A. Donenfeld wrote:
> Hi Jann,
> 
> On Tue, Apr 19, 2022 at 9:45 PM Jann Horn <jannh@google.com> wrote:
> > AFAIK this also means that if you make an epoll watch for
> > /proc/sys/kernel/random/fork_event, and then call poll() *on the epoll
> > fd* for some reason, that will probably already consume the event; and
> > if you then try to actually receive the epoll event via epoll_wait(),
> > it'll already be gone (because epoll tries to re-poll the "ready"
> > files to figure out what state those files are at now). Similarly if
> > you try to create an epoll watch for an FD that already has an event
> > pending: Installing the watch will call the ->poll handler once,
> > resetting the file's state, and the following epoll_wait() will call
> > ->poll again and think the event is already gone. See the call paths
> > to vfs_poll() in fs/eventpoll.c.
> >
> > Maybe we don't care about such exotic usage, and are willing to accept
> > the UAPI inconsistency and slight epoll breakage of plumbing
> > edge-triggered polling through APIs designed for level-triggered
> > polling. IDK.
> 
> Hmm, I see. The thing is, this is _already_ what's done for
> domainname/hostname. It's how the sysctl poll handler was "designed".
> So our options here are:
> 
> a) Remove this quirky behavior from domainname/hostname and start
> over. This would potentially break userspace, but maybe nobody uses
> this? No idea, but sounds risky.
> 
> b) Apply this commit as-is, because it's using the API as the API was
> designed, and call it a day.
> 
> c) Apply this commit as-is, because it's using the API as the API was
> designed, and then later try to fix up the epoll behavior on this.
> 
> Of these, (a) seems like a non-starter. (c) is most appealing, but it
> sounds like it might not actually be possible?
> 
> Jason

I actually tried to verify your concern but didn't have success doing
so.

Both of these worked:

        int efd = epoll_create1(0);
        assert(efd >= 0);
        struct epoll_event event = {
                .data.fd = open("/proc/sys/kernel/random/fork_event", O_RDONLY)
        };
        assert(event.data.fd >= 0);
        assert(epoll_ctl(efd, EPOLL_CTL_ADD, event.data.fd, &event) == 0);
        for (;;) {
                assert(epoll_wait(efd, &event, 1, -1) == 1);
                puts("vm fork detected");
        }

And:

        int efd = epoll_create1(0);
        assert(efd >= 0);
        struct epoll_event event = {
                .data.fd = open("/proc/sys/kernel/random/fork_event", O_RDONLY)
        };
        assert(event.data.fd >= 0);
        assert(epoll_ctl(efd, EPOLL_CTL_ADD, event.data.fd, &event) == 0);
        for (;;) {
                assert(poll(&(struct pollfd){ .fd = efd, .events = POLLIN }, 1, -1) == 1);
                puts("vm fork detected");
        }

It also worked if I added EPOLLET to the epoll_event. It did not work if
I removed POLLIN from the pollfd event.

Maybe I'm missing some subtlety. But what exactly is broken? (Either
way, it doesn't change the (a) vs (c) calculus in my previous email.)

Jason

Hey Jann,

Ahh, gotcha, that makes sense. Either way, sounds like something to
fix in the sysctl proc API (option c) if possible...

Jason