how is trusting your fab any different than trusting Intel?
> that's not very different from trusting your compiler
if you were paranoid enough to be worrying about CPU backdoors, why would you trust your compiler?
> that's not very different from trusting your compiler
if you were paranoid enough to be worrying about CPU backdoors, why would you trust your compiler?
You increase the cost of an attack - it's harder to change a processor's behavior by editing the mask than the VHDL. If you were super-paranoid you could source to multiple different fabs and run the chips you get back in parallel, with some sort of trap that goes off whenever you get different results from one or other processor.
>if you were paranoid enough to be worrying about CPU backdoors, why would you trust your compiler?
If you don't trust your compiler, why are you even bothering worrying about CPU backdoors when you've got a much easier attack vector open?
Who's to say you're going to trigger the condition that causes the backdoor? Seems very unlikely. If you have ideas on this, though, I'd be interested.
If you don't trust your compiler, why are you even bothering worrying about CPU backdoors when you've got a much easier attack vector open?
You may not trust your compiler, and therefore do certain things in a VM where e.g. access to network is limited. See [1].
Also, trusting your compiler is different from trusting your CPU because one is much, much easier to check than the other. You can build GCC yourself, look at the source code, manually check the output. You could even write your own compiler. In general, we can't make our own processors or verify their internals, yet.
AMD on the other hand, is going fab-less for at least some of their products. TSMC was mentioned in the past as being a partner. So you'd have to trust both AMD and TSMC.
You'd have to write an assembly program and then a hand-translated binary version that can run directly on the bare metal with no OS. And use it to compile the "real" compiler.
I wonder if one could make that simple enough to do be "somewhat reasonable," yet complex enough to compile the real compiler. Probably! Though it may take a team of people quite some time.
I wonder if government(s) have infrastructure/teams that do this already, or if there are any open source projects aimed at this kind of thing.
1. Trusting chip fabs is a non-starter. Institutional security only helps large institutions. You will not audit your fab, nor can you trust other people to do it for you. Unlike software, there is no "certificate" that is easily verified in the event of a backdoored fab.
2. There's two phases in the lifecycle of a backdoor. First, is its latent 'offline' period which is noninteractive with respect to the attacker. For example, a backdoored compiler [RoTT] basically propagates a virus to new copies of the compiler. Solving this seems tractable by eliminating bootstrapping as the sole method for compiling a compiler, and research into interpreted languages that are easily ported to new platforms for the stage0 compiler.
3. The second phase is when the introduced vulnerability is 'active' and ready to be exploited over the network by an interactive attacker. The case of a network-facing compiler-infected binary should be easily solved by solving the first problem. The case of backdoored hardware/microcode is much more insidious, and requires coming up with assumptions to frame the problem for even a chance at being tractable. (Also, it requires the trustable software tools from (2) for implementing the solution)
4. Secure 'offline' computing on its own would be a boon for things like maintaining the integrity of master cryptographic keys (although keep in mind one still has to prevent against a backdoored CPU acting as an infected stage0, but this is much easier in a noninteractive setting). I'm less familiar with state of the art in this area than I should be, but I'm guessing implementations are probably still in the dark ages of 'trust the company'.