admin-guide/hw-vuln/core-scheduling.rst

1 .. SPDX-License-Identifier: GPL-2.0
15 ----------------
16 A cross-HT attack involves the attacker and victim running on different Hyper
18 full mitigation of cross-HT attacks is to disable Hyper Threading (HT). Core
19 scheduling is a scheduler feature that can mitigate some (not all) cross-HT
21 user-designated trusted group can share a core. This increase in core sharing
27 core involves additional overhead - especially when the system is lightly
29 scheduling to perform more poorly compared to SMT-disabled, where N_CPUS is the
33 -----
35 Using this feature, userspace defines groups of tasks that can be co-scheduled
55     - ``PR_SCHED_CORE_GET`` -- get core_sched cookie of ``pid``.
56     - ``PR_SCHED_CORE_CREATE`` -- create a new unique cookie for ``pid``.
57     - ``PR_SCHED_CORE_SHARE_TO`` -- push core_sched cookie to ``pid``.
58     - ``PR_SCHED_CORE_SHARE_FROM`` -- pull core_sched cookie from ``pid``.
65     ``PR_SCHED_CORE_SCOPE_``-prefixed macro constants.  For example, if arg4
80 cookie and thus a core is to rely on the fact that the core-sched cookie is
83 same core-sched group.
94 ---------------------
100 siblings of a core such that all the selected tasks running on a core are
108 highest priority task with the same cookie is selected if there is one runnable
110 the idle task is selected.  Idle task is globally trusted.
112 Once a task has been selected for all the siblings in the core, an IPI is sent to
113 siblings for whom a new task was selected. Siblings on receiving the IPI will
114 switch to the new task immediately. If an idle task is selected for a sibling,
119 Forced-idling of hyperthreads
122 tasks selected to be scheduled are of the highest priority in a core.  However,
130 When the highest priority task is selected to run, a reschedule-IPI is sent to
136    A      idle -> user space      user space -> idle
137    B      idle -> user space      guest -> idle
138    C      idle -> guest           user space -> idle
139    D      idle -> guest           guest -> idle
143 the destination CPU immediately into kernel mode from user space, or VMEXIT
157 and are considered system-wide trusted. The forced-idling of siblings running
158 cookie-0 tasks is also avoided.
164 Limitations of core-scheduling
165 ------------------------------
177 IPI. Even though cache is flushed on entry to user mode, victim tasks on siblings
181 Open cross-HT issues that core scheduling does not solve
182 --------------------------------------------------------
186 running in user mode and the others running in kernel mode. Even though all
218 ---------------
219 The main use case for Core scheduling is mitigating the cross-HT vulnerabilities
222 - Isolating tasks that needs a whole core: Examples include realtime tasks, tasks
224 - Gang scheduling: Requirements for a group of tasks that needs to be scheduled