Paul Kocher talks Meltdown and Spectre
Last month, SiFive hosted a seminar that featured senior Rambus technology advisor Paul Kocher. During the seminar, Kocher discussed a number of security related topics, including side-channel (SCA) differential power analysis (DPA), Meltdown and Spectre. As we’ve previously noted on Rambus Press, Meltdown and Spectre were independently disclosed by a number of security experts, including Kocher and senior Rambus security engineer Mike Hamburg.
According to Paul McLellan of the official Cadence blog, Kocher emphasized that silicon isn’t typically designed with security concerns in mind.
“[Moreover], today’s code may be fine but turn out to be insecure on future chips with even higher performance. Any fix will be incomplete and other attack variants may be able to get around it,” McLellan paraphrases. “Future chips may comply with the architecture but have different side channels. To make it worse, none of this is documented since a lot is considered proprietary: nobody publishes how their branch predictor works, or how the algorithms in the cache (typically for eviction) work.”
As Kocher also pointed out, chips are usually designed for performance, rather than security. This leaves the industry with three options: fast and dangerous (today), safe but slower (limit speculation), or punting the problem from hardware to software, thereby making the compiler put LFENCE in front of any branch that might be ‘exploitable.’ In a multicore processor, McLellan says, Kocher feels there is no reason that the chip could not be optimized for security rather than performance.
“The process we have for fixing software vulnerabilities works well (tell the software supplier, give them an embargo time to fix, then publish),” McLellan reports. “However, the process doesn’t work for hardware since, if you told everyone who needs to know, then that is more people than can keep a secret. There are too many parties, none in control and conflicting agendas.”
As McLellan concludes, DPA was the first hardware vulnerability that required mitigation across a whole ecosystem. Spectre and Meltdown are the second, although they obviously won’t be the last.
In fact, as Kocher told attendees: “These [vulnerabilities] should have been found 15 years ago, not by me, in my spare time, since I quit my job and was at a loose end. This is going to be a decade-long slog.”
ISA a post-Meltdown and Spectre world
In related news, Adrian Giordani of Scientific Computing recently penned an article about how Meltdown and Spectre will impact future processor designs.
Indeed, Giordani interviewed Daniel Gruss, a researcher from the team at the Graz University of Technology in Austria, who works on understanding micro-architectural attacks such as Meltdown and Spectre. As Giordani reports, a number of security researchers including Gruss, Kocher and Hamburg, published a paper in January titled “SpectreAttacks: Exploiting Speculative Execution.”
“They argue that even though countermeasures have and are being implemented, there is currently no way to know whether a particular code construction is, or is not, safe across today’s processors – and future designs,” writes Giordani. “For example, mitigations for Meltdown do not work against Spectre attacks.”
As such, the security researchers emphasize that long-term solutions will require updating instruction set architectures (ISAs) to include clear guidance about the security properties of the processor.
“The problem is that compilers, device drivers, operating systems, processors, etc. have all evolved multiple layers of complexity that introduce security risks. Future designs, in many cases, will need alternative implementations with security front-of-mind. Computational performance may have to take a back seat,” adds Giordani. “These problems are here for the long term until the next generation of silicon processors hit the market. In the end, one of the original teams that found these security vulnerabilities says it best on their website: ‘As it is not easy to fix, it will haunt us for quite some time.’”
