Hacker News Reader

Comment by funkisjazz | Hacker News Reader

is it practical in any way?

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.

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.

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.

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.

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

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/

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

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").

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)

At one point a variation of it could compile a Linux kernel (very fast too!) and boot from the same ISO. Of course GCC or LLVM produced better optimised code, but TCC, being so small runs so much faster.

Another practical application is using tinycc as a backend compiler for Nim [1]. I set up my nim.cfg to default to this for a rapid edit-compile-test cycle (usually under 250 millisec), with a quick define switch to move to gcc-optimized code.

Similar is likely possible for other prog.langs that emit C.

One helpful feature for the full round-trip to an executable file is a built-in object file linker.

Also, libtcc can be used as a library to "compile a string" and then run it which is the JIT application mentioned elsewhere in this thread.

[1] https://nim-lang.org

Yes, for winning IOCCC competitions! Which would normally be a great CV badge to demonstrate your skills to prospective employers, but likely of little consequence if you're Fabrice.

> Which would normally be a great CV badge to demonstrate your skills to prospective employers

Not many employers would know of the IOCCC.

> Not many employers would know of the IOCCC.

Sure. But who wants to work flipping burgers, greeting shoppers, or doing web front-ends for the rest of their life?

If you have the sort of brain that makes winning IOCCC entries, it is highly probable that a candidate employer who has not heard of it is not, in fact, prospective.

Anyone interviewing an IOCCC winner probably has.

can confirm

source: won the IOCCC

It's probably of little consequence for his employment, but Bellard has won a few IOCCC prices: https://www.ioccc.org/winners.html#B

Android once included a library "libacc", (the Android "Almost" C Compiler") which was based on the deobfuscated version of this.

https://android.googlesource.com/platform/system/core/+/ecla...

It isn't as it compiles a subset of c. Nonetheless it's a gem!

Reply on news.ycombinator.com