Google Posts New ASI Patches For KVM To Help Fight Off Speculative Execution Attacks
Google engineers have posted a big patch series for Linux as they work on a new Address Space Isolation implementation for KVM to help mitigate various types of speculative execution attacks.
This address space isolation (ASI) implementation for KVM is considered proof of concept and sent out under a "request for comments" flag. This is of similar intent to prior ASI KVM patches but a new underlying implementation and also introduces the notion of sensitive and non-sensitive memory.
The intent of the address space isolation is still about mitigating speculative execution attacks with a hope of ASI KVM having lower overhead for VMs than some of the other current mitigation approaches. That patch cover letter summarizes, "Address Space Isolation is a comprehensive security mitigation for several types of speculative execution attacks. Even though the kernel already has several speculative execution vulnerability mitigations, some of them can be quite expensive if enabled fully e.g. to fully mitigate L1TF using the existing mechanisms requires doing an L1 cache flush on every single VM entry as well as disabling hyperthreading altogether. (Although core scheduling can provide some protection when hyperthreading is enabled, it is not sufficient by itself to protect against all leaks unless sibling hyperthread stunning is also performed on every VM exit.) ASI provides a much less expensive mitigation for such vulnerabilities while still providing an almost similar level of protection."
The letter also notes more on the intended mitigation strategy with ASI-KVM:
See the patch cover letter for more details on this RFC series of 47 patches aiming to provide address space isolation for KVM. The patch series also notes that KVM Kernel Page Table Isolation (KPTI) could also be implemented on top of this same, new infrastructure. The patch documentation also notes they have a sibling hyperthread stunning implementation internally at Google that is integrated with KVM-ASI and may be integrated later.
This address space isolation (ASI) implementation for KVM is considered proof of concept and sent out under a "request for comments" flag. This is of similar intent to prior ASI KVM patches but a new underlying implementation and also introduces the notion of sensitive and non-sensitive memory.
The intent of the address space isolation is still about mitigating speculative execution attacks with a hope of ASI KVM having lower overhead for VMs than some of the other current mitigation approaches. That patch cover letter summarizes, "Address Space Isolation is a comprehensive security mitigation for several types of speculative execution attacks. Even though the kernel already has several speculative execution vulnerability mitigations, some of them can be quite expensive if enabled fully e.g. to fully mitigate L1TF using the existing mechanisms requires doing an L1 cache flush on every single VM entry as well as disabling hyperthreading altogether. (Although core scheduling can provide some protection when hyperthreading is enabled, it is not sufficient by itself to protect against all leaks unless sibling hyperthread stunning is also performed on every VM exit.) ASI provides a much less expensive mitigation for such vulnerabilities while still providing an almost similar level of protection."
The letter also notes more on the intended mitigation strategy with ASI-KVM:
Given these, the idea of using ASI to thwart speculative attacks is that we can execute the kernel using a restricted set of page tables most of the time and switch to the full unrestricted kernel address space only when the kernel needs to access something that is not mapped in the restricted address space. And we keep track of when a switch to the full kernel address space is done, so that before returning back to the process/VM, we can switch back to the restricted address space. In the paths where the kernel is able to execute entirely while remaining in the restricted address space, we can skip other mitigations for speculative execution attacks (such as L1 cache / micro-arch buffer flushes, sibling hyperthread stunning etc.). Only in the cases where we do end up switching the page tables, we perform these more expensive mitigations. Assuming that happens relatively infrequently, the performance can be significantly better compared to performing these mitigations all the time.
See the patch cover letter for more details on this RFC series of 47 patches aiming to provide address space isolation for KVM. The patch series also notes that KVM Kernel Page Table Isolation (KPTI) could also be implemented on top of this same, new infrastructure. The patch documentation also notes they have a sibling hyperthread stunning implementation internally at Google that is integrated with KVM-ASI and may be integrated later.
3 Comments