On Di, 17.09.19 12:30, Ahmed S. Darwish (darwish.07@xxxxxxxxx) wrote: > Ideally, systems would be configured with hardware random > number generators, and/or configured to trust the CPU-provided > RNG's (CONFIG_RANDOM_TRUST_CPU) or boot-loader provided ones > (CONFIG_RANDOM_TRUST_BOOTLOADER). In addition, userspace > should generate cryptographic keys only as late as possible, > when they are needed, instead of during early boot. (For > non-cryptographic use cases, such as dictionary seeds or MIT > Magic Cookies, other mechanisms such as /dev/urandom or > random(3) may be more appropropriate.) > > Sounds good? This sounds mean. You make apps pay for something they aren't really at fault for. I mean, in the cloud people typically put together images that are replicated to many systems, and as first thing generate an SSH key, on the individual system. In fact, most big distros tend to ship SSH that is precisely set up this way: on first boot the SSH key is generated. They tend to call getrandom(0) for this right now, and rightfully so. Now suddenly you kill them because they are doing everything correctly? Those systems aren't going to be more useful if they have no SSH key at all than they would be if they would hang at boot: either way you can't log in. Here's what I'd propose: 1) Add GRND_INSECURE to get those users of getrandom() who do not need high quality entropy off its use (systemd has uses for this, for seeding hash tables for example), thus reducing the places where things might block. 2) Add a kernel log message if a getrandom(0) client hung for 15s or more, explaining the situation briefly, but not otherwise changing behaviour. 3) Change systemd-random-seed.service to log to console in the same case, blocking boot cleanly and discoverably. I am not a fan of randomly killing userspace processes that just happened to be the unlucky ones, to call this first... I see no benefit in killing stuff over letting boot hang in a discoverable way. Lennart
