Last year an AMD engineer proposed the notion of “Attack Vector Controls” for the Linux kernel to re-think how the CPU security mitigation handling is done and making it easier for system administrators/users to toggle the mitigations they are concerned about or not.
With the proposed Attack Vector Controls for Linux, it’s a new approach to managing what CPU security mitigations are applied or not based on the class/scope of vulnerabilities rather than managing the mitigations at an individual level. With this approach, particularly for Linux servers, it makes it easier to manage the CPU security mitigations based on the intended role of the instance being deployed.
The existing CPU security mitigations are grouped into classes of mitigating user-kernel, user-user, guest-host, guest-guest, and cross-thread exploits. For example, a Linux server running untrusted public guest VMs may be much more concerned around guest-host/guest-guest security than those running just in-house VMs.
David Kaplan of AMD last week sent out the third iteration of these Attack Vector Controls patches. The patches continue to device the new attack vector options and then restructuring existing MDS, TAA, MMIO, RFDS, SRBDS, GDS, Spectre V1, Retbleed, Spectre V2, BHI, SSB, L1TF, and SRSO mitigations within the different classes.
As summed up in the patch series:
“While many users may not be intimately familiar with the details of these CPU vulnerabilities, they are likely better able to understand the intended usage of their system. As a result, unneeded mitigations may be disabled, allowing users to recoup more performance. New documentation is included with recommendations on what to consider when choosing which attack vectors to enable/disable.”
Those interested in these proposed patches for the Linux kernel to more easily manage the CPU security mitigations can see the v3 patch series. The third iteration of the patches take care of some bugs and code clean-ups.