Finding the Bottom Turtle
blog.dave.tf
blog.dave.tf
You can't and don't "bootstrap" even your bread, which is one of the simplest and oldest human technologies. Bread is said to take flour, yeast, salt and heat. You don't "bootstrap" your yeast culture and your grain culture - you get them from some source. You are handed over the recipe and these living cultures from people who have been doing it before, and you start from that (you can experiment with changes to that of course). Of course the technology changes, but there's still a tradition and will always be.
What matters practically is that we have a variety of living software cultures and traditions to choose from to consume, to conserve and to pass on.
How do you get your first batch started? Must be you rely on the fact that
> Flour naturally contains a variety of yeasts and bacteria
https://en.wikipedia.org/wiki/Sourdough#Starter
So you either take your starter from somebody else or you fall back to a lower-level prerequisite of dormant living organisms present in your flour, and you hope they are alive and good for your end product.
It's not that hard to imagine that these bacteria are killed by irradiation, or are "compromised by perfectly placed state-level adversary".
Grain is different.
And the whole GNU project was bootstrapped by what was going on at the MIT Media labs etc. etc.
You do not have to buy them. You get them from the grain. But I agree with you though. It's basically bootstrapping, because they are everywhere around us.
-Sagan
Of course it doesn't mean that at all. We often use it to mean "from nothing", but it doesn't mean that either. It means "from the beginning" or "from the starting line" (which might be a scratch in the ground). And of course that starting mark is movable, so one can get closer or further away from the ideal of "from nothing" and still make something "from scratch".
Wait, what? It is super simple to bootstrap your own yeast culture. You just need wheat, water, and time. You can easily grow your own wheat. The only way this is not bootstrapping is if I need to create my own water out of hydrogen and oxygen and my own wheat by… actually I’m not sure how one would bootstrap wheat. Find some of the original wild plants that served as the original source of our current domesticated wheat and re-domesticate it? But that would literally be impossible, thus making the term bootstrap meaningless in this case.
AFAIK research into origins of life is stuck somewhere around the GNU Mes level now. We know of the weird mutual dependency between proteins and nucleic acids (RNA and ribosomes in particular), but noone figured out how to kickstart the process from one turtle deeper yet.
Biology is still waiting for its "stage0".
It makes me excited that we're still so close to the origin (of computing) that such questions are vaguely tractable.
> The same holds for the genome. To create a new ‘binary’ of a specimen, a living copy is required. The genome needs an elaborate toolchain in order to deliver a living thing. The code itself is impotent. This toolchain is commonly called ‘your parents’.
You’re a western signals intelligence agency with virtually unlimited budget and access to some of the brightest mathematical minds on the planet. Your goal is to evaluate the viability in systemic compromise of virtually all compiler infrastructure used in modern computing to the point where verifiability becomes all but impossible, as theorized in the article.
How would you even go about that? What would the modifications look like? How much foresight would you need? Is it even a worthwhile goal, let alone a feasible one?
In practice, you’re probably just going to compromise the proprietary platform security modules instead. There, you can use undercover or otherwise sanctioned employees at semiconductor companies backed up by offensive cyber on a continuous basis. From that offensive vantage point, you’re able to compromise most compilers in use today.
If those miraculous Mes binaries devoid of any available source were in fact compromised, I suspect at best they’d be relics of a chess game that started long ago and is still being played today, with the binaries themselves no longer relevant.
Rather than some deliciously diabolical compromise at the lowest levels of the software stack from which all further compromise flows (a single turtle), a more pragmatic view might hold that systemic compromise may be more akin to architecting turtle contagions and ensuring their continuous delivery. Compilers are just one vector in achieving that end.
An even more pragmatic view might hold systemic compiler compromise (i.e. compilers indiscriminately compromising other compilers) is not undertaken for all manner of reasons.
That's the real problem. It's practical to bootstrap software in surprisingly few steps. There are people who can write assembler that can do a basic C compiler, from which we can get a full C compiler, from which the world is our oyster. I'm not that good in assembler myself but I could bootstrap from nothing in another couple of intermediate steps (and a whole bunch of time). Then on top of that you have things like NixOS and Debian pushing for full reproducability, which isn't a panacea on its own but means we get further visibility into what builds produce, and makes it more worthwhile to do a full software bootstrap because it extends the assurance out that much farther. If there is in fact an ancient buried trapdoor in our compiler stacks, whoever put it there better start trying to remove it because it's probably getting close to being discovered. I don't think there is one, but the amount of room for it to hide in is rapidly shrinking.
But that does nothing about the hardware that has a backdoor into reading the contents of my harddrive and shoveling them out over Wifi to some arbitrary network destination if the right network packets arrive at my Wifi adapter. My software will never even see these magic packets because the hardware will never deliver them.
I bootstrapped Go 1.14 for FreeBSD 8, with a couple of patches for older syscalls, but I didn't go as far as bootstrapping GCC. I wanted to build a tool that would automatically bootstrap Go (gc and gccgo), but I lost momentum before finishing.
More recently, I bootstrapped Rebol 3, which is a self-hosted compiler, but I couldn't get to the bottom turtle since old versions were closed-source.
You need insulated wire, saturable cores, some various passive components, and a large 2 phase power source. (You likely could use a modified car alternator, then upscale to about 1 Mhz clock rates)
It was done before, most (not all) of the logic was magnetic. https://en.wikipedia.org/wiki/UNIVAC_Solid_State
I imagine a tiny Forth, which interprets larger Forth, which implements C enough to compile old TinyCC/GCC and start the chain of rebuilds (as explained in stage0).
As for hardware, a schematic for Forth would be simpler than schematic for generic RAM machine. But if not, intermediate minimal RISC-style machine language is still fine.
Steps to reach that level of hardware are already describe in NandToTetris, so in the end anything capable of implementing NAND/Fanout/Wiring can be used to run bootstrap chain.
Then we only have to make sure HW and SW implementers don't introduce bugs.
Even the first hobby computer had a front panel. The Apple 1 was a user-friendly improvement in that regard.
i.e. build a minimal, very small, inspectable relay computer as an initial bootstrap step.
But who verifies the verifier? ;)
Clock them in a checkerboard pattern to eliminate race conditions
A B A B A B A B
B A B A B A B A
A B A B A B A B
B A B A B A B A
However, you give up everything you're used to inheriting from Von Neuman in the process.
This was more of a necessity than something done for verifiability though. Systems were more diverse back then and you couldn't just target "a Unix with a C compiler".
I'll just leave these here..
I think one could keep following the turtles right down to the silicon...
This is why the whole thing seems like an exercise in futility to me. Just trust a reasonable base (e.g., including the OS) and call it a day. If you can't even trust your vendor to give you trustworthy firmware then find some way to invest $N Billion into your own fabrication labs to make your own chips in front of your face.
And, if you do care about trustable hardware... There are bootstrapping and verification paths available there as well, depending on your threat model.
Or you can of course give up and declare all of computing fundamentally untrustable but still useful for some purposes. Like I said in the post, I'm glad for the existence of both the purists and the pragmatists in this space.
https://puri.sm/products/librem-key/
Interception and firmware replacement is a thing. It happens. One could thus trust the hardware but not the firmware.
Similar, the lower down you go, the harder it is to put that kinds of smarts in.
That might be one reason to stop at this point? (Not sure.)
Solving the hardest problem (or what appears to be it) does not mean that everything else is tractable. In this case, the sheer size of the problem means that it is beyond the scope of one person [1], so the problem becomes one of who you trust, not what you trust.
I think we all knew it was going to come down to this; how does bootstrap.org deal with it?
[1] I'm putting aside the problem of verifying the design of what the fab makes, of the fab itself, and the trustworthiness of the people building and operating it, which is, as you suggest, 'just' another heap of turtles.
It'd be nice if there was some form of homomorphic compute analogue to public-key/private-key encryption to allow for IO channels, but I'm not sure if that's possible.
Somewhat uselessly, if ever you do actually find the bottom turtle, it's impossible to tell that it really is the bottom - and that holds true right down to the universe itself.