Date: Tue, 2 Jan 2018 13:09:37 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: [PATCH] Add getrandom syscall wrapper function On Tue, Jan 02, 2018 at 04:27:59PM +0100, Szabolcs Nagy wrote: > * Rich Felker <dalias@...c.org> [2018-01-01 21:14:03 -0500]: > > > > glibc does not have a fallback for this syscall there was a long > > > > discussion about this, see here: https://lwn.net/Articles/711013/ > > > > As they never found a good solution for their fallback. I think musl > > > > should also not provide a fallback. > > > > Interesting that the biggest issue seems to have been about using file > > descriptors as the fallback. That's something I never considered using > > in musl since we have AT_RANDOM and sysctl on ancient kernels that > > lack it. There are a small number of kernels between when sysctl > > started spamming syslog with deprecation warnings and when AT_RANDOM > > was added but I don't really care about those; it still works anyway. > > note that getrandom gives new entropy after fork > but AT_RANDOM is the same. The concept of "new entropy" is not meaningful. Yes, a naive AT_RANDOM-based approach would share state between parent and child in a program that forks without exec, which would be bad, but the obvious way you do this is (1) consume AT_RANDOM and overwrite it with the output of the internal csPRNG so that getauxval(AT_RANDOM) doesn't leak sensitive state, and (2) step the csPRNG twice at fork, using the outputs as the new state in the parent and child so that neither can predict the other's state. Admittedly such a random number source is not hard against heartbleed-type attacks, so you probably should still prefer SYS_getrandom when it's available. On modern systems where people really care, it will be available anyway. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.