Kernel Watch

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

“It can be painful when the vulnerability mitigation suggests that such threads be disabled”

Linus Torvalds announced the 5.2-rc5 (Release Candidate 5) kernel, noting that the release was settling down with “nothing...particularly scary-looking”.

Assuming that nothing scary does emerge, 5.2 should be released soon after we go to press, meaning that we will have a full rundown of the new features next issue. This includes support for “pressure-stall monitors” (userspace monitoring of sources of memory pressure that could later slow down a

system), the new “mitigations=” one stop shop for controlling security mitigations, and a CLONE_PIDFD flag in the clone() system call to allow userspace (e.g. Android) to monitor processes in a race free manner.

KVM Address Space Isolation

The past year has seen several hardware vulnerabilities that can impact public and private cloud computing environments.

In several cases, vulnerabilities can leak secrets (keys, and other sensitive data) due to resource sharing within a microprocessor. This includes the CPU memory “caches” used to speed up access to recently used data items. In some processors, the inner most data cache is shared by two sibling hardware threads that appear as if they were separate “logical processors” to the OS but are in fact cunningly splitting the resources of a single processor core. Indeed, in some cloud environments, when you spin up an instance with two “vcpus”, you’re actually getting one physical CPU core with two of these threads as “CPUS”.

It can be painful when the vulnerability mitigation suggests that such threads be disabled (halving advertised CPU resources, even if throughput isn’t impacted as much). Hence the need to find mechanisms to isolate secrets shared between unrelated hardware threads so vulnerabilities don’t lead to data leaks.

A patch posted by Alexandre Chartre based in part upon earlier work from Liran Alon and others aims to introduce Microsoft-like Hyper-v “Hyperclear”, creating a separate address space within the kernel for every KVM guest.

Although the guest itself traditionally runs in its own context, the new patches create an additional separate context within the host kernel such that if one thread exits from the guest, it does so in a minimal special environment that doesn’t contain secrets the other thread could try to extract. If things work out well, this should be one of the less painful mitigations in terms of performance impact. It’s early days, but it is promising.