>On Sun, 12 Jul 2026 18:29:44 +0200 >[email protected] wrote: > Is there any other reason than to avoid the "trusting trust" compiler > backdoors, to pursue the bootstrapping which you envision?
From time to time, people invent new computers. Including new ISAs, but also brand new system architectures (well, nothing is really new, fifties and sixties offer a goldmine of interesting computing ideas). These new computers require bootstrapping software onto them. Sometimes, the systems are specifically designed, for their own reasons, in a way that breaks the assumptions of current POSIX environments. In these cases, bootstrapping is the only option. Alternatively, from time to time people invent new operating systems that they desire to bootstrap. Perhaps because the systems are so alien to the current crop bootstrapping from scratch really is the cleanest way to get going. Next, bootstrapping can be and is a way to instantiate a new system without relying on an interconnected mess of "bloat", as is common in modern GNU/Linux distributions. Bootstrapping implicitly limits the dependency list to a very small number of requirements. This promotes permacomputing. Furthermore, bootstrapping teaches people how to create software without relying on a ready-made computing environment. This is invaluable for embedded system design, or even for building using old technologies. An interesting example of this many people here will probably like is https://www.bdsoft.com/resources/bdsc.html , a C compiler (predating K&R C) for CP/M, that requires you to understand the entire software environment to really unlock it's full power. (There's another, confusingly called Tiny C. And I remember seeing a third C compiler that was also a variation on the name "Tiny C Compiler".) Bootstrapping teaches skills relevant for all these fields. And, to give a nod to the modern world, all of these things have economic utility, especially the last one about teaching embedded system design. > What is wrong with Posix binaries? They are easily available and it > does _not_ matter for the sanity of generated artifacts whether those > binaries were auditable. It matters, but for this you need to go beyond your assumptions. This following section tries to show the limits of VSOBFS, and to make sure I'm not misunderstanding anything, I went to Codeberg to check, but the website tells me "Access denied". Thus, what follows may misunderstand VSOBFS' mechanism of verification but I think it doesn't because hard logic limits possible options to, I think, only the one I discuss below. As far as I understand, VSOBFS builds the same binaries on a heterogenous set of host systems and compares the outputs. If the outputs are bit-for-bit identical, the conclusion is that there were no implants added to them. The conclusion is correct, but only in the confines of it's unspoken assumptions. What are those? The first assumption is that the build fleet has at least one clean (or honest) builder, at least one system that won't inject any implants into the resulting binary. Thus, if any of the other builders adds anything, the discrepancy will be obvious. Even if the human operator doesn't know which particular system is honest and which dishonest, he/she will at least know there is something wrong. But the same outcome can happen in one other situation: if all the builders are dishonest in the exact same way. This is the second unspoken assumption: dishonest system add differing implants. But if they all add the same implant, you will again see identical binaries, but will be unable to detect the presence of the implant in all of them. Therefore, to prevent this failure mode, you *need* a known-clean builder, at least one, in your fleet. Otherwise, you're just assuming things and can't actually *prove* anything to people who don't share your assumptions about your build fleet. But, very important, there is one other failure mode of VSOBFS. What if an attacker wanted to prevent you from having any software at all? Well, all they have to do is deliberately inject a dishonest builder into your fleet, and now your verification fails! Remember, VSOBFS doesn't have sensors able to detect implants. It only detects all builders agree on the output. This is vulnerable to denial-of-service attacks. Furthermore, VSOBFS only works if all 100% of your starting fleet is honest. Otherwise, if you run it for the first time ever, and get disparate output binaries, you do in fact know there's something wrong, but you have no way of knowing, within the methodology of VSOBFS, *which* ones are wrong! Now, maybe you got lucky and didn't have any dishonest builders the first time you did this, but what if somebody else runs it and finds a mismatch? Once again assuming - assuming! - the all-non-mismatched eventuality is a result of honest builders, and not of equally-dishonest builders. -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. --
signature.asc
Description: PGP signature
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
