__vdso_getrandom/__kernel_getrandom has been recently introduced into the linux kernel, I wonder what should be a proper plan to utilize it. The additional userspace state structure looks a bit scary to me. It seems to me that the state requires proper maintenance across fork and clone, and has potential security implications. This reminds me of history of pid caching, so I am hesitating on whether I should go ahead to implement getrandom optimization when the vDSO symbols are available. (P.S. this time, kernel provides desired flags that can help us to keep the region safe to some extend: https://lore.kernel.org/linux-mm/[email protected]/T/)
Given that glibc is already working on a patch, I wonder if we have consensus on the following questions:
1. Is there a clear performance demand such that it becomes necessarily to avoid syscall inside
2. Is it certain that such performance demand will pay off given all the additional complexity required to maintain per-thread/per-process state (with async-signal-safety)?
3. Is it clear that unwrapped clone/fork and other edge cases will not complicate the situation?
Given that glibc is already working on a patch, I wonder if we have consensus on the following questions:
1. Is there a clear performance demand such that it becomes necessarily to avoid syscall inside
getrandom? 2. Is it certain that such performance demand will pay off given all the additional complexity required to maintain per-thread/per-process state (with async-signal-safety)?
3. Is it clear that unwrapped clone/fork and other edge cases will not complicate the situation?