On Thu, 21 Sept 2023 at 20:05, Steffen Nurpmeso <stef...@sdaoden.eu> wrote:
> |IMHO, I vote for /sys rather than /proc/debug. The capability to > > There is /proc/sys/kernel/random. > > |directly handle the system entropy pool should be an Admin privilege > |even before being a debug option. As well as disable that handling > |with an > | > |echo 1 > /sys/driver/random/entropy_handle_disable > | > |In such a way that even Admin cannot do something like > | > |echo 1 > /sys/driver/random/entropy_pool_reset > | > |or > | > |dd if=/dev/zero count=128 of=/sys/driver/random/entropy_pool > ... > > Access to the pool will never happen again i bet. Well, not by /dev/random or by /dev/urandom for a matter of back-compatibility and I agree on this. Breaking well established interfaces is not a good policy especially when an alternative is possible. > And i have to concur that with the seedrng approach super fine- > grained and secure locking in a super-parallel super-fast async > boot process is possible. Mixing parallel output streams into a single one like a log daemon does, for a 4 or a 8 cores system is a great source of entropy. On the other side, you can argue that each line of those streams' line carries on a timestamp and this strictly enforces an order. As long as the timestamp is fine-grained, it supplies greatly the lack of arbitrary mixing where arbitrary means when the scheduler decides to switch to another task. > But i do not get his arguments, who writes during the boot, and so > much, and if, just change to /dev/random for credit (i mean, isn't > /dev/urandom the not-so-good thing anyhow). > But if it is not that (random), then a trigger like yours as in > /proc/sys/kernel/random/pool_is_seeded is not a bad idea. Thanks Steffen. After all, it is nothing more that a generalisation of an interface to inject errors which usually would stay in debugfs but because can also have a real-world production advantage - let the admin dealing with the entropy in a straightforward manner - it could be a great way to overcome the limitations of the ioctl() interface, in some advanced system (most of the system can be considered advanced by this definition). Recently I saw a commercial about a mother board carrying up to 8 SoC each of one with a 4-cores ARM CPU, for a total of 32 cores. That board fully equipped was selling for less than $1000. High parallel computing entrance barrier is not anymore as expensive as in the past, but quite cheap. At least for everyone that can pay for a top-gamma smartphone ($1000-$2000) and with the same money can enter into HP computing. Best regards, R- _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
