Theodore Ts'o <tytso@xxxxxxx> writes: > On Mon, Jun 19, 2017 at 10:57:18PM +0200, Jason A. Donenfeld wrote: >> >> With rc6 already released and rc7 coming up, I'd really appreciate you >> stepping in here and either ACKing the above commit, or giving your >> two cents about it in case I need to roll something different. > > I actually had set up an earlier version of your patch for on Saturday > while I was in Beijing. (Like Linus, I'm attending the LinuxCon China > conference Monday and Tuesday.) I had even created the signed tag, > but I didn't send the pull request to Linus because I was waiting to > see about how discussions over the locking strategy and the spammy log > messages on PowerPC was going to get resolved. > > I've since respun the commit to reflect your newer patch (see the > random_for_linus_stable tag on random.git) and rebased the dev branch > on top of that. Please take a look and comment. > > The other open issue I want to resolve before sending a pull request > this week is whether we want to change the default for > CONFIG_WARN_UNSEEDED_RANDOM so that the answer is 'n'. Yes please. > It *is* spammy for PowerPC, because they aren't getting their CRNG *some* powerpc machines ... > initialized quickly enough, so several userspace processes are getting > fork/exec'ed with an uninitialized CRNG. That being said, it is a > valid warning because it means that the initial stack canary for the > first couple of PowerPC processes are being created without a fully > initialized CRNG, which may mean that an attacker might be able to > circumvent the stack canary on the first couple of processes. So that > could potentially be a real security issue on Power. OTOH, most Power > users aren't going to be able to do anything about the fact the stack > canaries of the system daemons started during early boot don't have > strong randomness, so perhaps we should disable the warning by > default. powerpc supports a wide range of hardware platforms, some of which are 10-15 years old, and don't have a hardware RNG. Is there anything we can do on those machines? Seems like our only option would be to block the boot while some more "entropy" builds up, but that's unlikely to be popular with users. On our newer machines (>= Power8) we have a hardware RNG which we wire up to arch_get_random_seed_long(), so on those machines the warnings would be valid, because they'd indicate a bug. So I think it should be up to arches to decide whether this is turned on via their defconfigs, and the default should be 'n' because a lot of old hardware won't be able to do anything useful with the warnings. cheers
