In 2018, the cybersecurity landscape was permanently altered by the discovery of hardware-level side-channel vulnerabilities, most notably Meltdown and Spectre. These vulnerabilities proved that the physical silicon in modern CPUs was fundamentally flawed in its implementation of speculative execution.
One of the most devastating variants targets Simultaneous Multi-Threading (SMT), known commercially as Intel Hyper-Threading. In SMT, two logical CPU threads run on the exact same physical CPU core, sharing the same L1 cache. Attackers discovered that if a malicious process (Thread A) runs on the same physical core as a highly secure process (Thread B), Thread A can execute a timing attack against the shared L1 cache (L1TF/MDS vulnerabilities) and mathematically extract Thread B’s raw memory—stealing SSL private keys, passwords, or the Linux kernel memory itself.
For cloud providers hosting virtual machines for competing tenants, this meant Tenant A could steal data from Tenant B simply because the hypervisor scheduled their workloads on the same physical CPU core.
Initially, the only mitigation was to completely disable Hyper-Threading in the BIOS, instantly destroying 20-30% of the server’s processing performance. However, starting with kernel 5.14, Linux introduced a surgical software mitigation: Core Scheduling.
This guide explains how Linux Core Scheduling works and how to implement it to neutralize SMT side-channel attacks without disabling Hyper-Threading.
Understanding Core Scheduling Architecture
The Linux kernel scheduler (CFS – Completely Fair Scheduler) treats logical threads as independent processors. If you have a 4-core, 8-thread CPU, the kernel sees 8 CPUs. It blindly schedules tasks onto whatever thread is available, without caring if the two threads on Core 0 are running workloads that hate each other.
Core Scheduling changes this logic by introducing a “trust boundary” (a cookie).
When you enable Core Scheduling, the kernel scheduler applies a strict rule: A physical CPU core can only execute tasks that share the exact same trust cookie at the exact same time.
If a highly secure database (Cookie Red) is running on Thread 0, and a random, untrusted user script (Cookie Blue) is assigned to Thread 1, the kernel will refuse to execute the Blue script. It will literally force Thread 1 to sit idle (injecting idle cycles) until the Red database finishes its timeslice on Thread 0.
By guaranteeing that mutually untrusted tasks never share a physical core simultaneously, the L1 cache timing attack becomes mathematically impossible. You retain the performance benefits of Hyper-Threading for trusted tasks, while mitigating the security risk for untrusted tasks.
Step 1: Verifying Kernel Support
Core Scheduling requires a modern Linux kernel (5.14 or newer) compiled with the specific CONFIG_SCHED_CORE option.
Check your kernel configuration:
zgrep CONFIG_SCHED_CORE /proc/config.gz
(If your distribution uses a different config path, check /boot/config-$(uname -r)).
You should see CONFIG_SCHED_CORE=y.
You must also ensure that SMT (Hyper-Threading) is actually enabled on the system, otherwise Core Scheduling is irrelevant.
cat /sys/devices/system/cpu/smt/control
This should output on.
Step 2: Interacting with Core Scheduling via prctl
Core Scheduling is not a global toggle switch; it is a highly granular API controlled via the prctl() system call. You assign a specific process (and its children) into a unique trust group.
While developers can program this directly in C, systems administrators interact with it using the chrt utility from the util-linux package.
To launch a new application (e.g., a Redis server) in its own isolated Core Scheduling trust group, use the -a or --sched-core flag:
sudo chrt --sched-core -p 0 redis-server /etc/redis/redis.conf
The kernel generates a unique 64-bit cookie for this Redis instance. If the server has 16 physical cores and 32 threads, the kernel guarantees that whenever this Redis process executes on a thread, the sibling thread on that physical core will only execute other processes spawned by this specific Redis instance. If no sibling processes exist, the sibling thread is forced to idle.
Step 3: Applying Core Scheduling to Virtual Machines (KVM)
The primary use case for Core Scheduling is isolating Virtual Machines in a multi-tenant hypervisor (KVM/QEMU) environment.
Modern versions of libvirt (the KVM management API) natively support Linux Core Scheduling.
To configure a VM to run in a protected Core Scheduling group, you edit the VM’s XML definition:
virsh edit my-secure-vm
Locate the <cputune> block and add the <core_sched> element:
<domain>
...
<cputune>
<core_sched/>
</cputune>
...
</domain>
When you start the VM, libvirt automatically invokes the prctl system call, grouping all of the QEMU vCPU threads for that specific VM under a single, unique trust cookie.
This guarantees that the virtual CPUs of my-secure-vm will never share a physical host core with the virtual CPUs of any other tenant’s VM, completely neutralizing L1TF, MDS, and cross-VM side-channel data extraction.
Conclusion
Disabling Hyper-Threading to mitigate hardware side-channel attacks was a blunt-force trauma to server performance, heavily penalizing cloud providers and enterprise data centers. By implementing Linux Core Scheduling, systems architects can surgically define trust boundaries around high-value processes and virtual machines. The kernel scheduler intelligently prevents hostile neighbors from executing simultaneously on the same physical silicon, allowing organizations to reclaim the massive performance benefits of SMT without compromising isolation integrity.