3 ms·

Use a CPU that does constant-time everything (e.g. has no caches). Most of the super-simple in-order RISC-V cores that are available on github will do. Just put

Use a CPU that does constant-time everything (e.g. has no caches). Most of the super-simple in-order RISC-V cores that are available on github will do. Just put one of them in an FPGA, and you are set up. Most of those CPUs are designed by CS or EE students taking a computer architecture class, so... in a sense... one can argue that defending against Spectre-like attacks is actually super simple: just use a simple CPU design. To actually become vulnerable to Spectre, you need a very complex CPU design, so in the same way, it can be argue, that making a CPU vulnerable to Spectre is actually hard, since it takes a lot of work to create such a CPU design. Now, if what you want is a CPU that's both fast and secure, then I'm sorry to tell you that such thing cannot exist. Those two goals are at tension. You can either get a F1 or a tank, but no vehicle that offers the same amount of protection as a tank is going to be able to compete against a F1 car, and vice-versa.

guenthert 6y ago
Caches aren't the problem (in the context of SPECTRE), branch prediction is. Getting rid of caches would be very costly performance-wise. VLIW CPUs don't predict branches themselves, but rely on the compiler to generate optimal code ahead of time. I was actually expecting an updated Itanium after the SPECTRE debacle.
- volta87 6y ago
  AFAIK branch prediction enables the attack by enabling speculative execution, but the data is not leaked through the branch predictor, but rather through the timing differences observed due to speculative loads bringing data to cache. I guess if you remove the branch predictor, you might avoid spectre while keeping caches, but I think you can keep the branch predictor and remove caches to also avoid spectre. The downside I see in keeping the caches is that you keep the _source_ of the timing differences, so an attacker just needs to find a different attack vector to create a new timing attack. If you remove the caches, you kill the source of most timing attacks. I'm not an expert on this though.

guenthert 6y ago

Caches aren't the problem (in the context of SPECTRE), branch prediction is. Getting rid of caches would be very costly performance-wise. VLIW CPUs don't predict branches themselves, but rely on the compiler to generate optimal code ahead of time. I was actually expecting an updated Itanium after the SPECTRE debacle.

volta87 6y ago
AFAIK branch prediction enables the attack by enabling speculative execution, but the data is not leaked through the branch predictor, but rather through the timing differences observed due to speculative loads bringing data to cache. I guess if you remove the branch predictor, you might avoid spectre while keeping caches, but I think you can keep the branch predictor and remove caches to also avoid spectre. The downside I see in keeping the caches is that you keep the _source_ of the timing differences, so an attacker just needs to find a different attack vector to create a new timing attack. If you remove the caches, you kill the source of most timing attacks. I'm not an expert on this though.