[wolf550e]

Suppose you want to defeat a "Reflections on Trusting Trust" attack and bootstrap a toolchain source code you believe is clean to produce binaries that are clean. You need to compile llvm/clang (or gcc). You start with something small you can audit manually, use it to build binaries that can compile llvm, then use llvm to build itself to get an optimized compiler that doesn't have malicious code to recognize the password check inside the login binary and emit machine code that is not faithful to the source code.

[ducktective]

Interesting! Still, I believe this doesn't prevent malfunction resulting from a compromised silicon...Like a sequence of instruction executions or memory accesses resulting to sending over a packet via the network.

I wonder how can one prevent that? Even an open-source ISA could not be fully trusted since one can't know what is implemented on the actual die on hand.

[LeifCarrotson]

It's true that the silicon is hard to audit, but it's also pretty static, and there's a huge variety of pretty effective obfuscation that can live on top of the silicon. The

You suggest that an adversary could use some compromised layer to send a packet over the network when something happens. For example, someone running `aesenclast xmm15, xmm10` could also secretly trigger a socket()/send()/close() syscall set that would transmit a packet over the network adapter. But what if the target code never calls the AES-NI instructions? A user could easily be using a library that processes the encryption in software; a simple ISA filter has an impossible task to determine which xor instructions are cryptographic and which are just ordinary compiler output. You could be running a virtual machine, in which you've loaded a browser Javascript engine, and using that Javascript engine to run a virtual machine (https://bellard.org/jslinux/), in which you're running a Python instance, which is finally performing the encryption.

Sure, if all those layers were efficient, they'd just pass it down the stack to eventually call `aesenc`, but modern software is anything but efficient. Yes, if your deeply nested Python calls "sum = num1 + num2", the x86 `add` instruction likely gets invoked somewhere, but to predict when some client code is handling a secret key or when some user input is actually a password seems really difficult.

[archi42]

tl;dr of a pamphlet I decided not to post: If you're [seriously] considering anything beyond "my firewall is strictly unable to report it", you're either building something like nuclear weapons or taking the first steps to sliding down the rabbit hole of paranoia, ending up in tinfoil-hat-wonderland ;-)

The topic is interesting from an academic point of view. Maybe something along "On trustworthy, verifiable execution on untrusted, adversary hardware". Like homomorphic encryption, but I think having the user supply the input would make for a difficult programming+debugging cycle :P

Anyway, the goal of this compiler here isn't to prevent ANY kind of attack. As the page says, it is "only" a tiny C compiler, and an obfuscated one at that. The "tiny" part makes it much easier to audit than say GCC or clang (and you don't need to audit GNU binutils, either - and I've seen that code, so trust me when I say: You don't want to go that route).

//edit: Obviously I don't want to insult the fine folks investing their time into projects such as binutils, they deserve quite some praise - but as someone who is not familiar with the code base I found it to be very overwhelming.

[Drakim]

How do you know that your text editors aren't compiled to hide the payload when examining this compiler, thus perpetuating the hidenness?

[xmodem]

If you wanted to solve for that, you would have to build a computer like the monster6502 [1] to run the compiler on, and visually inspect the memory contents.

1: https://monster6502.com/

[MawKKe]

How do you know the person who designed that isn't in on it?

[archi42]

The thing is pretty easy to verify.

The ultimate question is: How far do you need to go until you believe that the earth is indeed not flat? Do you trust your teachers? Stand on a tall building? Take a balloon ride? A plane? A spaceship? Then still, at which point can you rule out that the earth just appears to be a ball due to some yet-to-be-explained phenomenon (gravitational anomaly?) but is indeed flat? (The correct answer of course is "turtles all the way down").

[xmodem]

For some definition of 'easy', yes. You still need to know a lot about how a CPU works. I think a project to bootstrap a PC with code generated from a completely verifiable platform would be really cool, but in practise would be of limited usefulness above and beyond secure boot we already have, because you're still trusting all the binary BLOBs you can't control (BIOS/UEFI, Intel ME, microcode, etc)