Better CPU vulnerability mitigation configuration

Modern CPUs all have multiple hardware vulnerabilities that the kernel needs to mitigate; the 6.13 kernel has workarounds for 14 security-sensitive CPU bugs just on x86_64. Several of those have multiple variants, or multiple mitigations that apply on different microarchitectures. There are different kernel command-line options for each of these mitigations, which leads to a confusing situation for users trying to figure out how to configure their systems. David Kaplan recently posted a patch set that adds a single, unified command-line option for controlling mitigations and simplifies the logic for detecting, configuring, and applying them as well. If it is merged, the patch set could make it much easier for users to navigate the complicated web of CPU vulnerabilities and their mitigations.

The kernel provides information about the vulnerabilities it's aware of via sysfs. The /sys/devices/system/cpu/vulnerabilities/ directory contains a file for each known class of attack, with information about whether the system is vulnerable, and which mitigations have been enabled. Some of these are easy to interpret, and merely state whether a mitigation is turned on or off. Others are somewhat cryptic. For example, my x86_64 machine has the following to say about Spectre v2:

    Mitigation: Enhanced / Automatic IBRS; IBPB: conditional; RSB filling; \
        PBRSB-eIBRS: SW sequence; BHI: BHI_DIS_S

This line means that Enhanced Indirect Branch Restricted Speculation (Enhanced IBRS), Indirect Branch Predictor Barrier (IBPB), Return Stack Buffer (RSB) filling, Post-barrier Return Stack Buffer Enhanced IBRS (PBRSB-eIBRS), and Branch History Injection (BHI) are all enabled by the kernel. Enhanced IBRS is a technique that prevents the CPU from speculating through indirect branches. IBPB introduces a barrier to prevent code from before the barrier from influencing branch predictions after the barrier. RSB filling makes sure that any return addresses the CPU might speculate about when encountering a return instruction are overwritten on context switch. PBRSB-eIBRS extends that protection to cover exits from virtual machines on some CPUs. Finally, BHI protects against code that manipulates the branch predictor in order to speculate through a branch. Theoretically, all of those mitigations combined should render my computer mostly immune to Spectre-based attacks.

Each of those mitigations is controlled with one of the spectre_v2=, spectre_v2_user=, and spectre_bhi= kernel command-line options. The other mitigations have their own idiosyncratically named options. The kernel's documentation on hardware vulnerabilities describes the various options, but knowing what the best configuration for a given system is requires knowledge about how the different vulnerabilities can be abused. In practice, most users probably leave the settings on their defaults, which is good for security but comes with a noticeable performance penalty.

Kaplan's patch restructures the kernel's mitigation-configuration logic to depend on a single command-line option, mitigations=. That option already exists, but can currently only be set to "off" or "auto". Kaplan's patch extends it so that the user can append a semicolon and a comma-separated list of specific attack vectors not to bother mitigating:

• no_user_kernel — don't mitigate attacks from malicious user-space programs attempting to leak kernel data.
• no_user_user — don't mitigate attacks from one user-space program on another.
• no_guest_host — don't mitigate attacks from a malicious virtual machine trying to exfiltrate data from its hypervisor.
• no_guest_guest — don't mitigate attacks from one virtual machine on another.
• no_cross_thread — don't mitigate attacks from a program or virtual machine running on one simultaneous multithreading (SMT) core against code running on its sibling core.

The default is to mitigate all of these attack vectors, so there's no separate setting for "on". The exception is cross-thread attacks, which can generally only be completely prevented by disabling simultaneous multithreading. That's usually not desirable because of the large performance impact, so users need to specify "auto,nosmt" instead of just "auto" in order to get that behavior. Generally, leaving all of the mitigations enabled is a safe choice. But for systems that won't run virtual machines, for example, adding mitigations=auto;no_guest_host,no_guest_guest to the kernel command line could win back some lost performance. In Kaplan's cover letter, he justifies switching to this set of command-line options:

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.

When the user specifies one of the new attack-vector options, the kernel uses its knowledge about which bugs exist in the computer's CPU to turn on the best mitigations for that case. For now, they're only effective on x86 (and x86_64), pending input from the maintainers for other architectures about which mitigations should be associated with each option. The existing mitigation-specific command-line options will continue to function as normal, although they will probably see a good deal less use going forward.

This particular design is the result of an extended discussion on the previous version of Kaplan's patch set. That version had five different new command-line options, one for each potential attack vector. Reviewers found that design unnecessarily complicated, though, and eventually agreed on the simpler interface described above. Pawan Gupta, Josh Poimboeuf, and Kaplan all suggested various ideas, but Borislav Petkov made the suggestion that ended up being closest to what Kaplan adopted in the new version of the patch set.

The reviewers were not completely convinced by Kaplan's taxonomy of potential attacks, although they seemed to generally agree that it was better than the confusing status quo. Poimboeuf thought that the cross-thread group, in particular, didn't make much sense to separate from the others. In a cross-thread attack, the code that is running on the attacking SMT core (also called a hardware thread) must be either a user-space program or a virtual machine; therefore, Poimboeuf argued, any cross-thread attack should already fall under one of the other four categories that Kaplan set out.

Kaplan didn't disagree, although he had noted earlier in the discussion that disabling SMT has to be treated specially. Still, even with the complication around SMT, Kaplan's command-line options are a good deal less complicated than the existing set.

The internal logic for selecting mitigations — which also received substantial attention from reviewers, although only in the form of code style comments — has also been cleaned up. Previously, the code was somewhat labyrinthine. With Kaplan's changes, the functionality should be the same, but the implementation has been split up into a "select", "update", and "apply" function for each mitigation the kernel knows about. The select function determines whether the mitigation ought to be enabled, the update function allows the specific configuration for the mitigation to be changed depending on which other mitigations have been selected, and the apply function does the actual job of applying the mitigation to the kernel.

The most recent version of Kaplan's patch set was posted on March 10, and therefore hasn't had much time to attract any additional discussion. Given the positive reception of the previous version, it seems quite possible that these new command-line options will be available for x86 and x86_64 soon, hopefully with other architectures to follow.