[Toybox] Toybox / mkroot init

[Rob Landley]

On 2/17/26 05:21, Roberto A. Foglietta wrote:
>>> 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.

Conceptually this initramfs is just 
https://linuxfromscratch.org/hints/downloads/files/OLD/bsd-init.txt 
taken to its logical conclusion. (Over the course of 20+ years. And I'm 
pretty sure I started with an earlier, simpler version of that before it 
got "updated" to be more complex, but am not fishing for it...)

>>> - 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.

No, the point is to catch upstream regressions in the kernel. I have a 
patch stack I apply 
(https://landley.net/bin/mkroot/0.8.13/linux-patches/) to beat basic 
functionality out of it for that set of architectures. (The README in 
the same directory as the tarballs mentions this, as do the release notes.)

At some point, the kernel will make a Career Limiting Move like refusing 
to build basic services without rust or something. I maintained a perl 
removal patch stack for many years (it finally went upstream in 2013, 
about the same time an employer poked me to fix the initramfs 
documention I'd written back in 2005 that said you could also use tmpfs, 
by making the vanilla kernel actually do that)

This is why mkroot builds under a toybox airlock: when they break stuff, 
I like to notice before institutional memory of what they DID fades. 
(Not that they've answered my questions in a while now. Development is 
going down such a rathole these days I've got "migrate to netbsd" on my 
long-term todo list because this ain't gettin' fixed. The cultural 
recto-cranial inversion that's blocked things like 
https://landley.net/bin/mkroot/0.8.13/linux-patches/0003-Wire-up-CONFIG_DEVTMPFS_MOUNT-to-initramfs.patch 
from going upstream since 2017 is a progressive condition.)

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

I'm aware of the concept of "Long Term Support" (since Ubuntu started 
using the name), and get cc'd on Greg KH's LTS branches for a year after 
any patch I've got an acked-by on goes in.

You're welcome to use other kernels. The LINUX=/path/to/source argument 
is theoretically kernel agnostic, or you could build it yourself using 
the docs/linux-fullconfig file in each tarball. These are just the 
releases _I_ do.

(Somebody rewrote mkroot in rust for no apparent reason. That "one true 
language" cult has advanced to the point they feel the need to rewrite 
bash scripts in their fixation now. Am I the only one who thinks 
clawdbot and moltbook and stuff having obviously rust-derived crustacean 
logos is... indicative of a mindset? No, just me? Ok...)

>>> 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.

If you're not skeptical of a "one true standard" that hasn't been 
touched in 6 years...

https://xkcd.com/927/

It thinks "universal" means Linux plus mac and 3 bsd versions. It's 
x86-64 specific despite mac having gone arm ~6 years ago (before x86 it 
was ppc, and before that it was m68k, so if you think that's the last 
stop...) and Android having been arm all along. It seems to add /bin/sh 
(and thus sourcing various profile scripts) into the invocation of every 
binary. (Presumably meaning your shell still has to be an actual binary 
and libc your kernel has a loader for?) If they really did write their 
own libc (I didn't dig that far) then lib/porability.{h,c} would 
probably double in size trying to make that work. The author does not 
even seem to be aware of issues like 
https://devblogs.microsoft.com/oldnewthing/20050131-00/?p=36563 (unless 
they're applying Linux binary semantics to windows binaries in which 
case your syscall translation layer's gonna be HUGE, or maybe they're 
running under WSL there in which case why not just ELF?)

I wrote a noticeably longer list of gripes the first time (and am not 
going through the page and enumerating issues or looking up rebuttal 
links again), then deleted it to first ask whether or not you were 
serious because I could no longer tell.

One of the big problems with https://pubmed.ncbi.nlm.nih.gov/41656802/ 
is how its users make piles of work for other people. "You did not think 
of this because you did not think at all. You deployed something a 
vending machine glued together out of recycled parts which worked for 
you once, in a problem space you did not even attempt to understand, and 
the inevitable side effects are "externalities" which other people 
clearly should clean up for you because said vending machine tells you 
that you are a special person whose time is more valuable than theirs. 
(And that's not ME saying it, 
https://openai.com/index/sycophancy-in-gpt-4o/ was about doing a whole 
revision to try to make the "sycophancy" (their word!) less obvious 
and/or legally actionable.)

"Explain to me why this is wrong" is making a request for my time and 
energy, to perform an analysis for someone who admits they haven't 
looked into it at all yet.

> 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.

It's not the off topic (if you'd asked about shipping bionic binaries or 
mac binaries or bsd binaries that would be relevant), it's that you 
didn't think through it yourself and wanted me to think for you.

I remember you from the busybox mailing list 20 years ago. The first 
commit in the busybox repo mentioning you (7b4aa6ffc6a4) is from 2006. 
You've got at least as much experience here as I do. You're asking me 
about a project you could have poked at yourself to see if it was load 
bearing.

Yes, that project is vaguely familiar at first glance, I'm pretty sure 
it wandered by years ago and seemed a manifestation of dunning-kruger 
then too.

There's a reason the web page was last updated 6 years ago and did not 
take the world by storm in the intervening time. What it's TRYING to do 
has an enormous attack surface, to the point it would have been big news 
if it HAD worked. Extraordinary claims require extraordinary evidence.

(I'm trying not to be prejudiced by 
https://lists.busybox.net/pipermail/busybox/2026-February/091907.html 
and https://lists.busybox.net/pipermail/busybox/2026-January/091889.html 
and such, but... there's a reason I keep thinking about AI psychosis in 
this case.)

>> 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?

No, it's about understanding threat models.

Do you know why Diaper Dan loves eating McDonalds? Because back when I 
lived in New Jersey (I moved out in 1995) he was laundering money for 
the Russian mob.

(Which he seems to have pivoted to after blowing through the entirety of 
Fred's estate, which he acquired by appointing himself executor of it, 
https://nyprobate.com/mary-trump-donald-trump-lawsuit-inheritance/ has 
some of the details but it was common knowledge around Atlantic City 
back in the day. Seriously, why do you think he's gone bankrupt so many 
times but 
https://www.theguardian.com/business/2019/apr/17/deutsche-bank-faces-action-over-20bn-russian-money-laundering-scheme 
was always willing to loan him more money? Because before 2008 the IRS 
didn't look at LOSSES as potential money laundering, so all an oligarch 
had to do was "loan" a billion dollars to a cleaner, who then spent 95% 
of it on the oligarch's businesses and then declared bankruptcy. The 
more blatant oligarchs even got a tax writeoff for the "losses", to 
apply against the new "income" to avoid paying taxes on the laundered 
money.)

Since the russians love poisoning people (apparently Nalvany got done in 
by dart frog poison, which is just showboating), grabbing random 
commodity meals from an outlet that didn't know he was coming made that 
asshole feel safe back when he still had a temporal lobe.

The same is approximately true of commodity hardware. You can do supply 
chain attacks on it, but a random raspberry pi grabbed off the shelf 
from best buy or something doesn't give a lot of attack surface. 
(Especially if you took public transit with your phone left home and 
paid cash. :)

As I said: threat models. Who is likely after you to accomplish what? My 
programming output's posted publicly and subject to peer review, what 
would exploiting my stuff get anyone other than the usual personal 
theft? (Or done on hardware provided by an employer thus delegating 
fiduciary responsibility for securing it.) I have electrical tape over 
my phone's front and back facing cameras and never ever spend money 
through it because that's my comfort level, yes I'm aware there's no 
tape over the microphone but you gotta draw the line somewhere. I paid 
more than a new phone would cost to have the screen replaced recently 
because as nice as Elliott is, I don't trust the corporation that did 
https://www.kaspersky.com/blog/what-are-android-safetycore-and-key-verifier/53171/ 
to provide a new OS version those can't be uninstalled from, and I 
really don't want to stop to come up to speed on grapheneOS right now. I 
could write for half an hour on the downsides of using an old android 
version that went out of service in 2022, and again about migrating to 
https://www.youtube.com/watch?v=4To-F6W1NT0 but there are no perfect 
options, and you've gotta pick a local peak in your threat model that 
mitigates "enough" risk. There is no "safe", just "safer" with a price tag.

> 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.

If your hardware has been tampered with in a supply chain attack or evil 
maid situation, you've already lost.

> Anyway, just let me say: CPUs are hardware,

See the j-core stuff in https://landley.net/resume.html going back to 
2014? Or stuff like 
https://web.archive.org/web/20001109095700/http://www.fool.com/portfolios/rulemaker/2000/rulemaker000901.htm 
from basically a previous life.

I am aware that CPUs are hardware, thanks.

> 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.

Which the linux kernel has done since... 1996 I think?

The kernel is providing those context switches for you. If the kernel is 
exploited, the idea that userspace using information provided from the 
kernel can keep you safe is basically the old hashing security argument 
(providing unknowable answers from known inputs). There used to be some 
conference videos from ~1985 about that. (Not HOPL II but filed next to 
the HOPL II tapes, years ago on VHS in a library I drove to back when I 
lived a more nomadtic lifestyle after my mother died and I inherited her 
station wagon...)

> We can agree that we do not trust in userland,

Who's "we", kemosabe?

I don't trust the kernel, the hardware, and vaguely expect that if we're 
up against a state/oligarch actor somebody's got a drone pointing a yagi 
antenna through a window or hooked up a synchrophasor the building's 
power lines to reconstruct the processor operations from electromagnetic 
evidence of differential power consumption or similar nonsense. (Which 
was "cutting edge as far as I knew" circa 2005, meaning the Five Guys 
had probably been encoding it into their french fries 20 years before 
then...)

Seriously, the dunning-krugerand priesthood were worried about this sort 
of thing when https://xkcd.com/538/ was obviously more common. As in 
https://apnews.com/article/crypto-cryptocurrency-kidnapping-new-york-f43b5da989093d956ab39bc5fc62a72a 
were IDIOTS because the pros quietly threaten family members and such 
and get away without leaving evidence.

My father did defense contracting from before I was born until after I 
graudated and moved away (the stuff on kwaj was ICBM guidance and 
tracking systems, the New Jersey Stuff was the Aegis Phased Array Radar 
System). My grandfather (on the OTHER side of the family) worked for the 
NSA for 40 years and I _didn't_know_ until my mother's funeral in 2002 
(when he got very drunk and my brother had to wrestle his gun away from 
him; outliving his wife _and_ 2 of his 3 children did not sit well), at 
which point he'd been out of the game for 15 years (he never 
volunteered, he just did cryptography during world war II and they told 
him if he didn't "volunteer" for this new OSI thing that turned into the 
NSA they'd draft him and put him on the font line in Korea; he finally 
got out when some IDIOT tried to hand off information to him in Iraq in 
1986 and blew his cover as a senior engineer at GE sent around the world 
to troubleshoot problems. I knew my father and mother met on the apollo 
program because he dated the boss's daughter, I _hadn't_ known said boss 
was Verhner Von Braun's NSA liason.)

There is a reason I've never taken a job requiring security clearance. I 
have zero interest in getting any of that crap on me.

"What level am I operating at? Not that."

(I still need to read https://en.wikipedia.org/wiki/The_Puzzle_Palace 
which I _think_ was the book Grampa said was very good, but I also got 
the vague impression that No Such Agency turned into a PR firm when it 
got outed and the real work moved to like army intelligence or 
something? Not my area, I haven't asked, dowanna get that on me...)

> 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.

You literally cannot be paranoid enough. Thus I just assume exploitation 
and fraud in the system all the way down, treat it as a cost of doing 
business, and mostly try not to be worth targeting or let obvious stuff 
go unverified. (Can't stop it, might catch it after the fact, or at 
least preserve forensic evidence I'm currently unaware of the value of 
so experts eventually can if it ever comes up.)

 From a technical perspective: busybox added a basic https 
implementation to its lib because without it wget and httpd are 
basically useless in a modern context. So added "simple RSA+AES tls 1.2" 
to the post-1.0 TODO heap but haven't really looked at it yet (outside 
of bookmarking https://www.muppetlabs.com/~breadbox/txt/rsa.html and 
such...)

But that's "missing capability I don't want to depend on an external 
library to provide". If your kernel mechanism underlying libc's 
getentropy() is borked: fix your system.

> 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.

https://en.wikipedia.org/wiki/Printer_tracking_dots#Protection_of_privacy_and_circumvention

Being aware and wanting to engage are different things. No thank you.

(You leave fingerprints on everything. You leave DNA on everything. 
There are cameras everywhere. Don't read up about palantir if you don't 
want to lose sleep due to rage at the sheer injustice of guilllotines 
not currently being part of the social contract's generally agreed upon 
enforcement toolkit.)

> 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)

I'm trying to get toysh into reasonable shape but life has not been 
cooperating the past few years.

> 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

A filesystem before a filesystem?

You have to have a filesystem to launch the first executable from, 
that's how PID 1 launches. (And before that it opens stdin/stdout/stderr 
from /dev/console which I've GRIPED ABOUT AT LENGTH in so many places 
because the static initramfs path is buggy in the kernel and they keep 
ignoring my attempts to fix it...)

> (and thus cannot be accessible by userland in any manner by direct
> interaction).

https://landley.net/aboriginal/old used to glue a zisofs (squashfs 
didn't exist yet) onto the end of a kernel (lilo patch in a real boot, I 
don't remember if grub existed yet) or a user mode linux ELF executable 
(qemu didn't exist yet) and repurposed part of the ELF header to point 
to the offset to loopback mount the file from the initrd (initramfs 
didn't exist yet) and then pivot_root (I don't think mount --move 
existed yet)...

There's a reason I was following initramfs very closely and wrote up my 
own documentation when I couldn't find any.

I"m pretty sure you were around on the #busybox IRC channel and mailing 
list during this time.

Rob

P.S. One of my proposed talks at ELC, since they're having it in 
Minneapolis this year, is "booting Linux under VHDL simulation" where we 
build a toolflow (well, nvc), build simulated VHDL hardware that sort of 
thinks it's an ECP5 FPGA with simulated spi flash (also VHDL, from some 
foundation) and simulated giant block of SRAM (C via 
https://www.nickg.me.uk/nvc/manual.html#VHPI) bolted on, build linux 
from source with a new device tree, and then do hardware bringup through 
our own ROM bootloader (also written in C, which we also compile during 
this, then the SOC build creates the rom using a trap-based ELF loader 
WRITTEN IN VHDL, Jeff is crazy) that reads a vmlinux from the flash and 
ELF loads it into the sram and calls its entry point, so it can boot up 
and spit messages out to emulated serial port and eventually a serial 
console shell prompt.