Hacker News Reader

Comment by tcoppi | Hacker News Reader

An interesting experiment would be to see if a modern, easy(relatively) to audit compiler like tcc can still be used to bootstrap a more full-featured compiler like gcc or llvm. That would provide at least some protection against this, in that it is unlikely a backdoor in your binary version of gcc will have a trusting trust backdoor for tcc, which can then compile a clean gcc.

I know this was possible in the past, but I'm not sure if tcc can still compile a relatively new gcc.

View on HN

Better off making it close to but not C language so it's easy to compile. A language easy to compile + easy to write a compiler in. Scheme and ML are probably ideal for the compiler + verification part given I've seen it done already down to machine code in relatively few pages of text. Not C-like, though.

Best method I can think of is assembly writes a macro assembler that writes compiler for simple, high-level language which is used for the first, C compiler. That compiles the complicated, optimizing one. HLA, a P-code variant, and Hansen's Edison are all potential contenders for low-level language. An Oberon-like language with something closer to C syntax & Wirth-style compiler might do for initial, high-level language. tcc or QBE backend have potential for simple, initial, C compiler. I'd do both LLVM and GCC for last step as good projects rely on each.

If one wanted to spend money, then license CompCert, extract it to ML, compile with CakeML, verify each function against assembly, and equivalence check everything with testing. CompCert verifies C to ASM with its outputed ML verified by CakeML assuming their specs are correct. Easiest cheat. Use CompCert to compile first C compiler, the main C compilers, or anything else you can.

This particular attack is done entirely in the rustc frontend, so adding another way to build the backend shouldn't matter? One requires a new implementation of the frontend to apply diversity mitigations.

Which makes me wonder if Miri ( https://github.com/solson/miri ) counts as an alternate implementation of the frontend. Combined with, say, Cretonne ( https://internals.rust-lang.org/t/possible-alternative-compi... ) I wonder if we couldn't cobble together an alternate frankencompiler for mitigating RoTT.

You need to generate the MIR though (to feed to miri); this only fixes attacks that happen in the pipeline after MIR. Doing path and type resolution is the tough part and so far we only have one implementation of that.

https://github.com/thepowersgang/mrustc exists, anyway. I don't think it can compile rustc yet.

Reply on news.ycombinator.com