David Kaplan who is a Senior Fellow at AMD focused on security technologies has published an initial set of Linux kernel patches for "Attack Vector Controls" in rethinking the CPU security mitigation handling. The proposed Attack Vector Controls makes it easier to manage desired security mitigations to have enabled/disabled based upon intent of the system rather than having to be knowledgeable about individual CPU security vulnerabilities and the various tuning knobs.

The Attack Vector Controls aren't some new security mitigation or the like but restructuring the existing CPU security mitigation code within the Linux kernel and making it easier to manage and to handle different CPU security mitigation state based upon the intended role of the system.

AMD's David Kaplan explained in the "request for comments" patch series on Attack Vector Controls:

"This RFC restructures arch/x86/kernel/cpu/bugs.c and proposes new command line options to make it easier to control which CPU mitigations are applied. These options select relevant mitigations based on chosen attack vectors, which are hopefully easier for users to understand.

This patch series will also be part of a discussion at the LPC x86 microconference next week.

...

The rest of the patches define new "attack vector" command line options to make it easier to select appropriate mitigations based on the usage of the system. 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."

Rather than managing CPU security mitigation tunables one-by-one, the Attack Vector Controls proposal is currently split into five sections for mitigations around user-kernel interactions, user-user interactions, guest-host interactions, guest-guest interactions, and cross-thread mitigations. With the mitigate_user_kernel=, mitigate_user_user=, mitigate_guest_host=, mitigate_guest_guest=, mitigate_cross_thread= boot parameters you can set these areas to on/off depending upon whether you are concerned about CPU security vulnerabilities of a particular type. Such as systems being deployed by hyperscalers to the public cloud may be more concerned about guest/guest and guest/host vulnerabilities and less about cross-thread vulnerabilities if all sibling threads end up being assigned to the same VM anyhow.

Breaking down the mitigation handling to these different classes should make it much easier to manage rather than worrying about individual vulnerabilities or new vulnerabilities that may later come to light if you are aiming to protect the system/server against a particular class of issues and given the role of a particular system less concerned about other classes and there wanting to regain as much performance as possible.

Those wanting to learn more about this proposed Attack Vector Controls for Linux can see [1]this patch series now out as a request for comments. This idea will be discussed further next week at the Linux Plumbers Conference. We'll see how much more interest there is in this type of mitigation handling.

The proposed Linux Attack Vectors doesn't change any of the default mitigations used by the Linux kernel aside from the automatic disabling of VM-based attack vectors for when the Linux kernel is built without KVM support enabled.



[1] https://lore.kernel.org/lkml/20240912190857.235849-1-david.kaplan@amd.com/T/#m81d5854d625e41baa18888a6183d0c7b56d05e36