Re: Linux 5.3-rc8

[Alexander E. Patrakov]

14.09.2019 21:52, Linus Torvalds ÐÐÑÐÑ:
> On Sat, Sep 14, 2019 at 9:35 AM Alexander E. Patrakov
> <patrakov@xxxxxxxxx> wrote:
> > Let me repeat: not -EINVAL, please. Please find some other error code,
> > so that the application could sensibly distinguish between this case
> > (low quality entropy is in the buffer) and the "kernel is too dumb" case
> > (and no entropy is in the buffer).
>
> I'm not convinced we want applications to see that difference.
>
> The fact is, every time an application thinks it cares, it has caused
> problems. I can just see systemd saying "ok, the kernel didn't block,
> so I'll just do
>
>     while (getrandom(x) == -ENOENTROPY)
>         sleep(1);
>
> instead. Which is still completely buggy garbage.

OK, I understand this viewpoint. But then still, -EINVAL is not the 
answer, because a hypothetical evil version of systemd will use -EINVAL 
as -ENOENTROPY (with flags == 0 and a reasonable buffer size, there is 
simply no other reason for the kernel to return -EINVAL). Yes I 
understand that this is a complete reverse of my previous argument.

> The fact is, we can't guarantee entropy in general. It's probably
> there is practice, particularly with user space saving randomness from
> last boot etc, but that kind of data may be real entropy, but the
> kernel cannot *guarantee* that it is.
>
> And people don't like us guaranteeing that rdrand/rdseed is "real
> entropy" either, since they don't trust the CPU hw either.
>
> Which means that we're all kinds of screwed. The whole "we guarantee
> entropy" model is broken.

I agree here. Given that you suggested "to just fill the buffer and 
return 0" in the previous mail (well, I think you really meant "return 
buflen", otherwise ENOENTROPY == 0 and your previous objection applies), 
let's do just that. As a bonus, it saves applications from the complex 
dance with retrying via /dev/urandom and finally brings a reliable API 
(modulo old and broken kernels) to get random numbers (well, as random 
as possible right now) without needing a file descriptor.

--
Alexander E. Patrakov

Attachment: smime.p7s
Description: Криптографическая подпись S/MIME