Re: [PATCH] Add getrandom syscall wrapper function

[Rich Felker <dalias@libc.org>]

On Tue, Jan 02, 2018 at 04:27:59PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.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