IRC channel logs
2026-03-17.log
back to list of logs
<aggi>ok, got a tcc-head (0.9.28rc) linked against a live-bootstrap musl libc.a - and it seems to be self-hosting and working _without_ those extra passes involving 0.9.26 <aggi>other than problems which tcc-head might have had preventing a patch-rebase for the pnut-exe|mes-cc transition, this could help a bit to clear things up in the future <aggi>ideally, there was one version of tcc involved (regardless of various steps/ and transitions), instead of two versions <aggi>for tiny-bootstrap now there's is only one occurence of tcc-0.9.26 remaining, that's the one for pnut-exe|mes-cc -> tcc-0.9.26 -> tcc-head <aggi>i'll reconfirm and zip all those tcc/musl-libc related passes, and then git push a few more tiny-bootstrap/steps-tiny to codeberg <aggi>will take a little while longer to review all this <aggi>busybox-1.2.2.1: build successful <aggi>for simplicity it's linked against tcc-head (instead of mes-libc which i had preferred) <aggi>have to clean-up a little chaos, then do the yasm/as86 steps/, then linux-tcc 2.4 kernel <aggi>need some sleep before git-push <aggi>*linked against musl-libc with tcc-head <aggi>neat thing with linux-tcc/busybox, this got the crucial pieces for networking,sata,usb,smp ready far earlier with MUCH less lines of code <aggi>i'll too review and test the _complete_ live-bootstrap with python/gcc/binutils once only againt tcc-head, then tag this, and then won't bother with this anymore for myself <aggi>the real problem remaining then, i've got another 500ebuilds forked for tcc, which are deeply entangled into gentooism/bashism/git-9999 builds <aggi>apropos, git, that's missing completely with live-bootstrap, but a must-have with tiny-bootstrap <aggi>and this pulls many pieces, such as curl,libressl and a few more, lots of work <aggi>nowadays, i think live-bootstrap is the only sane option remaining of rolling a "distro" <aggi>i was thinking about cross-compile scenarios again, that's related to the QEMU issue when backporting this to linux-tcc 2.4 kernel <aggi>for practical reasons, if that was the development host to test for foreign ARCH such as riscv64 <aggi>currently it is impossible to pull in QEMU as dependency early with a small dependency graph (an old version 0.14 passed compile-time against linux-tcc 2.4 only) <aggi>which means, bootstrapping such, for testing inside chroot, ALWAYS needs a gigantic beast of dependencies pulled into for linux5/g++/etc. to use qemu-binfmt <aggi>there won't be steps-tiny/qemu-0.14 for a while (because i'm not using qemu myself, and gave up on any other ARCH than x86_32 anyway) <aggi>for historical reasons i've sent the qemu ebuild/patches for this to tinycc-devel few days ago <matrix_bridge>Hex seeds are written in ASCII and then decoded. What if I just committed binaries into source control, but the tooling around the binaries allows for adding comments to express intent? Imagine, in git you see clean diffs that look like commented assembly with labels and everything, but underneath it's just binaries with some structured comments. <matrix_bridge>The idea that we need a "hex monitor" in the first place might be a flawed assumption. I dunno, I'd love to hear y'all's thoughts. <matrix_bridge><wildwestrom> Git diff drivers solve the problem of Jupyter notebooks having unreadable diffs, so why not do the same for machine code? <Googulator>wildwestrom: how do you know the tooling isn't compromised? <Googulator>A tool for rendering a commented binary could have hidden code to detect compromised binaries and show their innocent versions instead. <matrix_bridge><wildwestrom> Googulator: Here's the thing. We rely on tooling in order to author hex code. Text editors, the default git diff. They too can be compromised. <matrix_bridge><wildwestrom> I suppose it does beg the question, what comes next? <matrix_bridge>Like, what's the first binary you load onto bare metal if not a hex monitor? I haven't thought that far. <matrix_bridge><wildwestrom> Here's the thing. We rely on tooling in order to author hex code. Text editors, the default git diff, xxd. They too can be compromised. <matrix_bridge><wildwestrom> With "hex0" you can in theory type machine code via a keyboard very carefully and without an actual monitor. I don't have an answer for an alternative. <matrix_bridge><cosinusoidally> wildwestrom: hex0 code can be written with pen and paper. In theory you could then get the initial code into the computer via an eprom (that has been programmed by a panel of toggle switches). Easier said than done with modern machines, but in theory possible. <matrix_bridge><cosinusoidally> In practice at the moment stuff like live-bootstrap assume you have the ability to write the initial code onto a hard disk directly (and assume you can trust the bios). <matrix_bridge><cosinusoidally> Just thought, older chromebooks might actually be a good candidate for bootstrapping all the way down to the bios. I remember my old chromebook (asus C720) had an open source bios, and was easy to reflash with a spi flash programmer that clipped onto the bios eprom chip. <matrix_bridge><wildwestrom> Open source BIOS on an x86_64 machine? That's huge! <matrix_bridge><Jeremiah Orians> You don’t need a full bios, just a handful of bios interrupts used by builder-hex0 at the upper end or if you wanted to really reduce the size, just 2 interrupts but 4 would be easy enough <matrix_bridge><Jeremiah Orians> Also one could bootstrap from a 6502 or any 8bit architecture of their choosing. <matrix_bridge><Jeremiah Orians> Hex0 to M0 can be done directly on bare metal on a TTL or computer made of individual transistors if one wanted and M0 is a pretty good assembler that can build a BIOS with just a couple KB of memory <matrix_bridge><Jeremiah Orians> At which point you need only build a Ben Eater 8bit computer and use punched paper tape or magnetic cassette tape to store your source files and built binaries and then you can build a full x86 bios to complete the chain <Googulator>Also, a while back I wrote a PoC of a modified builder-hex0 where the stage 1 binary (boot sector) printed out the text of stage 2 as it compiled it. It's similarly possible to add printouts to stage 2 as it loads srcfs (skipping over any tarballs, which would instead be printed to screen during extraction by mescc-tools untar), and then the <Googulator>printed output can be recorded in an analog way, e.g. via an actual printer/TTY, or by recording RS-232 or VGA to analog tape, guaranteeing that the record is faithful to what was actually executed. <matrix_bridge><wildwestrom> Jeremiah Orians: Using a computer you built yourself is a pretty good way to get to rock bottom in terms of trust. <Googulator>This way, the only thing you need to trust is builder-hex0 stage 1 - any backdoor there would need to fit in 512 bytes, assuming you defend against a compromised host computer writing more than 512 bytes of binary, e.g. by storing builder-hex0 on media that physically can't store more. <matrix_bridge><wildwestrom> My plan was to use a RISC-V microcontroller and do I/O via UART. Right now I have tests running through QEMU this way. <matrix_bridge><wildwestrom> Googulator: This is a good idea. Printing back the output. <Googulator>Once Bash is built, all of this automatic printing can stop, as Bash can spawn an interactive terminal where you can review code before it runs. <Googulator>The key part is that you can only trust printouts of code that has not run yet - otherwise, compromised code could interfere with the printing functionality to print its own innocent version, Trusting Trust-style. <matrix_bridge><wildwestrom> My whole idea/hunch right now is that lexing and parsing plaintext kinda sucks. Ultimately any format your serialize into will have to be deserialized in some way, but ASCII text? And at each stage? I think structured editing is the way to go, but that's another story. <aggi>3.5" floppy disks had one great feature: READ-ONLY switch for the boot-medium <aggi>CD-ROM is an option too, live-bootstrap is missing app-cdr/cdrtools <aggi>mkisofs does NOT need Perl nor autotools (isohybrid is a perl script, but if you skip usb-flash and burn onto cd-r or dvd-r that's a non-issue) <aggi>i'll probably tailor tiny-bootstrap for dvd/cd-r to bundle all distfiles and the bootable system <aggi>builder0 probably can't handle iso9660, fiwix can (don't know yet)