On So, 15.09.19 10:17, Ahmed S. Darwish (darwish.07@xxxxxxxxx) wrote: > Thus, don't trust user-space on calling getrandom(2) from the right > context. Never block, by default, and just return data from the > urandom source if entropy is not yet available. This is an explicit > decision not to let user-space work around this through busy loops on > error-codes. > > Note: this lowers the quality of random data returned by getrandom(2) > to the level of randomness returned by /dev/urandom, with all the > original security implications coming out of that, as discussed in > problem "3." at the top of this commit log. If this is not desirable, > offer users a fallback to old behavior, by CONFIG_RANDOM_BLOCK=y, or > random.getrandom_block=true bootparam. This is an awful idea. It just means that all crypto that needs entropy doing during early boot will now be using weak keys, and doesn't even know it. Yeah, it's a bad situation, but I am very sure that failing loudly in this case is better than just sticking your head in the sand and ignoring the issue without letting userspace know is an exceptionally bad idea. We live in a world where people run HTTPS, SSH, and all that stuff in the initrd already. It's where SSH host keys are generated, and plenty session keys. If Linux lets all that stuff run with awful entropy then you pretend things where secure while they actually aren't. It's much better to fail loudly in that case, I am sure. Quite frankly, I don't think this is something to fix in the kernel. Let the people putting together systems deal with this. Let them provide a creditable hw rng, and let them pay the price if they don't. Lennart -- Lennart Poettering, Berlin
