The man-db compatibility issue with hardened_malloc has been resolved: git.savannah.gnu.org/cgit/man-db.gi. This will also fix compatibility with ports of OpenBSD malloc and other libc hardening triggering calls to getrandom, such as secondary stack randomization if man-db spawns threads.
Conversation
There's a single call to getrandom during init for the init CSPRNG. For efficiency, that's used to seed all the others, but it has no use after that and is unmapped. The reason getrandom is called again is regularly reseeding as a minor security boost: github.com/GrapheneOS/har.
1
3
Originally I started out with caching the output of getrandom directly, but that's at least an order of magnitude too slow even with the system call cost amortized. Even the current optimized scalar ChaCha8 implementation with highly optimized random range generation is too slow.
Replying to
Yes, I use ChaCha8 rather than ChaCha20 because it has much higher throughput and it's still more than strong enough for the use case of probabilistic memory corruption mitigations:
github.com/GrapheneOS/har
ChaCha8 is the same code as ChaCha20 with 8 rounds instead of 20 rounds.
2
3
Show replies