Proposed a few years ago was Kernel Address Space Isolation (KASI / ASI) for limiting data leaks with the growing number of speculative execution attacks on CPUs. Several organizations have been involved with Address Space Isolation efforts for the Linux kernel including IBM, Oracle, and Google with various approaches. Google engineers earlier this year posted a newer iteration of ASI focused on KVM use for the cloud / VMs. ASI still hasn’t made it to the mainline kernel but Google engineers this week at LPC argued that it should be the path forward for mainline in better dealing with these CPU security vulnerabilities.
As we have only seen more speculative execution attacks with time (and no sign of them letting up) and each new vulnerability requiring significant engineering resources and testing, Google engineers going for the Address Space Isolation route may be more robust and lead to quicker turnaround times on mitigations and less costly for performance.
From Google’s take on ASI earlier this year with their KVM-tailored “RFC” patches:
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.
…
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.
Junaid Shahid and Ofir Weisse, both of Google, used the Linux Plumbers Conference this week in Dublin to try to drum up renewed interest in going for Address Space Isolation.
Not only should ASI mean less performance degradation, but patching for new vulnerabilities should mean less code change / engineering resources needed.
But one of the challenges with ASI itself is that it touches a lot of low-level kernel code to get into place. With ASI touching the memory management, interrupt handling, the hypervisor (KVM), etc, the initial bring-up for ASI is invasive. ASI will need to prove as well that it can be just as secure as the existing but more expensive mitigation techniques.
But at least the Google engineers believe ASI can be as effective as existing mitigation techniques while inducing less overhead.
It remains to be seen though if/when Address Space Isolation would be in a good enough shape for the mainline kernel at least for KVM hypervisor usage. With Google’s resources we will see if it can happen sooner rather than later or if it will take a few more speculative execution attacks with further performance degradation before it gets pushed along. Those wanting to learn more about Google’s current ASI work for Linux can see this slide deck and the LPC 2022 presentation embedded below.
