> The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well-installed microcode bug will be almost impossible to detect.
[0] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
You can trust a system by accepting that if it is owned, you are owned. If you don't trust it you instead protect it with a system that you do trust. For example, if you don't trust any x86 system you would not make them face the Internet. You would put them behind a trusted firewall.
But you have to decide whether you trust a system or not. If you trust it then you have to believe it when it reports a certain feature is disabled. If you don't trust it to begin with then it doesn't matter if it's disabled or not. Your security shouldn't be relying on it anyway.
Which is a hint to the solution: https://news.ycombinator.com/item?id=41368835