The Quest For Faster getrandom() Performance Continues Two Years Later
Going back just under two years was the propsal for adding getrandom() to the vDSO in the quest to achieve faster performance for obtaining random numbers in user-space. That effort while seemingly simple remains an ongoing and contentious matter.
Jason Donenfeld known for his work on WireGuard continues to pursue getrandom() in the vDSO among other Linux RNG improvements. This effort is aimed at providing faster cryptographically secure random numbers to user-space and the inability for user-space to roll its own RNG with the same security guarantees as the kernel's getrandom(). When recently sending out the v16 patches for getrandom() in the vDSO, Donenfeld summed up the status as:
It's great to see there is light at the end of the tunnel and optimistically may even land for the upcoming Linux 6.11 cycle. The updated patches have been going through review and discussion.
As recently as three days ago the patches were updated in random.git's vdso branch. Here's to hoping this patch series for helping with faster getrandom() performance may be ready to go for the Linux 6.11 kernel after being in the works the past two years.
Jason Donenfeld known for his work on WireGuard continues to pursue getrandom() in the vDSO among other Linux RNG improvements. This effort is aimed at providing faster cryptographically secure random numbers to user-space and the inability for user-space to roll its own RNG with the same security guarantees as the kernel's getrandom(). When recently sending out the v16 patches for getrandom() in the vDSO, Donenfeld summed up the status as:
"This is back after a bit of a hiatus. In the last attempt to do this in the beginning of 2023, I think we reached consensus on a few things -- the use case, the vDSO implementation and semantics, its integration with libc, the test code and documentation, and so forth. It was basically "ready to go". Almost. But there was a lingering issue that bogged this down, which is that it demanded some new mm semantics that weren't very popular.
In particular, the series from last year made use of the x86 instruction decoder to just skip over faulting instructions. I still think this is nifty, but it's not actually essential for the semantics needed, and I can understand why this was by far the largest objection. So all of that is dropped, which simplifies quite a bit.
In another avenue of the mm discussion, Andy had mentioned using _install_special_mapping() instead of the VM_DROPPABLE work, and I spent a long while looking into this, and attempted several times to code up a working implementation that used that. But the semantics really just weren't possible without adding hooks to lots of other core code, and duplicating a lot of code that really ought not to be. So I've kept the VM_DROPPABLE patch here, but because the x86 instruction decoding stuff has been removed, that patch is actually a lot smaller and simpler and I don't think should be too controversial. In terms of actual C code, it only adds around ten lines, and is compact enough that you can just grep for VM_DROPPABLE to see the whole thing.
The original cover letter is produced below. I'm eager to finally get this patchset moving, and sorry for the delay in producing the v+1 from before.
Assuming this goes well, the plan would be to take this through my random.git tree for 6.11. And if the mm part looks fine, I'll get this cooking in linux-next ASAP."
It's great to see there is light at the end of the tunnel and optimistically may even land for the upcoming Linux 6.11 cycle. The updated patches have been going through review and discussion.
As recently as three days ago the patches were updated in random.git's vdso branch. Here's to hoping this patch series for helping with faster getrandom() performance may be ready to go for the Linux 6.11 kernel after being in the works the past two years.
9 Comments