Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver
From: Colm MacCarthaigh
Date: Sat Oct 17 2020 - 23:15:23 EST
On 17 Oct 2020, at 6:24, Jason A. Donenfeld wrote:
There are a few design goals of notifying userspace: it should be
fast, because people who are using userspace RNGs are usually doing so
in the first place to completely avoid syscall overhead for whatever
high performance application they have - e.g. I recall conversations
with Colm about his TLS implementation needing to make random IVs
_really_ fast.
That’s our old friend TLS1.1 in CBC mode, which needs a random
explicit IV for every record sent. Speed is still a reason at the
margins in cases like that, but getrandom() is really fast. A stickier
problem is that getrandom() is not certified for use with every
compliance standard, and those often dictate precise use of some NIST
DRBG or NRBG construction. That keeps people proliferating user-space
RNGs even when speed isn’t as important.
It should also happen as early as possible, with no
race or as minimal as possible race window, so that userspace doesn't
begin using old randomness and then switch over after the damage is
already done.
+1 to this, and I’d add that anyone making VM snapshots that they plan
to restore from multiple times really needs to think this through top to
bottom. The system would likely need to be put in to some kind of
quiescent state when the snapshot is taken.
So, anyway, here are a few options with some pros and cons for the
kernel notifying userspace that its RNG should reseed.
1. SIGRND - a new signal. Lol.
2. Userspace opens a file descriptor that it can epoll on. Pros are
that many notification mechanisms already use this. Cons is that this
requires syscall and might be more racy than we want. Another con is
that this a new thing for userspace programs to do.
A library like OpenSSL or BoringSSL also has to account for running
inside a chroot, which also makes this hard.
Any thoughts on 4c? Is that utterly insane, or does that actually get
us somewhere close to what we want?
I still like 4c, and as a user-space crypto-person, and a VM person,
they have a lot of appeal. Alex and Adrian’s replies get into some of
the sufficiency challenge. But for user-space libraries like the *SSLs,
the JVMs, and other runtimes where RNGs show up, it could plug in easily
enough.
-
Colm