3 ms·

Mike Pall somewhat famously wrote a Lua interpreter in assembler. Assuming that you can write a compiler for your language in Lua, you don't really have to trus

by scythe 3y ago

Mike Pall somewhat famously wrote a Lua interpreter in assembler. Assuming that you can write a compiler for your language in Lua, you don't really have to trust trust, but you do have to trust Mike Pall. I'm not aware of any other raw assembly implementations of modern programming languages, but I suspect there are other examples. The overall scheme (^,~) could probably be replicated by a sufficiently dedicated team if there was interest. Not exactly easy, but probably easier than a decompiler that produces human-equivalent source code.

dev_slash_null 3y ago
You still have to trust your assembler and linker in that case.
- scythe 3y ago
  In tune with the parent's point about decompilation, the transformation from assembly to machine code is more or less completely reversible and often local, allowing the assembly to be tested in chunks that are less detectable. Linking is also "reversible", though attacks on the linker are actually much more common in practice than attacks on the compiler (LD_PRELOAD injection etc). So the verification he was concerned with becomes much easier when using assembly for bootstrapping.
dzdt 3y ago
The C4 compiler [https://github.com/rswier/c4 https://github.com/rswier/c4] is a self-hosting compiler for a subset of the C programming language that produces executable x86 code. You can understand and audit this code in a couple of hours (its 528 lines). It could be an interesting exercise to bootstrap up from something like this to a working linux environment based solely on source code compilation : no binary inputs. Of course a full linux environment has way too much source code for one person or team to audit, but at least it rules out RoTT style binary compiler contamination.
- tedunangst 3y ago
  It's an interpreter.
tetha 3y ago
Now this has me wondering if we should write more useless software. In this case, specifically, more terrible compilers and interpreters. Like, sure, technically, everything could be backdoored, but what if there are a whole bunch of C-compilers written by amateurs in languages ranging from assembly to python to Haskell to Common Lisp? Good luck compromising all of them.

by scythe 3y ago

dev_slash_null 3y ago

You still have to trust your assembler and linker in that case.

scythe 3y ago
In tune with the parent's point about decompilation, the transformation from assembly to machine code is more or less completely reversible and often local, allowing the assembly to be tested in chunks that are less detectable. Linking is also "reversible", though attacks on the linker are actually much more common in practice than attacks on the compiler (LD_PRELOAD injection etc). So the verification he was concerned with becomes much easier when using assembly for bootstrapping.

dzdt 3y ago

The C4 compiler [https://github.com/rswier/c4 https://github.com/rswier/c4] is a self-hosting compiler for a subset of the C programming language that produces executable x86 code. You can understand and audit this code in a couple of hours (its 528 lines). It could be an interesting exercise to bootstrap up from something like this to a working linux environment based solely on source code compilation : no binary inputs. Of course a full linux environment has way too much source code for one person or team to audit, but at least it rules out RoTT style binary compiler contamination.

tedunangst 3y ago
It's an interpreter.

tetha 3y ago

Now this has me wondering if we should write more useless software. In this case, specifically, more terrible compilers and interpreters. Like, sure, technically, everything could be backdoored, but what if there are a whole bunch of C-compilers written by amateurs in languages ranging from assembly to python to Haskell to Common Lisp? Good luck compromising all of them.