4 ms·

I don’t see it either. The paper specifically talked about modifying the source of the “root” compiler, and then using it to compile the system compiler. This

by Cyph0n 8y ago

I don’t see it either. The paper specifically talked about modifying the source of the “root” compiler, and then using it to compile the system compiler. This can be generalized to N compilers, so to truly claim that your compiler is safe, you’ll need to verify the source of all compilers in the chain. I’m not an expert, so please correct me if I’m off here!

coldtea 8y ago
Assembler is pretty trivial to translate to machine code (and can be even written so that it's 1 to 1 per line). Theoretically (not very practical due to size) you could translate the compiler text that you see to machine executable code yourself, looking at some opcode reference.
- WalterGR 8y ago
  While that’s true, I don’t believe that’s the approach we’re discussing here.
  - WalterGR 8y ago
    Apologies, maybe that is the approach we’re talking about here, and I’ve simply confused myself. :) OP: If you have the source compiler, which is itself bootstrapped from source, then you effectively sidestep the problem brought up in the paper. So does that translate to English as: You have the source code for a compiler. You’ve ensured that the source code isn’t tainted in any way. If you translate that source code into an executable binary by hand, then you know that binary isn’t tainted. And subsequently, that binary won’t taint its output. ? Hmm. That just doesn’t seem interesting. And, as you say, “Theoretically... you could...”. Emphasis mine...
WalterGR 8y ago
I think I’ve resolved my confusion (see my updated response to coldtea.) I think you’re 100% correct. This result just doesn’t seem interesting. Not only do you have to verify the source of all compilers in the chain, you need to ensure that - when that code is compiled - it’s the exact source that was verified. And even then, how do you know that the disk firmware actually gives you that non-tainted compiler when you ask for it? But: I guess it’s turtles all the way down. This at least theoretically improves how much of the chain (from atoms on a disk to the binaries produced by your Nth compiler) is non-tainted.
pygy_ 8y ago
Don't forget the CPU, which can also be malicious. That being said, that problem can be worked around by throwing interpreters into the mix.

by Cyph0n 8y ago

coldtea 8y ago

Assembler is pretty trivial to translate to machine code (and can be even written so that it's 1 to 1 per line). Theoretically (not very practical due to size) you could translate the compiler text that you see to machine executable code yourself, looking at some opcode reference.

WalterGR 8y ago
While that’s true, I don’t believe that’s the approach we’re discussing here.
- WalterGR 8y ago
  Apologies, maybe that is the approach we’re talking about here, and I’ve simply confused myself. :) OP: If you have the source compiler, which is itself bootstrapped from source, then you effectively sidestep the problem brought up in the paper. So does that translate to English as: You have the source code for a compiler. You’ve ensured that the source code isn’t tainted in any way. If you translate that source code into an executable binary by hand, then you know that binary isn’t tainted. And subsequently, that binary won’t taint its output. ? Hmm. That just doesn’t seem interesting. And, as you say, “Theoretically... you could...”. Emphasis mine...

WalterGR 8y ago

I think I’ve resolved my confusion (see my updated response to coldtea.) I think you’re 100% correct. This result just doesn’t seem interesting. Not only do you have to verify the source of all compilers in the chain, you need to ensure that - when that code is compiled - it’s the exact source that was verified. And even then, how do you know that the disk firmware actually gives you that non-tainted compiler when you ask for it? But: I guess it’s turtles all the way down. This at least theoretically improves how much of the chain (from atoms on a disk to the binaries produced by your Nth compiler) is non-tainted.

pygy_ 8y ago

Don't forget the CPU, which can also be malicious. That being said, that problem can be worked around by throwing interpreters into the mix.