Comment by ludocode | Hacker News Reader

Comment by ludocode | Hacker News Reader

Parent Full thread

The team at bootstrappable.org have been working very hard at creating compilers that can bootstrap from scratch to prevent this kind of attack (the "trusting trust" attack is another name for it.) They've gotten to the point where they can bootstrap in freestanding so they don't need to trust any OS binaries anymore (see builder-hex0.)

I've spent a lot of my spare time the past year or so working on my own attempt at a portable bootstrappable compiler. It's partly to prevent this attack, and also partly so that future archaeologists can easily bootstrap C even if their computer architectures can't run any binaries from the present day.

https://github.com/ludocode/onramp

It's nowhere near done but I'm starting a new job soon so I felt like I needed to publish what I have. It does at least bootstrap from handwritten x86_64 machine code up to a compiler for most of C89, and I'm working on the final stage that will hopefully be able to compile TinyCC and other similar C compilers soon.

So bootstrap in freestanding does make this kind of attack much more difficult to pull off, but with contemporary hardware, it does not fully prevent the attack.

What if the trojan is in microcode? No amount of bootstrap in freestanding can protect you here.

It is true that there are many layers of code below the OS level. UEFI for example is probably hundreds of thousands of lines of compiled code. Modern processors have Intel IME and equivalent with their own secret firmware. Almost all modern peripherals will have microcontrollers with their own compiled code.

These are all genuine attack vectors but they are not really solvable from the software side. At least for Onramp I consider these problems to be out of scope. It may be possible to solve these with open hardware but a solution will look very different from the kind of software bootstrapping we're doing.

Boot from obfuscated VM running on a FPGA softcore?

Maybe on two completely different ones and verify for differences.

Correct me if I’m wrong, but isn’t this recreating a thing that used to exist? I have memories of being told of a compiler older than GCC that could compile itself using… I want to say a bash script. It took forever to run because you had to run the script which of course was slow, and then it output a completely unoptimized compiler. And if memory serves that output didn’t have any of the optimization logic in it. So you had to compile it again to get the optimizer passes to be compiled in, then compile it again to get a fast compiler (self optimization).

Impressive work and truly necessary! Thanks for sharing.

really nice, and impressive work. However, I'm left wondering if a route via Forth would not have been a lot shorter.

Reply on news.ycombinator.com