3 ms·

> A and B are also compilers, one of which is known-good. 'Known-good' is exactly the problem Thompson's essay is describing. There is no 'known-good'. Instead

> A and B are also compilers, one of which is known-good. 'Known-good' is exactly the problem Thompson's essay is describing. There is no 'known-good'. Instead, you have decided to root your chain of trust with a compiler you call 'known-good' (say, B). But ultimately, that trust is arbitrary: your compiler B relied upon un-investigated components at some point in its heritage: a hex editor, a disk drive controller, a CPU, an LCD screen, etc. The best you can do is reduce the trusted base to the smallest amount, then make explicit your trust relationships as much as possible. Ideally, the trusted base would be physics and logic with a metaphysical certainty of the universality of those laws; we're a long way from that situation :)

SEMW 13y ago
Yes, of course. I don't think WalterBright was claiming that this method eliminates the theoretical possibility of all trusting-trust-type attacks entirely, only that it gives you a good shot at detecting the specific type that Thompson gave as his example (the compromised compiler). The point of the method being that since compiler B can be crap (slow, non-optimising, only implementing the minimum required to compile compiler C), it can be something you could knock up yourself, so reducing your level of trust to those components below the level of the compiler. So yes, you're still relying on things below that. That doesn't make the exercise 'arbitrary' or pointless. Good risk management is reducing the chances of the most probable attacks, and a compromised compiler is (ISTM) a much more likely attack than e.g. a compromised CPU. Seems to me that putting theoretical perfection too far ahead of pragmatism just gives the (wrong and damaging) impression that not being able to solve all trusting-trust issues entirely means it's not worth their time trying to solve the more tractable ones.
- sharkbot 13y ago
  I disagree with you, but you're not wrong. Taking the pragmatic approach to trust is perfectly valid, and the only short to medium term option at present. I personally find it distasteful, but that's my academic bias showing. However, Thompson's essay is both a practical attack and an abstract idea; I find the notion of trust with self referential systems more interesting than the specifics of how to detect a backdoored compiler.
  - SEMW 13y ago
    That's fair enough. Cheers for the discussion.

SEMW 13y ago

Yes, of course. I don't think WalterBright was claiming that this method eliminates the theoretical possibility of all trusting-trust-type attacks entirely, only that it gives you a good shot at detecting the specific type that Thompson gave as his example (the compromised compiler). The point of the method being that since compiler B can be crap (slow, non-optimising, only implementing the minimum required to compile compiler C), it can be something you could knock up yourself, so reducing your level of trust to those components below the level of the compiler. So yes, you're still relying on things below that. That doesn't make the exercise 'arbitrary' or pointless. Good risk management is reducing the chances of the most probable attacks, and a compromised compiler is (ISTM) a much more likely attack than e.g. a compromised CPU. Seems to me that putting theoretical perfection too far ahead of pragmatism just gives the (wrong and damaging) impression that not being able to solve all trusting-trust issues entirely means it's not worth their time trying to solve the more tractable ones.

sharkbot 13y ago
I disagree with you, but you're not wrong. Taking the pragmatic approach to trust is perfectly valid, and the only short to medium term option at present. I personally find it distasteful, but that's my academic bias showing. However, Thompson's essay is both a practical attack and an abstract idea; I find the notion of trust with self referential systems more interesting than the specifics of how to detect a backdoored compiler.
- SEMW 13y ago
  That's fair enough. Cheers for the discussion.