On Fri, 30 Jul 2010, Petter Reinholdtsen wrote: > > # Hm, why is the saved pool re-created at boot? [pere 2009-09-03] > > > > Answer: > > 1) The same SAVEDFILE should never be used twice. Never ever.
I have asked the kernel developers. I was told that Linux doesn�t care, you cannot weaken the random pool doing uncredited writes (like we do) because the transformation used by the pool itself is fully reversible, and no information is ever lost, so you cannot dillute it. Based on that data, while it is nice to NOT use the file twice, it is much better to use it twice than to not use it at all, or to use it late (after the kernel needed to use random numbers for session IV generation, encripted swap with ephemeral keys, etc). So, the fix would be to use the file in read-only mode (so that it works on read-only /) ASAP, and later remove and recreate it when we have / remounted read-write. Also, size doesn�t matter much, but it is best to match the pool size. When in doubt, it looks like we can simply always use 4096 bytes. OTOH, the relevant kernel developer said we don�t have pools higher than 2048 bits, but that doesn�t seem to match the sysfs reports done by upstream 2.6.32.y (amd64). If the same scripts are used in The HURD and FreeBSD kernels, we need to check with them as well. > > 2) It is "nice" if the SAVEDFILE gets updated during an orderly > > shutdown, but we cannot depend on this, because of the risk that > > the system might crash, due to power outage or whatever. The > > best approach is "belt and suspenders" i.e. updating it during > > boot *and* updating it again (if possible) during shutdown. Update it on late boot, so that we can feed it to the kernel at early boot (as soon as /dev/urandom is available). Also update on shutdown. This means we need to break the script in two pieces. > > This explanation should be included within the urandom script, > > because the question comes up again and again. > > > > Please update the source, as far upstream as possible. > > > > Let me know if you have any questions. > > Think you. I'm cc-ing your email to the sysvinit/initscripts > maintainers, to make us all aware of this. Will try to find time to > update the script as well. Petter, please have a look on the proper bug already in the BTS, and the recent posts in the pkg-sysvinit-devel ML... weird, I thought you were aware of that thread... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh _______________________________________________ Pkg-sysvinit-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
