Google Publishes Latest Linux Core Scheduling Patches So Only Trusted Tasks Share A Core

Google engineer Joel Fernandes sent out the ninth version of their "core scheduling" patches for the Linux kernel that allows for allowing only trusted tasks to run concurrently on the same CPU core -- in cases where Hyper Threading is involved to safeguard the system against the possible security exploits.

Core Scheduling has been a popular topic since vulnerabilities like MDS and L1TF have come to light. Core Scheduling aims to make Hyper Threading safer and by only letting trusted tasks share a CPU core is a reasonable safeguard for still leaving Hyper Threading active on servers rather than disabling it in the name of security. DigitalOcean, Oracle, Google, and other major x86_64 players have all been interested in core scheduling and working on different solutions in order to keep HT/SMT active. Particularly for the major cloud server providers having to disable HT/SMT would be a big blow to their models.

Core Scheduling has made good progress this year and Google engineers are seemingly hopeful their solution will be mainlined. The v9 patches posted today are re-based against the latest Linux Git code while addressing previously raised issues/feedback. There is "hope that this version is acceptable to be merged" pending no new issues being raised.

THis core scheduling implementation mitigates user-space to user-space attacks as well as user-space to kernel-space attacks. The patches do not change any default kernel scheduler behavior but require tagged cgroups for laying out the trusted tasks that can share a core when it comes to evaluating whether a task can be placed on a sibling thread.

Outside of the security context, core scheduling can be useful for real-time purposes and other performance sensitive applications where wanting better control over SMT usage. Joel 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)." But depending upon the configuration and workload it's still quite possible for core scheduling to eat into the overall system performance but generally should not be as bad as disabling SMT/HT.

More details on this Core Scheduling v9 work via the kernel mailing list. This core scheduling implementation in its current form amounts to just over four thousand lines of new code.