14.09.2019 21:52, Linus Torvalds пишет: > On Sat, Sep 14, 2019 at 9:35 AM Alexander E. Patrakov > 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