Google Engineer Calls For Greater Collaboration On Speculative Execution Mitigations

When it comes to kernel address space isolation (ASI) and other yet-to-be-merged security features around fending off speculative execution attacks, there are multiple concurrent efforts by many of the public cloud providers and other hyperscalers. A Google engineer at this week's Linux Plumbers Conference has called for more collaboration in this area to ideally provide a unified solution.

Case in point to all the work going on in this area were talks by Google, Oracle, and DigitalOcean this week at Linux Plumbers Conference. DigitalOcean has been pursuing Core Scheduling to make Hyper Threading safer by ensuring only trusted applications share a core. Oracle meanwhile presented on their Address Space Isolation work for Linux. Google also had a talk on Linux Address Space Isolation at this week's virtual event. ASI aims to deal with Hyper Threading data leakage by isolating the address space between the different areas of the kernel with a particular emphasis on KVM/virtualization to avoid the possibility of data leakage between guest VMs or the host.

Google's Ofir Weisse was talking at LPC 2020 about ASI due to the "significant security risk to hypervisors and VMs" by the known vulnerabilities like L1TF, MDS, and LVI. Google like other hyperscalers can't resort to disabling Hyper Threading and even some of the over excessive buffer flushing is too much to them, thus they have been investing in their own Address Space Isolation technique. "We are developing a high-performance security-enhancing mechanism to defeat speculative attack which we dub Address Space Isolation (ASI). In essence, ASI is an alternative way to manage virtual memory for hypervisors, providing very strong security guarantees at a minimal performance cost."

While there are existing mitigations to the Linux kernel already, Google views these as having too high of overhead (like the frequent L1 cache flushing) or incomplete. With their ASI code, performance is quite important. With their approach the kernel memory is split into privileged and unprivileged domains with each domain having a separate page table. If touching data outside of the page table, a page fault is generated. They are working on this code with the idea of being able to extend ASI to user-space too.

Google's approach is similar to the Oracle ASI code while they acknowledge Intel, Amazon, and IBM are among companies working on other solutions. Ultimately they hope ASI can also be a replacement to Kernel Page Table Isolation that is also used for Meltdown mitigations.

More details on Google's ASI work and the call for increased collaboration among organizations can be found via this slide deck.