[Toybox] Toybox / mkroot init

[Roberto A. Foglietta]

On Tue, 17 Feb 2026 at 09:37, Rob Landley <rob at landley.net> wrote:
>
> On 2/14/26 16:33, Roberto A. Foglietta wrote:
> > Hi,
> >
> > I have integrated and customised the mkroot init file here:
> >
> > - https://github.com/robang74/bare-minimal-linux-system/blob/main/update/init
> >
> > I wish to know which was the license in original, BSD (as toybox), MIT? etc.
>
> 0BSD like the rest of toybox.

Thanks for the kind answer.

> >
> > - why 6.17 instead of 6.12 which is a Long Term Support ?
>
> Toybox releases generally use the kernel that was current at the time of
> the toybox release: toybox 0.8.13 came out October 14 and linux 6.18
> came out december 1, a month and a half later.

Obviously, the same concept can apply when sticking to a LTS branch
but the micro version would be taken instead.

Useless that I explain to you the advantages of a LTS branch, for the
others: more continuity in personalising the mkroot.

>
> > Finally, one more question because I saw musl in a toybox:
> >
> > - What's about https://github.com/jart/cosmopolitan ?
>
> Are you trolling, or are you serious?

I am serious, I did not have the time yet to investigate it. My fault
for having not done my homework before asking and just hoping for a
brief answer by a supposedly well-known human instead of querying an
AI chatbot. Sorry, for asking OT.

> I'm not interested either. (Either we have hardware entropy or we don't
> have hardware entropy. Userspace can't programmatically provide entropy.)

I see your point, but hardware is free from interference? Can be
protected and it is local. Unless the hardware itself is tampered or
remotely switchable. Which is not a theoretical hypothesis anymore,
unless very cheap and limited uCPU.

Anyway, just let me say: CPUs are hardware, thus they can be used for
entropy. Despite CPUs not being available as devices (in a proper
terms we can intend a /dev/tty) their working affect indirectly the
userland activity in particular because of scheduler. Thus, the
scheduler jitters are a hardware source of entropy that can be
collected also by an userland application.

We can agree that we do not trust in userland, by principle. I can
agree but testing in userland is fine. Moreover for the same
principle, I can tell you that I do not trust the host and an userland
application might deceive its own behaviour pretending to be tetris
but being anything else. Let me clarify this point, I am not speaking
about a virus or a rootkit or whatever malicious.

However, I am aware that the same techniques or tools can be used for
the good or for the bad. The problem is always sitting between the
chair and the screen.

- https://github.com/robang74/working-in-progress/commit/50fd4306d96798f91264dfd58f3d5df2b5a1dfec

Finally, I managed to pass without any exception a 16GB (2^34)
PractRand stdin64 test which is not the easiest achievement for a PoC
which is based on 3 weeks of research and less than a week of coding
work and testing. Check the commit comment above, for reference.
However, I totally agree with you that evidence would not convince in
any way those who believe that "entropy is entropy" (rather than being
just data, whatever we might think to have collected it) and pure
white noise is a requirement (rather than being a math requirement and
possibly the only assumption that allows parallel massive analysis in
affordable manner).

I also agree that a A4 paper, smooth surface, standardised maniacally
precisely would not introduce any watermark in a pen writing while a
more "artisanry" piece of paper would. And that is why a piece of
paper with some peculiar irregularities (but not flawed) can introduce
such a kind of watermark and standardisation-break that it would not
practically affect security but mess-up with every industrial mass-gov
attack because outside of industrial 6-sigmas field, manual care or
waste sunk cost are the only two options (before they started to sell
that stuff for counterfeit market but in security is less keen to
happen).

By the way, I have cited busybox because I wish to have a toybox or a
busybox (the advantage of ash, from my PoV but ash can be provided as
its own alone) as self-contained executable which is something above
in terms of abstraction than a static binary, it is an executable
initramfs before even the concept of file system enters in the scene
(and thus cannot be accessible by userland in any manner by direct
interaction). I agree that a not detailed idea is a confused idea, but
intuitions are useful and once the intuition gets detailed in depth,
usually it is a code or a PoV (like uchaos, for example).

Best regards, R-