On Tue, 19 Sept 2023 at 13:30, Rob Landley <[email protected]> wrote: > > Modern "software" entropy collection is mostly timing jitter collected very > slowly as the system runs. The theory for embedded devices was if you have > some > writeable space in the device you save a few hundred bytes of /dev/urandom > output on shutdown and write it back on bootup so you're keeping enough > entropy > across reboots to seriously salt your attack surface. The perfect is the enemy > of the good: this just makes different boots behave differently.
Even without a small writable space the problem could be addressed because the time jittering at boot kernel time before the system would be ready and expose any kind of service. A general solution that can be completely safe and efficient for all kinds of systems or hardware on which Linux kernel can run is very hard to find. For a subset of systems - fortunately the most used and common to be found on the market - the solution is to amplify the small amount of entropy generated by kernel boot timing jittering and use it to seed the /dev/urandom. Because the amplification process can always be based on mixing multi-task outputs in a single stream in a way that tiny⁻⁴ timings variations (jittering) makes a difference also in lines ordering - in an truly unpredictable way - then the dmesg output provided with a fine-grained time resolution timestamp on each line can be used as input for a hash function or a compression algorithm tailored for discarding de/compression metadata. With this data it is possible to seed the /dev/random. Even In a system that always start with UNIX EPOCH = 0 and is missing an RTC, in the /init execute this instruction dmesg | sha512sum as soon as possible. I bet that you will never find two occurrences that match as far as the dmesg is provided with a enough fine-grained time resolution. In those system for which the time resolution provided by dmseg is too large compared with the timings jittering at boot time, then the sha512sum will ALWAYS provide the same output unless multi-tasking boot mix-up some lines because hardware initialisation timings can varying enough (a mixed case, few or some hashes are possible but not a great variety of them). In all these cases, seeding the /dev/urandom with this procedure DOSN'T hurt. Is the seed constant? At least it is not the same for all the systems but characteristic of that specific hw/vt instance. Is the seed weak because it can spawn among few/some others, at least is not totally constant like providing nothing at all. The seed is good but the cat /proc/cmdline happens like in Android just because they need to do something about? Fine, we cannot prevent it. As you can see the problem is not the problem, the problem is the perception of the problem. dmesg | sha512sum > /dev/urandom As the first init instruction or as the last kernel boot operation, is THE general answer also when it is not the solution. Some systems need a more dedicated effort but in no way THE answer puts them in a worse condition than they were before. Confutations are welcome. :-) _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
