Hi Simo, On Tue, May 10, 2022 at 08:40:48PM -0400, Simo Sorce wrote: > At your request teleporting here the answer I gave on a different > thread, reinforced by some thinking. > > As a user space crypto library person I think the only reasonable > interface is something like a vDSO. > > Poll() interfaces are nice and all for system programs that have full > control of their event loop and do not have to react immediately to > this event, however crypto libraries do not have the luxury of > controlling the main loop of the application. > > Additionally crypto libraries really need to ensure the value they > return from their PRNG is fine, which means they do not return a value > if the vmgenid has changed before they can reseed, or there could be > catastrophic duplication of "random" values used in IVs or ECDSA > Signatures or ids/cookies or whatever. > > For crypto libraries it is much simpler to poll for this information > than using notifications of any kind given libraries are > generally not in full control of what the process does. > > This needs to be polled fast as well, because the whole point of > initializing a PRNG in the library is that asking /dev/urandom all the > time is too slow (due to context switches and syscall overhead), so > anything that would require a context switch in order to pull data from > the PRNG would not really fly. > > A vDSO or similar would allow to pull the vmgenid or whatever epoch > value in before generating the random numbers and then barrier-style > check that the value is still unchanged before returning the random > data to the caller. This will reduce the race condition (which simply > cannot be completely avoided) to a very unlikely event. It sounds like your library issue is somewhat similar to what Alex was talking about with regards to having a hard time using poll in s2n. I'm still waiting to hear if Amazon figured out some way that this is possible (with, e.g., a thread). But anyway, it seems like this is something library authors might hit. My proposal here is made with nonce reuse in mind, for things like session keys that use sequential nonces. A different issue is random nonces. For these, it seems like a call to getrandom() for each nonce is probably the best bet. But it sounds like you're interested in a userspace RNG, akin to OpenBSD's arc4random(3). I hope you saw these threads: - https://lore.kernel.org/lkml/YnA5CUJKvqmXJxf2@xxxxxxxxx/ - https://lore.kernel.org/lkml/Yh4+9+UpanJWAIyZ@xxxxxxxxx/ - https://lore.kernel.org/lkml/CAHmME9qHGSF8w3DoyCP+ud_N0MAJ5_8zsUWx=rxQB1mFnGcu9w@xxxxxxxxxxxxxx/ Each one of those touches on vDSO things quite a bit. Basically, the motivation for doing that is for making userspace RNGs safe and promoting their use with a variety of kernel enhancements to make that easy. And IF we are to ship a vDSO RNG, then certainly this vmgenid business should be exposed that way, over and above other mechanisms. It'd make the most sense...IF we're going to ship a vDSO RNG. So the question really is: should we ship a vDSO RNG? I could work on designing that right. But I'm a little bit skeptical generally of the whole userspace RNG concept. By and large they always turn out to be less safe and more complex than the kernel one. So if we're to go that way, I'd like to understand what the strongest arguments for it are. Jason
