I am one of the leads for Google’s mitigation efforts of Spectre and its entire class of vulnerabilities. I have worked across most of Google’s products, and have specifically led all of our compiler-based mitigation efforts. There are several important conclusions I have drawn based on my experience with these new attack vectors and our attempts to mitigate them.

Compilers and Programming Languages can and must be leveraged in many cases to mitigate side channels, and this is only more critical in the face of Spectre. Despite that, these mitigations are insufficient in many cases. They either cannot cover all of the attack surface or they come with too high of a cost. We must get hardware vendors to build fundamental protection capabilities into future processors. It must be based on tested and proven techniques in software to ensure it works. And it must be a primary hardware feature to have the performance and availability needed.

We must change our programming patterns to clearly identify and express intent around side channels and speculative execution to allow our programming language implementations to effectively target either the software or hardware mitigations available. None of this will be sufficient when running untrusted code. To sandbox code from data on modern CPUs, the data must be kept out of the untrusted code’s virtual address space. Any other technique will eventually prove insufficient. I am interested in discussing these points and how to coordinate effectively around them. I am helping drive efforts to standardize changes to the C++ programming language[1] based on #4. I have also helped start an effort to provide guidelines for specific application code such as cryptographic code to exist effectively in a post-Spectre world[2]. I would love to see feedback, discussion, and help with both. I am also interested in discussing different software and hardware approaches to mitigating attacks like Spectre, including but not limited to Speculative Load Hardening[3]. Last but not least, I am interested in discussing how future hardware should support these efforts. This includes both Spectre-style mitigation but also the use of address spaces and other hardware facilities to enable secure sandboxing of untrusted code at minimal cost.

[1] ​ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0928r0.pdf

[2] ​ https://github.com/HACS-workshop/spectre-mitigations/blob/master/crypto_guidelines.md [3] ​ https://lists.llvm.org/pipermail/llvm-dev/2018-March/122085.html