Kernel watch

Jon Masters summarises the latest happenings in the Linux kernel, so that you don’t have to.

This month happens to align nicely between kernel cycles. As a consequence, since last issue Linus Torvalds has announced both the final GA release of Linux 5.13, as well as the first Release Candidate (RC1) for what will become Linux 5.14. We largely covered the 5.13 release in last month’s issue, which includes initial support for Apple M1 processor devices among its many other features. That release came just in time for the US 4 July holiday, and perhaps as a consequence the beginning of the 5.14 cycle was a little quieter.

The same cannot be said of the Linux Kernel Mailing List (LKML), where there has been quite some debate lately about the latest attempt to merge support for the Rust programming language into the kernel. Proponents point to the many security issues with C over the years, as well as the popularity of the new language to attract additional developers. But at the same time, attempts to merge support (which has been formally requested) seem premature – not the least because few practical users exist yet. A number of prominent developers have called for a real-world driver to be (re)written in Rust to demonstrate.

I’m thinking that it would be great to take the Rust patches for a spin and write about the experience. Stay tuned in the next few months to hear about that.

Core scheduling lands in 5.14

Linux 5.14 will include among its top-level features the merging of “core scheduling” support. This is a feature that has been under development for the past three years, kicking into overdrive around the time of the big wave of speculative execution cache side-channel security vulnerabilities that began to be reported in 2018 and continue to bring periodic unhappiness to this day.

When these security vulnerabilities hit, there was a renewed interest in very carefully isolating workloads from one another, especially in cloud settings.

Many (especially x86) microprocessors implement a resource sharing feature known as “simultaneous multi-threading” (SMT) in which resources within each core are split into multiple “logical” processors. You might see an example of this with your own laptop or desktop. It may, for example, be described as a “quad core”, but report having eight processors when you use the Linux top utility. This is because while there are really only four true CPUs (cores), each of those is provisioned as logical processors that will present separately, for example in /proc/cpuinfo.

The reason for this is that it is (relatively) seldom that a core is fully utilised. More often than not only a subset of execution units or other core resources are being used for a specific workload (application), meaning that they could be made available to another application. SMT is the means by which this can be achieved in the hardware. The overall result is approximately a 30 per cent speed up compared with running two applications on a single core. This splitting of resources happens automatically, including reallocating all core resources to a single logical processor if its sibling subsequently goes to sleep (in other words, becomes idle).

Resource sharing in this manner is great, much of the time, but it can become a significant problem when a hostile actor can run code on a sibling logical processor on the same core as a sensitive application. Another worrying scenario is if a core becomes split between two different virtual machines running workloads of two different users. With the rise of virtualisation, and the public cloud, it became common to talk about “vCPUs” (virtual CPUs). In many cases, these are actually sibling threads on a core.

This means that when you spin up a “2 vCPU” cloud instance, it’s often only one real CPU core. This little-known fact actually makes mitigating some of the security challenges a little easier because it can be arranged that both threads of a single core are always given to the same virtual machine (or conversely that nothing else runs on the sibling at the same time). The Linux core scheduling patches add a concept of “cookies” (note these have nothing to do with the web) that define which workloads can share a physical CPU. An administrator (or a virtual machine manager) can thus ensure that different (or at least security sensitive) workloads always have different cookies, and remain isolated.