[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bjgjmijirueqwwmuen5dr6v7yqdcivk6kwa6gbukn3rodfcwko@fb5yxyqycena>
Date: Tue, 14 Oct 2025 09:29:25 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: David Kaplan <david.kaplan@....com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>,
Peter Zijlstra <peterz@...radead.org>, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H . Peter Anvin" <hpa@...or.com>, Alexander Graf <graf@...zon.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 00/56] Dynamic mitigations
On Mon, Oct 13, 2025 at 09:33:48AM -0500, David Kaplan wrote:
> Dynamic mitigations enables changing the kernel CPU security mitigations at
> runtime without a reboot/kexec.
>
> Previously, mitigation choices had to be made on the kernel cmdline. With
> this feature an administrator can select new mitigation choices by writing
> a sysfs file, after which the kernel will re-patch itself based on the new
> mitigations.
>
> 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.
>
> Use
> ---
> As described in the supplied documentation file, new mitigations are
> selected by writing cmdline options to a new sysfs file. Only cmdline
> options related to mitigations are recognized via this interface. All
> previous mitigation-related cmdline options are ignored and selections are
> done based on the new options.
>
> Examples:
> echo "mitigations=off" > /sys/devices/system/cpu/mitigations
> echo "spectre_v2=retpoline tsa=off" > /sys/devices/system/cpu/mitigations
>
>
> There are several use cases that will benefit from dynamic mitigations:
>
> Use Cases
> ---------
> 1. Runtime Policy
>
> Some workflows rely on booting a generic kernel before customizing the system.
> cloud-init is a popular example of this where a VM is started typically with
> default settings and then is customized based on a customer-provided
> configuration file.
I'm not really a fan of this. It adds complexity to some areas that are
already struggling with too much complexity.
IMO this would need some REALLY strong justification, more than just
"hey, this makes things more convenient."
The mitigations should be a "set it and forget it" thing. I don't see
anything here which justifies the considerable maintenance burden this
would add for all existing and future mitigations.
--
Josh
Powered by blists - more mailing lists