Re: [RFC PATCH 07/56] x86/bugs: Reset spectre_v2_user mitigations

Borislav Petkov
2025-12-03T12:31:58Z

On Mon, Dec 01, 2025 at 04:53:58PM +0000, Kaplan, David wrote:
> What does it mean for a 'task to comply'?

If the task has selected a mitigation which is not compatible with the setting
the admin selected later, that task's mitigation settings will be changed when
it goes through __switch_to.

> I think it's one thing for the task to ask for a mitigation and then the
> admin goes and overrides it with a system-wide setting. That doesn't worry
> me too much...the admin should be able to do that.

Ack.

> But this particular interface is tricky because it returns EPERM in some
> cases, like when the task asks for something but the admin doesn't allow it.
> In theory you could have processes that don't expect to see such an error in
> the middle of execution...that is, they might try to configure settings
> initially, find that succeeds, and then later modify them and not expect
> them to fail. Brendan is saying maybe that's ok, are you aligned with that?

No, not in the middle of execution - their mitigation setting will get changed
when they get scheduled. Example:

1. task sets PR_SPEC_DISABLE and enables indirect branches for it
2. admin comes in and disables indirect branches system-wide - i.e.,
SPECTRE_V2_USER_STRICT.
3. task comes through schedule() and it gets PR_SPEC_ENABLE forced on it

Makes sense?

> If so, I don't think we really have to do anything special then...the
> behavior of this prctl() may change due to dynamic mitigation changes and
> userspace might see unexpected EPERM errors if that happens.

I'm thinking the task will run the prctl() when it starts. Then, after the
system-wide setting has been changed, the above will happen.

A *new* task will then see EPERM and should be able to handle it.

Or am I missing a case...?

Thx.

--
Regards/Gruss,
Boris.