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.
1
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.
Replying to
ah. I'm looking for a cipher fast enough for a 8051. ChaCha20 is just a little bit too slow... though even making it 2x faster would probably not help. all the 32-bit ops really kill the performance
2
1
2
The chacha.c file is based on the reference implementation of ChaCha, converted into a keystream only implementation by removing the XOR with the message. The random.c file implements the CSPRNG on top of it, which fills a small cache (256 bytes) with the keystream and uses it.
1
1
There are also super efficient range generation functions: github.com/GrapheneOS/har. It's essentially the same as OpenBSD arc4random but with ChaCha8, faster range generation, no lock (each size class in each arena has one instead) and without the zeroing when copying out data.