Re: [RFC PATCH 00/56] Dynamic mitigations

Nicolas Bouchinet
2025-10-16T13:55:12Z

[snip]
> > LOCKDOWN_DEV_MEM is an integrity reason and should not be used for this
> > scenario.
> > I'd rather like to add a new Lockdown reason in the confidentiality set,
> > maybe LOCKDOWN_CPU_MITIGATION ?
> >
>
> Ok, that makes sense. Just to clarify, would that mean something like the below:
>
> diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> index 3f9410dee67c..9b4864f84146 100644
> --- a/drivers/base/cpu.c
> +++ b/drivers/base/cpu.c
> @@ -691,6 +691,9 @@ ssize_t cpu_write_mitigation_options(struct device *dev,
> struct device_attribute *attr,
> const char *buf, size_t count)
> {
> + if (security_locked_down(LOCKDOWN_CPU_MITIGATIONS))
> + return -EPERM;
> +
> /* Save and filter the provided options. */
> cpu_filter_mitigation_opts(buf);
>
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 92ac3f27b973..81cb52cf2111 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -153,6 +153,7 @@ enum lockdown_reason {
> LOCKDOWN_TRACEFS,
> LOCKDOWN_XMON_RW,
> LOCKDOWN_XFRM_SECRET,
> + LOCKDOWN_CPU_MITIGATIONS,
> LOCKDOWN_CONFIDENTIALITY_MAX,
> };

You should also add an entry to the lockdown_reasons array in
`security/security.c` with a description of the reason.

Nicolas