Linux Core Scheduling Nears The Finish Line To Avoid Flipping Off HT

Besides Linux kernel developers still working to optimize code due to Retpolines overhead three years after Spectre rocked the ecosystem, another area kernel developers have still been actively working on is core scheduling for controlling the behavior of what software can share CPU resources or run on the sibling thread of a CPU core. That core scheduling work is finally closer to the mainline Linux kernel.

Core scheduling has been an area of much interest by different companies -- especially public cloud providers -- due to the growing number of side-channel vulnerabilities affecting Intel Hyper Threading and some security recommendations to disable this form of SMT. With core scheduling, there is control for ensuring trusted and untrusted tasks don't share a CPU core / sibling thread and thereby help reduce the security implications of keeping Intel Hyper Threading enabled.

The core scheduling work when effectively used should be effective at mitigating user-space to user-space attacks and user to kernel attacks. But the default behavior with patched kernels is not to change the scheduler behavior but is left up to the user/administrator for assigning the tasks that can run simultaneously on the same core or not. For identifying tasks that can share a CPU core/resources, the core scheduling work allows doing so via cgroups and a per-tak prctl interface.

Google has been one of the vendors involved in the Linux core scheduling work to ensure only trusted tasks share a core, when the functionality is enabled. That work has been building up in the sched/core-sched branch while yesterday the latest patches were mailed out for getting the work over the finish line, once merged.

Enclosed is interface related core scheduling patches and one for migration. The main core scheduling patches were already pulled in by Peter with these bits left.

Main changes are the simplification of the core cookie scheme, new prctl code, and other misc fixes based on Peter's feedback.

While driven by the security implications around keeping Intel Hyper Threading active, core scheduling can also be useful for real-time computing and performance-sensitive software where wanting to control how tasks make use of SMT. In the aforementioned patch notes it is mentioned, "ChromeOS testing shows 300% improvement in keypress latency on a Google docs key press with Google hangout test (the maximum latency drops from 150ms to 50ms for keypresses)."

These remaining core scheduling patches can be seen via this mailing list thread. We'll see in the coming weeks if this work manages to get aligned for appearing in the upcoming 5.13 kernel cycle or not.