Linux RNG RFC Patch: implement getrandom() in vDSO

This change makes me sad, not because it isn&#x27;t brilliant work - it is - but because this kind of brilliant work is unlikely to move the needle in the real-world. I can&#x27;t use this RNG because it isn&#x27;t FIPS validated. I can&#x27;t sponsor getting it FIPS validated because the cryptography it uses isn&#x27;t even FIPS compatible. It wouldn&#x27;t make it past the cursory skim of a reviewer. That says more about FIPS than it does this work, but it still means that it&#x27;s a non-starter for many libraries and applications that end up having US Federal Government users ... which is to say that basically everything important gets pushed away from benefiting from work like this.<p>Seperately, I&#x27;m also a little sad that there are no distinct RNGs for secret and non-secret output. It is an indispensable layer of defense to have separately seeded RNGs for these use-cases. That way if there is an implementation flaw or bug in the RNG that leads to re-use or predictability, it is vastly harder for that flaw to be abused. s2n, BouncyCastle, OpenSSL, and more user-space libraries use separately seeded RNGs for this reason and I don&#x27;t think I could justify removing that protection.

This looks like an excellent idea. I will implement support for it in my libc immediately when it&#x27;s available in a release kernel.<p>Currently userspace has incentive to roll their own RNG stuff. This removes that, which is good for everyone. The less incentive you give people to write code that has already been written by other, more experienced people, the better.<p>I would go even further and export the kernel ciphers via vDSO. Then user space could rely on those ciphers being optimized for the host CPU and side channel free instead of everybody bringing their own crypto primitives. I don&#x27;t think there is a good reason why gnupg and openssl would bring different crypto primitives.

For those who need it: vDSO is almost a hack that allows implementation of syscalls without context switch.

Making providing high-quality randomness without compromises a first-class OS feature seems like a great idea. Especially because it reduces the chances of using a bad&#x2F;incorrectly seeded&#x2F;inadequately seeded&#x2F;cloned from snapshot userspace cryptographic PRNG, and of using a non-cryptographic PRNG for cryptographic stuff.<p>I&#x27;m a kernel expert, so I don&#x27;t know if VDSO is the right implementation, but the idea seems sound. Make it harder for people to make mistakes that break security!

On many operating systems, including macOS and Windows, the only ABI-stable interface is a userland-to-userland interface. Application code loads a shared library vended by the system and calls functions from that library like open() or CreateFileW(), in userland. These functions are in turn are usually thin wrappers around system calls with equivalent argument lists – but not always, and even when they are, it&#x27;s only an implementation detail. Trying to call system calls directly without going through the wrappers risks incompatibility with future OS versions, e.g. [1].<p>On Linux, traditionally, the userland-kernel interface itself is ABI-stable. The userland code can be fully custom and doesn&#x27;t even need to support dynamic linking. Syscall numbers and arguments are fixed, and application code can perform its own syscall instructions. You can then layer something like glibc on top of that, which provides its own syscall wrapper functions with a corresponding stable (userland-to-userland) ABI, but that&#x27;s separate.<p>The vDSO has always been a step away from that. It&#x27;s userland code, automatically mapped by the kernel, that provides its own system call wrappers. Applications are still allowed to make system calls manually, but they&#x27;re encouraged to use the vDSO instead. Its original purpose was to allow certain functions such as gettimeofday() to be completed in userland rather than actually performing a syscall [2], but it&#x27;s been used for a few other things. It&#x27;s worked pretty well, but it does have the drawback that statically linked binaries no longer control all of the code in their address space. This, for instance, caused a problem with the Go runtime [3], which expected userland code to follow a certain stack discipline.<p>Anyway, this patch seems to me like a significant further step. Not just putting an RNG into the vDSO, which is more complicated than anything the vDSO currently does, but also essentially saying that you <i>must</i> use the vDSO&#x27;s RNG to be secure (to quote the RFC, &quot;userspace rolling its own RNG from a getrandom() seed is fraught&quot;), and explicitly choosing not to provide stable APIs for custom userland RNGs to access the same entropy information.<p>I don&#x27;t think that&#x27;s necessarily a bad thing. It&#x27;s not <i>that</i> complicated, and to me, macOS&#x27; and Windows&#x27; approach always seemed more sensible in the first place. But it&#x27;s a step worth noting.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;jart&#x2F;cosmopolitan&#x2F;issues&#x2F;426" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jart&#x2F;cosmopolitan&#x2F;issues&#x2F;426</a><p>[2] <a href="https:&#x2F;&#x2F;man7.org&#x2F;linux&#x2F;man-pages&#x2F;man7&#x2F;vdso.7.html" rel="nofollow">https:&#x2F;&#x2F;man7.org&#x2F;linux&#x2F;man-pages&#x2F;man7&#x2F;vdso.7.html</a><p>[3] <a href="https:&#x2F;&#x2F;marcan.st&#x2F;2017&#x2F;12&#x2F;debugging-an-evil-go-runtime-bug&#x2F;" rel="nofollow">https:&#x2F;&#x2F;marcan.st&#x2F;2017&#x2F;12&#x2F;debugging-an-evil-go-runtime-bug&#x2F;</a>

&gt; hyperspeed card shuffling<p>i think that&#x27;s mostly scientific computing where you want the ability to control the RNG and even intentionally use deterministic seeds for reproducibility.<p>i think if the kernel is going to provide secure random numbers (which seems like a good idea), it should be through a (new) specific system call that fails unless a hardware entropy facility is available. performance seems like a secondary goal, where the primary is ensuring that people are using the right thing to generate keys and such.

There is always the option to reseed userspace PRNG with with getrandom() regularly. This makes userspace PRNG safe and more versatile than getrandom().

Nowhere near an expert, but this seems like a bad idea?

Why not just have the kernel map a page containing random bytes, that it rewrites with newly seeded random bytes when needed? Then userspace CSPRNGs could use that as a basis for their own reseeding.