Re: [PATCH RFC v3] random: getrandom(2): optionally block when CRNG is uninitialized

[Willy Tarreau]

On Sun, Sep 15, 2019 at 12:02:01PM +0200, Ahmed S. Darwish wrote:
> 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.

I don't see what's wrong in my tone above, I'm sorry if it can be
perceived as such. My point was that things such as creating lifetime
keys while there's no entropy is the wrong thing to do and what
progressively led to this situation.

> > > 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.

But with this EINVAL you have the information that it only filled
the buffer with whatever it could, right ? At least that was the
last point I manage to catch in the discussion. Otherwise if it's
totally silent, I fear that it will reintroduce the problem in a
different form (i.e. libc will say "our randoms are not reliable
anymore, let us work around this and produce blocking, solid randoms
again to help all our users").

> 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..

Then I am confused because I understood that the goal was to return
EINVAL or anything equivalent in which case the userspace knows what
it has to deal with :-/

Regards,
Willy