Hello. On Thu, Sep 19, 2024 at 02:52:31PM GMT, Pawan Gupta <pawan.kumar.gupta@xxxxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
