On Tue, Sep 10, 2019 at 07:21:54PM +0100, Linus Torvalds wrote: > On Tue, Sep 10, 2019 at 6:33 PM Ahmed S. Darwish <darwish.07@xxxxxxxxx> wrote: > > > > While gnome-session is obviously at fault here by requiring > > *blocking* randomness at the boot path, it's still not requesting > > much, just (5 * 16) bytes to be exact. It doesn't matter how much randomness it's requesting. With the new cryptographic random number generator, the CRNG is either initialized.... or it's not. > Just out of curiosity, what happens if you apply a patch like this > (intentionally whitespace-damaged, I don't want anybody to pick it up > without thinking about it) thing... > Which I think is what the code really wants - it's only using jiffies > because that is the only thing _guaranteed_ to change at all. But with > the sum, you get the best of both worlds, and should basically make > the entropy estimation use the "better of two counters". > > Ted, comments? I'd hate to revert the ext4 thing just because it > happens to expose a bad thing in user space. Unfortuantely, I very much doubt this is going to work. That's because the add_disk_randomness() path is only used for legacy /dev/random (which actually only still exists because of some insane PCI compliance issues which a number of end users really care about --- or they care about because it makes the insane PCI complaince labs go away). Also, because by default, the vast majority of disks have /sys/block/XXX/queue/add_random set to zero by default. So the the way we get entropy these days for initializing the CRNG is via the add_interrupt_randomness() path, where do something really fast, and we assume that we get enough uncertainity from 8 interrupts to give us one bit of entropy (64 interrupts to give us a byte of entropy), and that we need 512 bits of entropy to consider the CRNG fully initialized. (Yeah, there's a lot of conservatism in those estimates, and so what we could do is decide to say, cut down the number of bits needed to initialize the CRNG to be 256 bits, since that's the size of the CHACHA20 cipher.) Ultimately, though, we need to find *some* way to fix userspace's assumptions that they can always get high quality entropy in early boot, or we need to get over people's distrust of Intel and RDRAND. Otherwise, future performance improvements in any part of the system which reduces the number of interrupts is always going to potentially result in somebody's misconfigured system or badly written applications to fail to boot. :-( - Ted
