Re: [RFC PATCH 00/56] Dynamic mitigations

Brendan Jackman
2025-10-16T12:21:28Z

On Tue Oct 14, 2025 at 6:06 PM UTC, David Kaplan wrote:
>> From: Josh Poimboeuf <jpoimboe@kernel.org>
>> > 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.
>>
>
> The problem is there are environments like the one outlined where you can't just 'set it and forget it' because the kernel needs it set at boot-time, but in these environments you don't know how to configure the system until much later in boot. So you end up running with the default settings all the time, even if you don't need them. And the default settings can have significant performance impacts in many cases.
>
> The cloud guys on this thread may be able to offer some additional color here since I believe that's where you're most likely to have this situation.
>
> --David Kaplan

There's definitely a desire for more dynamic control at Google too,
similar to what Boris said.

Getting the config right is tricky and let's not forget it's
fundamentally a moving target as David noted. Even without dependence on
cloud-init type stuff, it's very useful to be able to change mitigations
on a timescale that's faster than we can reboot hosts.