Re: [PATCH v4] security: Expand task_setscheduler LSM hook

[Aaron Tomlin]

On Sun, Jul 19, 2026 at 09:41:56PM -0400, Aaron Tomlin wrote:
> At present, the task_setscheduler LSM hook provides security modules
> with the opportunity to mediate changes to a task's scheduling policy by
> inspecting the requested sched_attr. However, when invoked via
> sched_setaffinity(), the hook lacks visibility into the actual CPU
> affinity mask being requested. Consequently, security modules are
> entirely blind to the target CPUs and cannot make granular access
> control decisions based on spatial isolation.
> 
> In modern multi-tenant and real-time environments, CPU isolation is a
> critical boundary. The inability to audit or restrict specific CPU
> pinning requests limits the effectiveness of security policies,
> particularly when attempting to shield isolated or cryptographic cores
> from unprivileged or compromised tasks.
> 
> This patch expands the security_task_setscheduler() hook signature to
> include a pointer to the requested cpumask alongside the existing
> sched_attr. Because this is a shared hook used for multiple scheduling
> attribute changes, call sites that do not modify CPU affinity are
> updated to safely pass NULL for the mask. To protect against unverified
> dereferences, the parameter is annotated with __nullable in the LSM hook
> definition, ensuring the BPF verifier mandates explicit NULL checks for
> attached eBPF programs.
> 
> Historically, SELinux has governed all scheduling alterations under a
> single, monolithic PROCESS__SETSCHED access vector. However, by
> inspecting fields such as attr->sched_policy or attr->sched_priority, a
> security module can introduce granular access controls. For instance,
> differentiating between standard time-sharing policies and
> latency-sensitive real-time policies.
> 
> This change updates all in-tree security modules (SELinux and Smack) to
> accommodate the new parameter mechanically, while providing LSMs with
> the necessary context to enforce strict affinity policies.
> 
> Signed-off-by: Aaron Tomlin <atomlin@xxxxxxxxxxx>
> ---
> Changes since v3:
> 
>  - Expanded the task_setscheduler LSM hook to accept the 'sched_attr'
>    payload, enabling BPF and other LSMs to inspect scheduling attributes
>    (Peter Zijlstra)
> 
>  - Updated all call sites for security_task_setscheduler() to correctly
>    pass the attr structure when available, or NULL otherwise
>    (Peter Zijlstra)
> 
>  - Added the necessary forward declaration for struct sched_attr to
>    include/linux/security.h
> 
>  - Linked to v3: https://lore.kernel.org/lkml/20260526142838.774711-1-atomlin@xxxxxxxxxxx/
> 
> Changes since v2:
> 
>  - Dropped patch 1. This is to be addressed by the cgroup cpuset
>    maintainer (Waiman Long)
> 
>  - Dropped patch 3. Will be submitted as a separate patch (Paul Moore)
> 
>  - Linked to v2: https://lore.kernel.org/lkml/20260509213803.968464-1-atomlin@xxxxxxxxxxx/
> 
> Changes since v1:
> 
>  - Reordered the allocation and user-copy of new_mask in the MIPS
>    architecture's mipsmt_sys_sched_setaffinity() to occur before the
>    LSM hook is invoked. This ensures the security modules evaluate a fully
>    populated mask rather than uninitialised memory, while cleanly handling
>    error unwinding
> 
>  - Updated cpuset_can_fork() to pass the destination cpuset's effective CPU
>    mask instead of NULL
> 
>  - Linked to v1: https://lore.kernel.org/lkml/20260509164847.939294-1-atomlin@xxxxxxxxxxx/
> 
> Signed-off-by: Aaron Tomlin <atomlin@xxxxxxxxxxx>
> ---

Hi Paul,

I hope this message finds you well.

I am writing to follow up on the submission of [PATCH v4] security: Expand
task_setscheduler LSM hook [1].

Casey [2] has kindly reviewed the Smack portion, and to the best of my
knowledge, the suggestions raised across earlier revisions have now been
fully addressed.

Appreciating that you have many competing demands on your time, I should be
very grateful to learn whether you have any further thoughts or
reservations regarding this series, or if any additional adjustments are
required on my part before it might be considered for the LSM tree.

Thank you very much for your time and continued guidance!

[1]: https://lore.kernel.org/lkml/20260720014156.459386-1-atomlin@xxxxxxxxxxx/
[2]: https://lore.kernel.org/lkml/31679bf5-a0cb-41b6-bc1d-7833c4fc9744@xxxxxxxxxxxxxxxx/

Kind regards,
-- 
Aaron Tomlin