On 04.07.20 13:48, Pavel Machek wrote:
Hi!
Cryptographic libraries carry pseudo random number generators to
quickly provide randomness when needed. If such a random pool gets
cloned, secrets may get revealed, as the same random number may get
used multiple times. For fork, this was fixed using the WIPEONFORK
madvise flag [1].
Unfortunately, the same problem surfaces when a virtual machine gets
cloned. The existing flag does not help there. This patch introduces a
new flag to automatically clear memory contents on VM suspend/resume,
which will allow random number generators to reseed when virtual
machines get cloned.
Umm. If this is real problem, should kernel provide such rng in the
vsdo page using vsyscalls? Kernel can have special interface to its
vsyscalls, but we may not want to offer this functionality to rest of
userland...
And then the kernel would just need to maintain a sequence
number in the vDSO data page that gets bumped on suspen
Yes, something like that would work. Plus, we'd be free to change the
mechanism in future.
So if we keep treading along that train of thought, a simple vsyscall
that returns an epoch (incremented by every [VM] resume) would be good
enough, as user space could in its own logic determine whether it's
still living inside the same epoch.
The beauty of the clearing is that the checks on it are almost free and
that we can avoid to store secrets on disk in the first place.
The latter I think is impossible to model with the epoch, but that might
be ok.
Performance wise, I don't think we can make the vsyscall as cheap as a
memory compare. Keep in mind that we need to check for the epoch in a
pretty hot path. How bad would it really be? I'm not sure. It might be
good enough.
My main concern however is around fragmentation of mechanisms. We
already have the WIPEONFORK semantic in place in user space
applications. Do we really want to introduce yet another check for
what's almost the same semantic? With WIPEONSUSPEND, the hot path check
between fork and suspend are identical. With an epoch, we have to check
for zeros and the epoch in addition.
Unless we create a vsyscall that returns both the PID as well as the
epoch and thus handles fork *and* suspend. I need to think about this a
bit more :).
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
