(c) 2026 – Roberto A. Foglietta <roberto.foglietta@gmail.com>, CC BY-NC-ND 4.0
- Click on the button to know how to
this project and get in touch with me.
Warning
μChaoSys isn't an operative system but a recipe to create a specific operative system. A recipe that a bright kid can operate as well as the recipe's product, but a dumb adult cannot. Deliberately and hopefully, this warning helps everyone to grasp how silly/mad is, in its fundamentals, the idea to divide knowledge and agency by age.
This project is based on the previous case study random.txt in WIP, starting on 2026-01-26. Which leveraged the BMLS testing system for evolving from shell script (PoC) to the kernel (MVP). The main goal of respawning from scratch the project on a new repository is to strip the project from all that stuff accumulated over and over during the experimental development.
- Technical Presentation for Commercial Sponsorship (2026-03-16)
- Why it works so well as training consultancy content (2026-04-07)
Last but not least, this project provides a micro Linux embedded system with a footprint below 2MB (including the kernel and the initramfs, cfr. Components) as the result of a building process starting from the sources.
Checking the information below and those reported in the link above, we can agree that this project is interesting from several point of views. Including the ability of self-hosting and self-executing in a cascade KVM 64MB to TCG 32MB, for example.
In this peculiar system configuration uChaos replaces all the entropy sources within the Linux kernel and creates a character device driver that can be seen as a side channel and/or a malicious entropy injection channel, as well.
Moreover, using extreme qemu parameters settings, it is possible testing the system into a condition of complete isolation (AFAIK) which grants the predictability by repeatability across reboots of the uchaos and Linux crng randomness providers, both.
The data reported below are indicative and specific for the reference tagged version v0.6.5 which adopts the all-static policy (footprints: +3% sys, +1% musl) and boots on an experimental frankenstein glibc-musl all-static qemu compiled on Ubuntu 22.04 (footprint: +25% dev/build).
Reference processor i5-8365, toolchain metrics:
system building total time: 970 s (16m 10s)¹dev/build environment size: 5479 MB (5.35 GB)repository .zip copy size: 520 KB (pdf+img)
Reference architecture x86_64, system footprint:
uncompressed .cpio size: 672 KBinitramfs.cpio.gz size: 416 KBlinux kernel image size: 1384 KBqemu bootable system size: 1808 KB (1.76 MB)²
Running this minimal system, the essential metrics:
CPU single-pipeline KVM: sh start.sh -q -m 32total time for being ready to user: 0.064 s!!!total available memory in userland: 18856 KBhost: 32768, zram: -4714, cpio: -664 KBmlnx: 23544, used: -2408, buff: -1492 KB
It is interesting to note how the memory is allocated .
¹ in v0.6.8 without sources download variable time.
² without RNG_test for which .cpio size +2.28 MB.
- musl v1.2.15, and related packages for the cross-compilation toolchain;
- busybox v1.38, as the whole initramfs system component and user shell;
- linux v5.15.202, as the kernel from a very widely spread LTS branch;
- uchaosbox & dev.ko, as userland utility toolbox and char device driver;
- qemu v10.2.2, as machine emulator with virtio/microvm/q35 support.
- dL1 ‐ PractRand RNG_test, external static tool for testing randonmess quality
- dL2 ‐ gzcmd.sh, converts an executable in a gziped self-extracting executable
While PractRand RNG_test (2288 KB) is indispensable for testing, the gzcmd.sh is also relevant despite initramfs compression. In fact, the unreclaimable memory is allocated to host the uncompressed initramfs (aka cpio archive).
The RNG_test.gz.sh (906 KB) is 1366 KB lighter than the original, as much as the bzImage. Indeed, RNG_test requires a lot of RAM when working versus which the gzcmd saving isn't relevant but the rationale remains, presented here as a practical example.
However, using gzcmd executables make sense only when a storage is available. Otherwise there are two copies in RAM, at least. After all, gzcmd.sh exists as an alternative to compressed archives and initramfs is nothing else than a compressed cpio archive.
In this specific system configuration kernel is compiled in such a way that uChaos is the only source of entropy available (and just for seed the internal crng once) by loading the module which needs to hack the kernel internals because backport fix from 6.x left a corner case uncovered.
It is worth to underline that this choice is not suggested as per a standard case use of uChaos but it is necessary for testing uChaos/crng duo excluding every possible internal source of interference: if it doesn't fail, it isn't because other sources of entropy are supplying.
It is essential to underline that uChaos at the time of this text first writing (v0.6) was a 7½-weeks long project developed by a single person (started on 2026-01-26) while the randomness in kernel space is a decades long team collaboration project. Hence, the same results in the same conditions, whatever confirmed, isn't something trivial to achieve.
Last but not least, the chaos engine is exactly the same in kernel and user spaces: the same uchaos_dev.h translated in userspace by trivial macros. It compiles twice, and the two binaries never misalign: same file, same code. Audited once, it runs everywhere.
Warning
Due to the recent and unusual network failures of the open source mirrors placed across the ocean, make sources might need to be executed a few times before complete correctly and in full. Tarball repositories aren't related with this project or github, but run by 3rd parties. Edit cnfg/Makefile.musl or musl/Makefile and choose your geographically nearest mirrors for the best download performances.
url="github.com/robang74/uchaosys.git"
git clone https://$url --jobs $(nproc)
cd uchaosys
# git switch ${branch:-main}
# make copysrc FROM=$prevpath
time make sources
# real 2m42.075s
time make buildall status
# real 19m13.068s <-- everything since v0.6.9
# to run uChaoSys on u/qemu
make runqemu
# to test self-hosting u/qemu
make qemutest
# function for further tests
p8() { parallel -j8 "kdev/uckaos 16384" ::: {1..8}; }
# to test speed and DRAM tail slayer jittering
p8 | dd bs=1M of=/dev/null
#> Init mts 4096B access x7 times: 90 < 983.1 > 4635 nS
#> Init mts 4096B access x7 times: 81 < 859.9 > 4115 nS
#> Init mts 4096B access x7 times: 56 < 628.0 > 3053 nS
#> Init mts 4096B access x7 times: 56 < 679.4 > 3236 nS
#> Init mts 4096B access x7 times: 56 < 637.0 > 3100 nS
#> Init mts 4096B access x7 times: 83 < 866.1 > 4054 nS
#> Init mts 4096B access x7 times: 91 < 891.4 > 4156 nS
#> Init mts 4096B access x7 times: 83 < 880.6 > 4171 nS
#> 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 15.2865 s, 70.2 MB/s
# QA w/ RNG_test using PractRand version 0.96
p8 | prnd/RNG_test stdin64
#> ...
#> rng=RNG_stdin64, seed=unknown
#> length= 1 gigabyte (2^30 bytes), time= 14.6 seconds
#> no anomalies in 227 test result(s)The instructions above are able to provide the same output in about 20m, depending on the download transfer rate, unfortunately these days many GNU repositories are experiencing severe downtime.
- uchaosys snapshot folder for bzImage + initramfs v0.6.3 w/ uqemu v0.6.6 glibc-musl static elf64
Considering that the system footprint is below 2MB, offering a binary sample makes sense independently from the outages. This snapshot is not supposed to be updated often, therefore refers to the above project link.
- μ-footprint hacked qemu edition host page, last version
Since v0.6.5 this project also provides the option of compiling an experimental frankenstein glibc-musl static edition of the qemu-system-x86_64 binary (v0.6.7: 7264 KB, -3% minz w/lto) which uses a subset of ROMs (488 KB, tgz: 272 KB).
FILE: 'qemu-system-x86_64.gz.sh', HEAD: 1392 (4), GZIP: 2656031 (2594 Kb, 35 %), GZSH: v0.1.6
FILE: 'RNG_test.gz.sh', HEAD: 1384 (4), GZIP: 927519 (906 Kb, 39 %), GZSH: v0.1.6
It is worth to note that the whole package uChaoSys + u-QEMU + RNG_test once compressed – by gzcmd.sh in a self-executable or by gzip into the initramfs.cpio.gz – remains under 6MB (precisely 5.44 MB).
The result above has been achieved in 7-days from the initial commit of this project. Here below after 1mo:
Pre-Kernel boot time related to qemu, KVM and bios/roms is:
0.251 / 1.896 = 0.13 s→ total:0.298 s(verbose printouts on the console)0.219 / 1.896 = 0.12 s→ total:0.208 s(quiet, boot data collection by dmesg)
Printouts on the console are responsible for not less than 1/3 of the boot time !!!
virt/qemu-system-x86_64 -m 32 -kernel bzImage -initrd initramfs.cpio.gz \
-nographic -vga none -display none -no-reboot -name tinylnx -enable-kvm \
-cpu host,migratable=off,+invtsc -overcommit mem-lock=on -append 'quiet '\
'HOST=x86_64 root=/dev/ram0 init=/init console=ttyS0,115200n8 net.ifnames=0 '\
'nokaslr' -M q35,accel=kvm,usb=off,vmport=off,dump-guest-core=off -boot order=dcThe overall license for the uChaoSys binaries is dependent on the system components thus the GPLv2 is the reference as the most demanding license among those involved as long as "GPLv2 or later" means GPLv2 as an option.
