Doc Formal: When ‘silicon proven’ is not enough
By Ashish Darbari, Tech Design Forum
Who would have thought the New Year would start on such a rocky note for all things digital? I am talking, of course, about Spectre and Meltdown.
I admit I didn’t pick up the signs when trouble started brewing last June. Having done some research, the problems appear to have been kept deliberately under wraps, so that hackers would not immediately start looking for exploits.
Who would have thought the New Year would start on such a rocky note for all things digital? I am talking, of course, about Spectre and Meltdown.
I admit I didn’t pick up the signs when trouble started brewing last June. Having done some research, the problems appear to have been kept deliberately under wraps, so that hackers would not immediately start looking for exploits.
The current furore has been caused by these two spectacular vulnerabilities that affect almost all processors. They are not just keeping Intel, ARM, AMD, Apple, Microsoft, Google, Amazon and Facebook awake at night. Just about anyone who uses a PC desktop, laptop, tablet, mobile phones or any other device (or cloud service) based on mainstream CPUs has reason to be concerned. I’m tossing and turning a bit myself.
That has made me think about how we got into this mess from the perspectives of both verification and validation. I find it hard to believe that processor vendors are running short of smart engineers and are under-resourced, or that they didn’t try hard enough to prevent this problem arising.
Spectre and Meltdown leave devices vulnerable to side channel attacks. These have been around for a while. They can be launched against CPUs predominantly due to the well-known speculative out-of-order execution optimization and branch target prediction features built into virtually all modern-day processors. So, I doubt that we are looking at a simple failure of intelligence or a mass oversight. Assuming that is the case, how did these vulnerabilities elude the industry for so long?
My theory comes down to a general bias in how we look at the design of electronic systems: security simply is not sufficiently seen as a hardware issue.
