Strange Loops: Ken Thompson and the Self-referencing C Compiler • Hacker News Board

Re: Strange Loops: Ken Thompson and the Self-referencing C Compiler

#51

Post by sharkbot » Tue, Sep 10, 2013, 4:57 PM UTC

SEMW wrote: post #48

sharkbot wrote: post #46

Earlier quoted context omitted.

> 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,…

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 compil…

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.

Re: Strange Loops: Ken Thompson and the Self-referencing C Compiler

#52

Post by SEMW » Tue, Sep 10, 2013, 5:14 PM UTC

sharkbot wrote: post #51

SEMW wrote: post #48

Earlier quoted context omitted.

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 compil…

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 backdoo…

That's fair enough. Cheers for the discussion.

Re: Strange Loops: Ken Thompson and the Self-referencing C Compiler

#53

Post by barbs » Wed, Sep 11, 2013, 5:10 AM UTC

adrusi wrote: post #34

barbs wrote: post #27

Interesting! Out of curiosity, if this were the Gnu C Compiler, would this be illegal, since the GPL requires the source to be distributed with the binary, and the source and binary don't match?

The is no definition of "match" beyond just what the compiler produces. No spec dictates what the output of a compiler should be.

Does this mean that, in theory, if someone wanted to modify some GPL'd code to merge it into a proprietary project, and they didn't want to GPL the entire project, they could modify the compiler to compile the code with the modifications? It'd be a completely round-about way to do it, but in theory would this be legal?

If it were a GPL-licensed compiler (e.g. GCC), they wouldn't need to distribute the compiler-code changes, since they would only be using it internally and not distributing the binary for the compiler itself.

Of course, they could just modify and use a shared-library of the GPL'd code or whatever. At least, that's my understanding, could be wrong...

Re: Strange Loops: Ken Thompson and the Self-referencing C Compiler

#54

Post by adrusi » Thu, Sep 12, 2013, 10:13 PM UTC

barbs wrote: post #53

adrusi wrote: post #34

Earlier quoted context omitted.

The is no definition of "match" beyond just what the compiler produces. No spec dictates what the output of a compiler should be.

Does this mean that, in theory, if someone wanted to modify some GPL'd code to merge it into a proprietary project, and they didn't want to GPL the entire project, they could modify the compiler to compile the code with the modifications? It'd be a completely round-about way to do it, but in theory would this be legal? If it were a GPL-licensed compiler (e.g. GCC), they wouldn't need to distribute the compiler-code c…

Well they couldn't use gcc, because that's also GPL and they'd have to release its source, but if I'm not missing some more nuanced part of the license, they could probably compile with a fork of clang.

Re: Strange Loops: Ken Thompson and the Self-referencing C Compiler

#55

Post by barbs » Tue, Sep 17, 2013, 11:49 PM UTC

adrusi wrote: post #54

barbs wrote: post #53

Earlier quoted context omitted.

Does this mean that, in theory, if someone wanted to modify some GPL'd code to merge it into a proprietary project, and they didn't want to GPL the entire project, they could modify the compiler to compile the code with the modifications? It'd be a completely round-about way to do it, but in theory would this be legal? If it were a GPL-licensed compiler (e.g. GCC), they wouldn't need to distribute the compiler-code c…

Well they couldn't use gcc, because that's also GPL and they'd have to release its source, but if I'm not missing some more nuanced part of the license, they could probably compile with a fork of clang.

See, I don't think they'd have to release the source for gcc, since they're not releasing the gcc binary.

My understanding is, under the GPL, if you distribute the binary, you need to distribute the source.