The Spectre and Meltdown bugs have been billed as a ‘failure of imagination’, where the hardware designers simply didn’t conceive of the possibility that a performance optimisation might lead to a security vulnerability.

I personally find this a little hard to swallow. The very first time I came across side-channel attacks the first thing I though of was CPU caches. I just naively assumed that the folk at Intel etc. were smart enough to have figured out the potential problems and already designed in the countermeasures.

Regardless of whether Spectre and Meltdown genuinely were caused by failure of imagination (and I have my doubts about ARM here given that the CSDB instruction was already in the silicon of their licensees) it’s a class of problem we collectively need to think harder about. There seem to be a few valid approaches here:

1. Adopting a more adversarial mindset – think about how an attacker might try to exploit a new feature or performance optimisation – the ‘red team‘ approach.
2. ‘Chicken bits'[1] to allow features/optimisations to be disabled if they’re discovered to be vulnerable.
3. Use of artificial intelligence (AI) to imagine harder/differently. When Google’s Deepmind team created AlphaGo it played Go like a human but a bit better; when they created AlphaGo Zero it came up with entirely different plays. I’d therefore expect that similar approaches could be applied to security validation.

Note

[1] Hat tip to Moritz Lipp for this term from the Q&A section of his QCon London presentation ‘How Performance Optimisations Shatter Security Boundaries‘