On Sun, Sep 15, 2019 at 11:30:57AM +0200, Willy Tarreau wrote: > On Sun, Sep 15, 2019 at 10:59:07AM +0200, Lennart Poettering wrote: > > 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. > > It is exactly the type of crap that create this situation : making > people developing such scripts believe that any random source was OK > to generate these, and as such forcing urandom to produce crypto-solid > randoms! Willy, let's tone it down please... the thread is already getting a bit toxic. > No, distro developers must know that it's not acceptable to > generate lifetime crypto keys from the early boot when no entropy is > available. At least with this change they will get an error returned > from getrandom() and will be able to ask the user to feed entropy, or > be able to say "it was impossible to generate the SSH key right now, > the daemon will only be started once it's possible", or "the SSH key > we produced will not be saved because it's not safe and is only usable > for this recovery session". > > > 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. > > This is precisely what this change permits : fail instead of block > by default, and let applications decide based on the use case. > Unfortunately, not exactly. Linus didn't want getrandom to return an error code / "to fail" in that case, but to silently return CRNG-uninitialized /dev/urandom data, to avoid user-space even working around the error code through busy-loops. I understand the rationale behind that, of course, and this is what I've done so far in the V3 RFC. Nonetheless, this _will_, for example, make systemd-random-seed(8) save week seeds under /var/lib/systemd/random-seed, since the kernel didn't inform it about such weakness at all.. The situation is so bad now, that it's more of "some user-space are more equal than others".. Let's just at least admit this while discussing the RFC patch in question. thanks, > > Quite frankly, I don't think this is something to fix in the > > kernel. > > As long as it offers a single API to return randoms, and that it is > not possible not to block for low-quality randoms, it needs to be > at least addressed there. Then userspace can adapt. For now userspace > does not have this option just due to the kernel's way of exposing > randoms. > > Willy
