Hoo boy. Here we go again. More silly codenames, more incomprehensible tech gobbledegook, more security flaws, more worry. What does it all mean?
I’m not going to give a detailed technical explanation. The best one is here. The very very short version is that processor speeds have run ahead of memory speeds for some time, so to get the best out of the processors the designers have resorted to guessing what they might want next from memory and loading it in advance into special high-speed on-processor storage called caches. Researchers have found that doing some cunning things in code can let you read the contents of these special caches, and even persuade the processor to load into them the parts of memory that particularly interest you.
Why is this such a worry, compared to other security flaws? Two reasons:
Firstly, it’s a problem with the hardware, not just some software, so it affects every Intel (and some other vendors’) processor made in the last few years and it’s hard to fix. The fixes that have been made available so far have affected both system reliability and performance – partly because they’ve been rushed out, and partly because they rely on turning off some of the things processors rely on to work fast.
Secondly, again because this is a hardware problem, if you can get suitable code onto a machine, you can read all of its memory. If that machine is part of a public cloud system, some of the memory might be being used for other companies’ processing, which would let you spy on them. This is a significant worry for anyone who’s adopted AWS, Azure or Google cloud as part of their enterprise IT, because they can’t control who else may be running code on the same hardware.
So should you worry?
Well, kinda. If you’ve got highly sensitive information in the cloud then it’s theoretically possible for a bad actor to get to it. But they’d have to have attack code running on the same physical machine as your data, and not have that code detected by the cloud provider’s monitoring. The attacks are, in theory, detectable because of their own impact on processor performance, and just as you don’t know which physical machine your workload is using, neither does the attacker.
The processor vendors, and the large cloud providers, are working hard to produce patches that prevent the attack. The problem is that these patches will also affect performance. You may find, therefore, that your cloud workloads slow down, or cost more to achieve the same throughput. It’s too early to say who’s going to end up paying that increased cost in the end – we do know that there are as of this moment 31 class-action suits against Intel.
If you aren’t in the public cloud, it’s a different story. For someone to exploit this vulnerability, they have to get code onto your system. That’s no different to any other virus or malware. They also have to be able to run the code without its performance impact being detected, and exfiltrate the stolen data afterwards. So our view is that you don’t need to rush to implement Meltdown or Spectre patches, but you do need to make sure that all of your existing defences are up-to-date and up to the job. Or, of course, check that you’ve outsourced your IT to the right people…
A bigger picture 