On Thu, May 14, 2020 at 10:35:48AM +0300, Andreas Gustafsson wrote: > Joerg Sonnenberger wrote: > > > There's nothing wrong with the general idea of entropy estimation as > > > implemented in NetBSD-current. If you run -current on your hypothetical > > > emulator, it will calculate an entropy estimate of zero, and > > > /dev/random will block, as it should. The question we are trying to > > > decide in this thread is whether getentropy() (and consequently, based > > > on nia's list, things like openssl) should also block when this > > > happens, and I'm saying they should. > > > > How should it known that it is not running on real physical hardware > > with random timing vs a deterministic environment with a programmable > > timing pattern? Hint: it can't. > > Of course it can't, and I never said it could.
But you are arguing that it should be able to do that all the time. Make up your mind please. The root problem is not that the kernel uses zero as entropy estimate for most entropy sources, but but there is no way to assign one without knowing the physical processes or at least the interface contracts of the hardware. I.e. a virtualized RNG is still a virtualized RNG and if it works, it will provide the promised entropy. That's about the only category of hardware that has this property though. Now what do we have, all non-dedicated devices have no guaranted entropy, but we can be reasonable sure that there is some in a normal environment. Until when should be block? > > The operator is > > responsible for providing enough entropy during the boot process" is not > > really different from what we did before, just without all the voodoo. > > The question is what should happen when the operator fails to do that. > Not that most computers even have "operators" nowadays. A regular system installation using sysinst on most platforms will create a seed file and the default installation will continue using that to provide a base line with mixed in timing data from regular operation. That's as good as you can normally do. It can fail if the system operator leaks the seed file and not enough entropy is added until an attacker can interact with the system. The primary mechanism for that is operational (mis)handling, i.e. cloning a disk while preserving the seed file. That is something that needs to be documented as it is a procedural issue. Scripts that setup VM images need to be aware of it and should remove the seed file or at least provide a mechanism for having per-instance initial seeding. > > Few programs need to be aware of it at all. > > Based on nia's list, some programs that do need to be aware are using > getentropy(). Both Linux and FreeBSD block in getentropy() when the > system thinks it lacks entropy, and I think NetBSD ought to behave > equally responsibly. OpenBSD always thinks it has entropy, so it > makes no difference whether it specifies blocking behavior for > getentropy() or not. I'd strongly argue that the only category where it really matters potentially are long term key generators. I would at the same time consider creating the ssh host keys as part of sysinst, but that's already setting up the seed file handling too. Joerg
