Spectre/Meltdown & What It Means for Future Design 2

I gave an introduction to speculative execution and the vulnerabilities that have come to light this year in yesterday's post Spectre/Meltdown & What It Means for Future Design 1.

There were 4 panelists at Hot Chips, chaired by Partha Ranganathan of Google. Each panelist gave a brief introduction, and then they got together as a panel and took questions from the audience.

• John Hennessy, currently Chairman of Alphabet (Google), but one of the inventors of RISC (for which he just shared this year's Turing Award).
• Paul Turner of Google. Google's Project Zero is one of the groups that discovered these vulnerabilities, and Paul was part of the group tasked with mitigation.
• Jon Masters of Red Hat, the person responsible for fixing up Red Hat Linux as well as is feasible.
• Mark Hill of the University of Wisconsin at Madison and also on sabbatical at Google.

John Hennessy: The Era of Security

John kicked off the session pointing out how much the world has changed. There is a lot more personal information online (so we all care more about security). Cloud servers mean that strangers, and even people we might consider adversaries, are sharing the same hardware. Meanwhile the bad guys are getting badder: state actors and cybercriminals are getting more organized and technically adept. Although most attacks are software-based, hardware is now entering the picture.

He gave a brief tutorial on how Spectre and Meltdown work (like mine yesterday). He also talked about NetSpectre, which I hadn't heard of, that allows you to exploit the Spectre v1 hole without running any code, breaking in from a remote machine. It's not a very effective attack, only leaking about 1 bit per minute, but the attack is completely remote.

The big challenge is we can't allow hardware flaws, no matter how much performance could be gained. But it is hard to fix the current flaws and the fixes may cost more than is gained by the hardware optimization. Even next-generation Intel processors probably won't fix Spectre v1 (the hardest of the vulnerabilities to address).

His mea culpa:

Lots of us missed this problem for about 10-15  years.

Paul Turner: The Project Zero Journey

Project Zero is an internal security team founded in 2014 with the goal of reducing the harm caused by attacks on the Internet, with a particular focus on "zero days", which are vulnerabilities that are not known about until the day (day 0) that an adversary attacks using them. Last year, Jann Horn, one of the researchers on Project Zero, discovered this new class of speculative vulnerabilities and, in Google, they became known as SpeckHammer (I think that is a play on speculative execution, and RowHammer, another hardware vulnerability in DRAMs, which is not today's topic).

Paul talked about the numbers that I covered in my post, the Numbers Everyone Should Know. The CPU tries to hide the big number, the 100ns access to main memory, using caches and speculation. It is very effective, with a low number of cycles per instruction (much less than 1). The flaw in all of this is the assumption that mis-predicted branches have no side-effects. By the definition of the ISA, that is true. But we now know that there this is not true when we look at the bigger picture.

Paul ran through the variants of Spectre, and some of the approaches to mitigation. That's a level too much detail for this post. I'll just point out that his slide for "What about Spectre Variant 1" was blank. There is one attack that nobody has a clue how to prevent without giving up all the gains that come from speculation.

Jon Masters: Exploiting Modern μArchitectures: Software Implications

Next up was Jon Masters of Red Hat. One of the big problems, he said, was that hardware and software people don't talk. In the very old days, pre-IBM/360, there was a much greater understanding (and hardware was simpler). But in the ISA era, there was no clear contract between hardware and software. Programmers assumed sequential execution, which involved various assumptions that were never explicitly clarified. Then we built more layers on top.

It is even worse today, since programming has become much more abstract (Python, Go, Ruby, etc) and many programmers don't even know what a stack or a branch is. Speculation was treated as a magic black box, and the gains were so impressive nobody looked under the hood much. The average programmer has no idea about speculation and out-of-order execution, or branch prediction.

Harold McMillan got re-elected as Britain's Prime Minister in the late 1950s with the catchphrase "You've never had it so good." Jon said something similar:

We are too used to how good we have had it.

Jon's summary:

• The “us” vs “them” became so ingrained we forgot how to collaborate
  • Most programmers negatively care about hardware, which is seen as a boring commodity
  • Software architects and hardware microarchitects don’t talk ahead of implementing new features, but instead build their view of the world and (maybe) reconcile it afterward
• Previous vertical system model gave way to separate hw/sw companies
  • Hardware folks design processors (and interconnects, and other platform pieces)
  • Platform-level capability was gradually eroded from outside processor vendors
  • The focus on security has actually been a positive from this perspective
• Renaissance in computer architecture brings us a new hope
  • Increasing need to understand a vertical stack from hardware to software
  • Focus on security has proven the need to understand how hardware works

Tomorrow

Tomorrow, I'll wrap up this important and fascinating session with Mark's presentation, and then the discussion that followed.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.