Reflections on Trusting Trust (1984) [pdf]
ece.cmu.edu
Reflections on Trusting Trust (1984) [pdf]
1–10 of 16 posts
Re: Reflections on Trusting Trust (1984) [pdf]
#2I had never heard about this lecture until a few months back. I read the annotated version on Fermat's Library which really helped me understand it - http://fermatslibrary.com/s/reflections-on-trusting-trust
Re: Reflections on Trusting Trust (1984) [pdf]
#3"Reflections on Trusting Trust" is really awesome; it's a very cogent discussion of the problems of subverted tools (like compilers).
If you read that, you should also take a look at my PhD dissertation which discusses how to counter it. It's "Fully Countering Trusting Trust Through Diverse Double-Compiling" (2009), available at: https://www.dwheeler.com/trusting-trust . It was discussed on Hacker News in 2016; here's the link: https://news.ycombinator.com/item?id=12666923
Another related work is the reproducible builds work; a good link is here: https://reproducible-builds.org/
Re: Reflections on Trusting Trust (1984) [pdf]
#4"Reflections on Trusting Trust" is really awesome; it's a very cogent discussion of the problems of subverted tools (like compilers). If you read that, you should also take a look at my PhD dissertation which discusses how to counter it. It's "Fully Countering Trusting Trust Through Diverse Double-Compiling" (2009), available at: https://www.dwheeler.com/trusting-trust . It was discussed on Hacker News in 2016; here'…
Yes, its one of my favorite papers. Thanks for the pointers, very useful.
Re: Reflections on Trusting Trust (1984) [pdf]
#5I had never heard about this lecture until a few months back. I read the annotated version on Fermat's Library which really helped me understand it - http://fermatslibrary.com/s/reflections-on-trusting-trust
Never really knew about Fermat's library. From skimming it looks like a really great idea, especially for reading papers in areas you may not be that familiar with.
Re: Reflections on Trusting Trust (1984) [pdf]
#6You clearly can't take this argument to ad naseum because then no one could do anything without starting from scratch. Most linux distros distribute binaries+source, and even source based distros like Gentoo have you download a something like a tarball for bootstrapping. Of course, there are things like checksums and such, but you have to, of course, trust the source.
Yet, the world still turns, absent some terrible exceptions. It's almost as if no system is truly safe and secure, which I think cultures have known since the ages.
Re: Reflections on Trusting Trust (1984) [pdf]
#7This is a nice elaboration of the attacks and issues discovered by co-founder of INFOSEC, Paul Karger, during his pentest of MULTICS in early 1970's. That included a proposed PL/I compiler that inserted vulnerabilities into itself when compiled. Thompson got the report while on MULTICS team. The solution was called high-assurance security which culminated in Orange Book of TCSEC. It came out in SCOMP about same time Thompson started writing on the original problem.
https://www.acsac.org/2002/papers/classic-multics.pdf
Paul helped invent much of INFOSEC from scratch with lots of his lessons rediscovered over time by mainstream INFOSEC that largely ignores predecessors' work. Here's Paul's other stuff for any interested:
https://www.semanticscholar.org/author/Paul-A-Karger/2467751
Back to this topic, the definitive solution is high-assurance compiler combined with SCM techniques presented best by David Wheeler:
Re: Reflections on Trusting Trust (1984) [pdf]
#8You clearly can't take this argument to ad naseum because then no one could do anything without starting from scratch. Most linux distros distribute binaries+source, and even source based distros like Gentoo have you download a something like a tarball for bootstrapping. Of course, there are things like checksums and such, but you have to, of course, trust the source. Yet, the world still turns, absent some terrible…
Sure you can. I've proposed how to do it here several times. You can start like Niklaus Wirth with a simple interpreter (eg P-code) + basic, routines for hardware. You write compiler as series of small passes (no optimization) in that interpreter. Compile it with itself. Add optimizations and recompile.
For hardware, you start with simplified CPU like a Forth or ZPU processor. One you can check by hand and eye on an older process node. Reverify it with itself. Then run above step for software on it. Optionally better EDA tools, too.
The diversity method ports the simple interpreter or compiler to a number of CPU architectures or dev tools. Pick whichever you want. If you aim for same binary, you'll need compiler designed to do that or reproducible builds like Wheeler links to up thread.
Re: Reflections on Trusting Trust (1984) [pdf]
#9You clearly can't take this argument to ad naseum because then no one could do anything without starting from scratch. Most linux distros distribute binaries+source, and even source based distros like Gentoo have you download a something like a tarball for bootstrapping. Of course, there are things like checksums and such, but you have to, of course, trust the source. Yet, the world still turns, absent some terrible…
Sure you can. I've proposed how to do it here several times. You can start like Niklaus Wirth with a simple interpreter (eg P-code) + basic, routines for hardware. You write compiler as series of small passes (no optimization) in that interpreter. Compile it with itself. Add optimizations and recompile. For hardware, you start with simplified CPU like a Forth or ZPU processor. One you can check by hand and eye on an…
"There exists" is not the same as it is practical. My sentiment doesn't regard possibility, but feasibility for the average user.
Re: Reflections on Trusting Trust (1984) [pdf]
#10Earlier quoted context omitted.
Sure you can. I've proposed how to do it here several times. You can start like Niklaus Wirth with a simple interpreter (eg P-code) + basic, routines for hardware. You write compiler as series of small passes (no optimization) in that interpreter. Compile it with itself. Add optimizations and recompile. For hardware, you start with simplified CPU like a Forth or ZPU processor. One you can check by hand and eye on an…
"There exists" is not the same as it is practical. My sentiment doesn't regard possibility, but feasibility for the average user.
It's quite feasible. You just pay a programmer or smart student to do it for you using the published literature. Done. Even stronger if you trust them. Use multiple, distrusting pros on same project if more trustworthiness is needed. What you cant afford you crowd fund or ask for grants.
It's a question of priorities rather than feasibility. Most users or customers dont care enough to invest time or effort needed. End of story. Same one as usual for strong INFOSEC.
I'll also add that there already exists certifying compilers for C and Standard ML that both extract to ML. The ML extracted is simple enough to hand-compile to ASM following one of two guides. So, not only can oma human verify no subversion, there's already a production one with machine-checked proof that's also be checked by humans [again].