On Sun, Sep 15, 2019 at 12:55:39PM +0200, Ahmed S. Darwish wrote: > On Sun, Sep 15, 2019 at 12:40:27PM +0200, Willy Tarreau wrote: > > 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: > [...] > > > > > 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"). > > > > V1 of the patch I posted did indeed return -EINVAL. Linus then > suggested that this might make still some user-space act smart and > just busy-loop around that, basically blocking the boot again: > > https://lkml.kernel.org/r/CAHk-=wiB0e_uGpidYHf+dV4eeT+XmG-+rQBx=JJ110R48QFFWw@xxxxxxxxxxxxxx > https://lkml.kernel.org/r/CAHk-=whSbo=dBiqozLoa6TFmMgbeB8d9krXXvXBKtpRWkG0rMQ@xxxxxxxxxxxxxx > > So it was then requested to actually return what /dev/urandom would > return, so that user-space has no way whatsoever in knowing if > getrandom has failed. Then, it's the job of system integratos / BSP > builders to fix the inspect the big fat WARN on the kernel and fix > that. Then I was indeed a bit confused in the middle of the discussion as I didn't understand exactly this, thanks for the clarifying :-) But does it still block when called with GRND_RANDOM ? If so I guess I'm fine as it translates exactly the previous behavior of random vs urandom, and that GRND_NONBLOCK allows the application to fall back to reliable sources if needed (typically human interactions). Thanks, Willy
