On Thursday, September 08, 2011 08:52:34 AM Neil Horman wrote: > > to disk device - of course only if the device adds entropy into the > > primary pool when there are writes on the device. > > Yes, and thats a problem. We're assuming in the above case that writes to > disk generate interrupts which in turn generate entropy in the pool. If > that happens, then yes, it can be difficult (though far from impossible) > to block on urandom with this patch and a sufficiently high blocking > threshold. But interrupt randomness is only added for interrupts flagged > with > IRQF_SAMPLE_RANDOM, and if you look, almost no hard irqs add that flag. So > its possible (and even likely) that writing to disk will not generate > additional entropy. The system being low on entropy is another problem that should be addressed. For our purposes, we cannot say take it from TPM or RDRND or any plugin board. We have to have the mathematical analysis that goes with it, we need to know where the entropy comes from, and a worst case entropy estimation. It has to be documented in detail. The only way we can be certain is if its based on system events. Linux systems are constantly low on entropy and this really needs addressing. But that is a separate issue. For real world use, I'd recommend everyone use a TPM chip + rngd and you'll never be short on random numbers. But in the case where we are certifying the OS, we need the mathematical argument to prove that unaided, things are correct. > > Of course you can still easily make the /dev/urandom to occasionally > > block with this patch, just read the data and drop it. > > > > But you have to understand that the value that will be set with the > > sysctl added by this patch will be large in the order of millions of > > bits. > > You can guarantee that? One proposal I made to Jarod was to add some minimum threshold that would prevent people from setting a value of 2, for example. Maybe the threshold could be set at 64K or higher depending on what number we get back from BSI. > This sysctl allows for a setting of 2 just as easily as it allows for a setting of > 8,000,000. And the former is sure to break or otherwise adversely affect > applications that expect urandom to never block. Thats what Sasha was referring to, > saying that patch makes it easy for admins to make serious mistakes. Would a sufficiently high threshold make this easier to accept? -Steve -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
