A big patch series was posted today for the Linux kernel that would allow enabling/disabling CPU security mitigations at run-time rather than the current handling that can only be managed at boot-time via various Linux kernel command-line arguments. Thus due to changing security needs, differing workloads mandating different CPU security concerns and the like, this proposed feature would allow Spectre, Meltdown, and other CPU security mitigations to all be toggled at run-time.
AMD engineer David Kaplan who recently wrapped up work on the Attack Vector Controls for the Linux kernel has next turned his attention to Dynamic Mitigations: the ability to enable/disable CPU security mitigations at run-time without needing a reboot or Kexec’ing to a new kernel.
To overcome the limitation of only being able to change CPU security mitigations at boot time, the patches sent out today under a “request for comments” would allow writing the CPU security mitigation option values to /sys/devices/system/cpu/mitigations. For example, echo “mitigations=off” > /sys/devices/system/cpu/mitigations to disable all the CPU security mitigations or other existing kernel boot argument values like “spectre_v2=retpoline tsa=off” to this new sysfs mitigations file.
“As the performance cost of CPU mitigations can be significant, selecting the right set of mitigations is important to achieve the correct balance of performance/security.”
Among the intended use-cases are for better run-time policy handling, changing mitigations as a result of new CPU security findings but without having to reboot the systems/servers, quick mitigation testing to avoid to reboot, etc.
AMD’s David Kaplan went on to explain how this run-time patching of the kernel is handled for the mitigations:
“Re-patching the kernel is expected to be a very rare operation and is done under very big hammers. All tasks are put into the freezer and the re-patching is then done under the (new) stop_machine_nmi() routine.
To re-patch the kernel, it is first reverted back to its compile-time state. The original bytes from alternatives, retpolines, etc. are saved during boot so they can later be used to restore the original kernel image. After that, the kernel is patched based on the new feature flags.
This simplifies the re-patch process as restoring the original kernel image is relatively straightforward. In other words, instead of having to re-patch from mitigation A to mitigation B directly, we first restore the original image and then patch from that to mitigation B, similar to if the system had booted with mitigation B selected originally.”
Kaplan observed the run-time re-patching of the kernel to take around 50 ms.
Those interested in the big 56 patch RFC series can find the proposed Dynamic Mitigations code on the Linux kernel mailing list.
