On Sat, Sep 14, 2019 at 03:32:46PM -0700, Linus Torvalds wrote: > > Worse, it won't even accomplish something against an obstinant > > programmers. Someone who is going to change their program to sleep > > loop waiting for getrandom(2) to not return with an error can just as > > easily check for a buffer which is zero-filled, or an unchanged > > buffer, and then sleep loop on that. > > Again, no they can't. They'll get random data in the buffer. And > there is no way they can tell how much entropy that random data has. That makes me even more worried. It's probably going to be OK for modern x86 systems, since "best we can do" will include RDRAND (whether or not it's trusted). But on systems without something like RDRAND --- e.g., ARM --- the "best we can do" could potentially be Really Bad. Again, look back at the Mining Your P's and Q's paper from factorable.net. If we don't block, and we just return "the best we can do", and some insane userspace tries to generate a long-term private key (for SSH or TLS) in super-early boot, I think we owe them something beyond a big fat WARN_ON_ONCE. We could return 0 for success, and yet "the best we can do" could be really terrible. > > For 5.3, can we please consider my proposal in [1]? > > > > [1] https://lore.kernel.org/linux-ext4/20190914162719.GA19710@xxxxxxx/ > > Honestly, to me that looks *much* worse than just saying that we need > to stop allowing insane user mode boot programs make insane choices > that have no basis in reality. > > It may be the safest thing to do, but at that point we might as well > just revert the ext4 change entirely. I'd rather do that, than have > random filesystems start making random decisions based on crazy user > space behavior. All we're doing is omitting the plug; I disagree that it's really all that random. Honestly, I'd much rather just let distributions hang, and force them to fix it that way. That's *much* better than silently give them "the best we can do", which might be "not really random at all". The reality is that there will be some platforms where we will block for a very long time, given certain kernel configs and certain really stupid userspace decisions --- OR, we can open up a really massive security hole given stupid userspace decisions. Ext4 just got unlocky that a performance improvement patch happened to toggle one or two configurations from "working" to "not working". But just saying, "oh well" and returning something which might not really be random with a success code is SUCH A TERRIBLE IDEA, that if you really prefer that, I'll accept the ext4 revert, even though I don't think we should be penalizing all ext4 performance just because of a few distros being stupid. If the choice is between that and making some unsuspecting distributions being potentially completely insecure, it's no contest. I won't have that on my conscience. - Ted
