Hi,

This is an experimental series exploring the feasibility of selectively
applying CPU vulnerability mitigations on a per-process basis. The
motivation behind this work is to address the performance degradation
experienced by trusted user-space applications due to system-wide CPU
mitigations.

Currently, the mitigations are applied universally across the system,
without discrimination between trusted and untrusted user-space processes.
This results in a performance penalty for all applications, regardless of
their trustworthiness. The proposed solution aims to provide a mechanism
for system administrators to explicitly mark certain applications as
trusted, allowing them to bypass these mitigations and regain lost
performance.

The series introduces a new cgroup attribute and a separate kernel
entry/exit path that can be used to selectively disable CPU mitigations for
processes that are deemed trustworthy by the system administrator. This
approach provides a tool to the administrator who understands the security
implications and is aware of trustworthiness of the applications that they
care.

The rationale for choosing the cgroup interface over other potential
interfaces, such as LSMs, is cgroup's inherent support for core scheduling.
Core scheduling allows the grouping of tasks such that they are scheduled
to run on the same cores. By leveraging core scheduling, we can minimize
the performance overhead caused by the MSR writes during context switching
between trusted and untrusted processes. With the end goal being trusted
and untrusted processes run on separate cores, enhancing the security.

Patch 1 adds the unmitigated entry/exit path.
Patch 2 provides a cgroup knob to bypass CPU mitigations.

This series is lightly tested. Feedback and discussion are welcome.

TODO:
- Add CONFIG_MITIGATION_PER_PROCESS
- Add support for skipping other mitigations like RSB filling.
- Update suspend/resume paths to handle the new entry/exit path.
- Should child processes inherit the parent's unmitigated status?
- Add documentation.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
Pawan Gupta (2):
      x86/entry_64: Add a separate unmitigated entry/exit path
      cpu/bugs: cgroup: Add a cgroup knob to bypass CPU mitigations

 arch/x86/entry/entry_64.S        | 66 +++++++++++++++++++++++++++++++++-------
 arch/x86/include/asm/proto.h     | 15 ++++++---
 arch/x86/include/asm/ptrace.h    | 15 ++++++---
 arch/x86/include/asm/switch_to.h | 10 ++++++
 arch/x86/kernel/cpu/bugs.c       | 21 +++++++++++++
 arch/x86/kernel/cpu/common.c     |  2 +-
 include/linux/cgroup-defs.h      |  3 ++
 kernel/cgroup/cgroup.c           | 42 +++++++++++++++++++++++++
 kernel/sched/core.c              |  2 +-
 9 files changed, 155 insertions(+), 21 deletions(-)
---
base-commit: 98f7e32f20d28ec452afb208f9cffc08448a2652
change-id: 20240919-selective-mitigation-6d02c4bbb72b

-- 
Thanks,
Pawan

Hello.

On Thu, Sep 19, 2024 at 02:52:31PM GMT, Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote:
> This is an experimental series exploring the feasibility of selectively
> applying CPU vulnerability mitigations on a per-process basis. The
> motivation behind this work is to address the performance degradation
> experienced by trusted user-space applications due to system-wide CPU
> mitigations.

This is an interesting idea (like an extension of core scheduling).

> The rationale for choosing the cgroup interface over other potential
> interfaces, such as LSMs, is cgroup's inherent support for core scheduling.

You don't list prctl (and process inheritance) interface here.

> Core scheduling allows the grouping of tasks such that they are scheduled
> to run on the same cores. 

And that is actually the way how core scheduling is implemented AFAICS
-- cookie creation and passing via prctls.
Thus I don't find the implementation via a cgroup attribute ideal.

(I'd also say that cgroups are more organization/resource domains but
not so much security domains.)


> - Should child processes inherit the parent's unmitigated status?

Assuming turning off mitigations is a a privileged operation, the
fork could preserve it. It would be upon parent to clear it up properly
before handing over execution to a child (cf e.g. dropping uid=0).

HTH,
Michal

On Fri, Sep 27, 2024 at 05:52:35PM +0200, Michal Koutný wrote:
> Hello.
> 
> On Thu, Sep 19, 2024 at 02:52:31PM GMT, Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote:
> > This is an experimental series exploring the feasibility of selectively
> > applying CPU vulnerability mitigations on a per-process basis. The
> > motivation behind this work is to address the performance degradation
> > experienced by trusted user-space applications due to system-wide CPU
> > mitigations.
> 
> This is an interesting idea (like an extension of core scheduling).
> 
> > The rationale for choosing the cgroup interface over other potential
> > interfaces, such as LSMs, is cgroup's inherent support for core scheduling.
> 
> You don't list prctl (and process inheritance) interface here.

Apologies for the oversight. prctl is indeed the interface that Core
scheduling uses to group tasks. Cgroup was the initially proposed interface
but that later got changed to prctl.

> > Core scheduling allows the grouping of tasks such that they are scheduled
> > to run on the same cores. 
> 
> And that is actually the way how core scheduling is implemented AFAICS
> -- cookie creation and passing via prctls.
> Thus I don't find the implementation via a cgroup attribute ideal.

Problem with prctl is that a process can't set its own skip-mitigation
status, unless it is privileged. So a privileged process has to spawn the
workload that needs to be unmitigated. This is not ideal for an application
that wants to selectively apply mitigations.

> (I'd also say that cgroups are more organization/resource domains but
> not so much security domains.)

Agree.

> > - Should child processes inherit the parent's unmitigated status?
> 
> Assuming turning off mitigations is a a privileged operation, the
> fork could preserve it. It would be upon parent to clear it up properly
> before handing over execution to a child (cf e.g. dropping uid=0).

IIUC, skip-mitigation should be a capability that can be inherited by child
processes, or can be set for an executable file. If we want to leverage
Core scheduling, it will be callenging to have all trusted processes in the
system have the same cookie. But, all child processes of a trusted process
would inherit the skip-mitigation status and same cookie, so they can be
co-sccheduled.