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... > - Provides a simple mechanism to avoid RAM exfiltration during > traditional sleep/hibernate on a laptop or desktop when memory, > and thus secrets, are vulnerable to offline tampering or > inspection. This second use has nothing to do with RNGs, right? And I don't think we should do this in kernel. It is userspace that initiates the suspend transition. Userspace should lock the screen _before_ starting it, for example. Userspace should also get rid of any secrets, first... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
