Comment by BoppreH
2 days ago
The proposed solution seems to rely on a trusted compiler that generates the exact same output, bit-for-bit, as the compiler-under-test would generate if it was not compromised. That seems useful only in very narrow cases.
You have a trusted compiler you write in assembly or even machine code. You then compile a source code you trust using that compiler. That is then used for the bit for bit analysis against a different binary of the compiler you produced to catch the hidden vulnerability.
It's assumed that in this scenario you don't have access to a trusted compiler; if you do, then there's no problem.
And the thesis linked above seems to go beyond simply "use a trusted compiler to compile the next compiler". It involves deterministic compilation and comparing outputs, for example.
Correct. The deterministic comparison is against compiler A compiling itself. Version 1 is compiler A compiling itself with a normal build of compiler A. Version 2 is compiler A compiled with a trusted toolchain. How do you get that trusted first tool chain is a challenge but, for example, you can start with a tiny tiny C compiler (they can be quite small) that’s used to compile a larger c compiler that can compile c compilers and then finally build clang. Then you have a trusted version of clang that can be used to verify the clang binary. From there you just use clang and periodically recheck no vulnerability has been reintroduced.