[Toybox] Toybox / mkroot init

[Roberto A. Foglietta]

On Sat, 14 Feb 2026 at 23:33, Roberto A. Foglietta
<roberto.foglietta at gmail.com> wrote:
>
> Hi,
>
> I have integrated and customised the mkroot init file here:
>
> - https://github.com/robang74/bare-minimal-linux-system/blob/main/update/init

Now, the github project above contains a script in particular
(start.sh) that allows to update on-demand on-the-fly the initramfs
from a folder tree (update/). I think that it can be useful for
testing and development. Moreover, allows to keep the git free of
binary artifacts until the next release.

The other project that I think you might find interesting is here:

- https://github.com/robang74/working-in-progress/blob/main/prpr/uchaos.c

Information about the background and test are spread in the repository
but this is the "lab log" (check at the end)

- https://github.com/robang74/working-in-progress/blob/main/random.txt

It is useful to seed the RNDG device when the boot is too fast and
predictable to generate enough "entropy" and the sshd starts later
than it could. In init script can be used in this way:

echo Y > /sys/module/printk/parameters/time
dmesg | tail -c 512 | uchaos -T 8 -r 64 >/dev/random

I am using the 5.13 kernel but above 5.17 it is also required a ioctl
to confirm the injection of entropy like fcntl.ioctl(f, magic_namber,
rand_pool_info)

What is the advantage of this approach? There are 400 C-language code
lines including comment and void lines, and half of the code is to
deal with user interaction by command line. Therefore it can be
integrated into toybox or busybox to avoid compiling it as a separate
static binary (820Kb circa for X86_64 using Ubuntu standard
toolchain).

Is it secure? It depends on the definition of "security", the value at
stake and the attackers. It is just a functional PoC at this stage (3
week os study, 4 days of coding and testing). Despite its PoC nature,
it was able to provide 8GB of output that did not fail on the
PractRand stdin64 test, using the first 512 bytes of its source code
as fixed input and schedule jitter to generate it at the rate of 300K
h/s (each hash is 64-bit).

It works on the github (Microsoft Azure cloud) dockers, qemu, 32bit or
64bit. There is an option to build it for using TSC but it is not
portable outside x86_64 architecture. However, the tests (all of them
and in particular the two of each 8GB) have been done with a binary
compiled with ONLY portable sys calls. It would be interesting to see
how to behave on ARM and ESP32.

If you compile and run for another architecture, consider contacting
me because I wish to see how it works outside the perimeter that I
tested it.

Best regards,
-- 
Roberto A. Foglietta
+49.176.274.75.661
+39.349.33.30.697