this post was submitted on 16 Jan 2026
25 points (87.9% liked)
Technology
1356 readers
50 users here now
A tech news sub for communists
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
He talks about this at the very start. It's very easy to insert a backdoor into a compiler and very difficult to find it. The video isn't really about Arch, but the rush to rewrite everything in Rust which is still an evolving language and only has a single compiler implementation. If that gets poisoned then you can poison everything downstream that's compiled with it.
My programming experience was using basic and punch cards to run simple algebraic equations, so most of the article flew right over my head. I guess I must rethink my assumption that open source is some sort of magic wand that limits the damage that can be done by bad actors.
Basically, the breakdown of Ken Thompson's terrifying compiler hack is that you can make a self-replicating backdoor. You poison a compiler, and when it builds programs, it slips in a secret vulnerability, like a hidden login. And of course, when you build a new compiler using it, the instructions to create that vulnerability are propagated into the new compiler's code.
This creates an undetectable chain. Every new compiler inherits the ability to insert the backdoor, passing it on like a genetic trait. You can audit the source code all you want. It will look clean because the poison only lives in the compiled binaries themselves as a legacy passed down from the original infected compiler. And the really scary part is that most compilers are self-hosted, meaning they're built using older versions of themselves, so once the infection starts it spreads everywhere.
All that means you can't trust software unless you fully trust the compiler. And the only way to do that would be hand craft it in assembly since using another compiler can slip in the vulnerability. Our entire digital world rests on a tower of tools we didn't write and can't fully verify. It’s a perfect, ghostly hack because it erases its own tracks from the source code, living on only in the executables themselves.
Your technical prowess in seemingly unrelated topics never ceases to amaze me, comrade.
thanks, I try to keep on top of things :)
Can you explain how evaluating checksum doesn't counter this? I don't know much about this topic but am quite intrigued.
Checksum compared to what though? Like you have to compile the code first, and if your compiler is compromised then all the code it outputs is also consistently compromised. Checksum isn't going to help you here. Literally the only way around this is to build a compiler from scratch in assembly, then use that to compile your code.
Compile the compiler? I presume there is some version that isn't compomised? Or go all the way back to some bootstrapped c compiler?
Like I said, the only way you could really trust it is if you're not using a compile to make it. You have to write a compiler directly in assembly and then use that to compile everything else.
What I'm saying is there is no need to write a whole new compiler in assembly, check out the bootstrapping article I linked.
Or, if there is some uncompomised older compiler version A, and a compromised version B built with A, then the source code for B can be fed to A to create a clean version. As in it might be hard to try to poison the supply chain now, if they haven't already. We can't be sure it isn't already poisoned, but if it actually isn't it's possible to catch such an attack.
The key problem is knowing whether something is compromised or not though, that why you can't use an existing compiler if you want to be sure. Meanwhile, bootstrapping involved building a minimal core in assembly and then progressively compiling the compiler using itself. That's basically how you build a whole new compiler starting with assembly.
Thanks for the explanation. I don't like this. Lmao.
Haha yeah it's not great. Now that I thought about it some more, I wonder if you could use decompiling to verify that the compiler is doing what it says it does. If you compile a minimal program, and then decompile the assembly, you could see if there are any instructions that shouldn't be there. It wouldn't be trivial, but seems like it is a possible way to check that the compiler isn't injecting something weird.
The compiler can introduce vulnerabilities only on some specific instructions, although it makes it difficult to propagate it further to new compilers.
Good point, verifying a disassembled binary wouldn't exhaustively prove the compiler is safe.
I don't know much about Rust, but from the discussion here, I get that it only has one compiler implementation and that it can't be verified. So anything compiled with it is, technically, not fully verifiable. It doesn't matter if the compiler I have on my computer is exactly the same as the one provided by the Rust devs (which is what checksums do), if the one provided by them is already tampered with.
Right, but really the problem goes beyond Rust itself. Other compilers could be compromised as well. Of course, when you have multiple compiler implementations, the situation is better because you can compare differences in binaries they output. Another approach you could take is to make am minimal program and decompile it, and see if there's anything funky.
I think the simplest benevolent example of this is what I call "the newline virus".
Basically, in most programming languages you represent the newline character inside strings with the escape sequence
'\n'(or equivalent), so naively you would expect to see a statement translating'\n'into its ASCII code10somewhere in the source code of the compiler, like this:but most likely, it will just say something like instead:
That is, the fact that
'\n' == 10is nowhere to be seen!You only need the initial version of the compiler to state it explicitly, all future versions can rely on the previous compiler doing the right thing.
yeah great example