Kernel development will become more formal. One of the things that has traditionally attracted a certain type of developer to kernel work is the fact that many of the normal rules don't apply. Kernel development often requires working with high levels of complexity, combined with the ups and downs of dealing with real-world hardware; in that setting, pulling together any sort of solution can be an accomplishment. The result is a sort of cowboy culture that emphasizes working solutions over formal designs.

The increasing level of complexity in the kernel and in the hardware it drives has made that approach less tenable over the years. The kernel community has responded in a number of ways, including better documentation and better testing. One real harbinger of the future, though, may be the work that has been quietly happening to develop a formal memory-ordering model that makes it possible to reason about concurrency and ensure that kernel code is correct. If the kernel is going to continue to scale, this kind of approach will have to spread to other areas. There will be grumbling, since adding formality may slow the pace of development. But, with luck, it should also slow the issuance of urgent bug fixes and security updates.

More kernel APIs will be created for BPF programs rather than exported as traditional system calls; we are heading toward a world where a significant amount of kernel functionality is only available via BPF. The result will be a significant increase in flexibility and efficiency, but some growing pains should also be expected. The BPF API sees even less review than other kernel interfaces, and the community's record with the latter is decidedly less than perfect. This may be the year when we realize that we haven't yet figured out how to provide such low-level access to the kernel in ways that can be supported indefinitely.

Somebody will attempt to test the kernel community's code of conduct and its enforcement processes in the coming year. The community will handle that test without trouble, though, just as it has been handling the constant stream of trolling emails attempting to stir up strife. At the end of the year, the code of conduct will look pretty much the way it does now: a set of expectations that helps to improve behavior in the community, but not a big deal in general.

This year's holiday gifts will include the 4.20 kernel; that can only mean that it is time for another look at where the code going into this release has come from. This development cycle was typically busy and brought a lot of new code into the kernel. There are some new faces showing up in the statistics this time around, but not a lot of surprises otherwise.
As of this writing, 13,856 non-merge changesets have found their way into the mainline repository for the 4.20 release; they were contributed by 1,743 developers. That makes 4.20 the busiest cycle since 4.15, but only by a little bit; both numbers are essentially in line with recent release history. Of those 1,743 developers, 283 were first-time contributors this time around.

When the 4.20 kernel was released on December 23, Linus Torvalds indicated that he would try to keep to the normal merge window schedule despite the presence of the holidays in the middle of it. Thus far, he seems to be trying to live up to that; just over 8,700 changesets have been merged for the next release, which seems likely to be called 5.0. A number of long-awaited features are finally landing in the kernel with this release.

The kernel's live-patching (KLP) mechanism can apply a wide variety of fixes to a running kernel but, at a first glance, the sort of highly intrusive changes needed to address vulnerabilities like Meltdown or L1TF would not seem like likely candidates for live patches. The most notable obstacles are the required modifications of global semantics on a running system, as well as the need for live patching the kernel's entry code. However, we at the SUSE live patching team started working on proof-of-concept live patches for these vulnerabilities as a fun project and have been able to overcome these hurdles. The techniques we developed are generic and might become handy again when fixing future vulnerabilities.
For completeness, it should be noted that these two demo live patches have been implemented for kGraft, but kGraft is conceptually equivalent to KLP.

At the heart of the Meltdown vulnerability is the CPU speculating past the access rights encoded in the page table entries (PTEs) and thereby enabling malicious user-space programs to extract data from any kernel mapping. The kernel page-table isolation (KPTI) mechanism blocks such attacks by switching to stripped-down "shadow" page tables whenever the kernel returns to user space. These mirror the mappings from the lower, user-space half of the address space, but lack almost anything from the kernel region except for the bare minimum needed to reenter the kernel and switch back to the fully populated page tables. The difficulty, from a live-patching perspective, is to keep the retroactively introduced shadow page tables consistent with their fully populated counterparts at all times. Furthermore, the entry code has to be made to switch back and forth between the full and shadow page table at kernel entries and exits, but that is outside of the scope of what is live patchable with KLP.

For the L1TF vulnerability, recall that each PTE has a _PAGE_PRESENT bit that, when clear, causes page faults upon accesses to the corresponding virtual memory region. The PTE bits designated for storing a page's frame number are architecturally ignored in this case. The Linux kernel swapping implementation exploits this by marking the PTEs corresponding to swapped-out pages as non-present and reusing the physical address part to store the page's swap slot number. Unfortunately, CPUs vulnerable to L1TF do not always ignore the contents of these "swap PTEs", but can instead speculatively misinterpret the swap slot identifiers as physical addresses. These swap slot identifiers, being index-like in nature, tend to alias with valid physical page-frame numbers, so this speculation allows for extraction of the corresponding memory contents. The Linux kernel mitigation is to avoid this aliasing by bit-wise inverting certain parts of the swap PTEs. Unfortunately, this change of representation is again something which is not safely applicable to a running system with KLP's consistency guarantees alone.

Most processors spend a great deal of their time doing nothing, waiting for devices and timer interrupts. In these cases, they can switch to idle modes that shut down parts of their internal circuitry, especially stopping certain clocks. This lowers power consumption significantly and avoids draining device batteries. There are usually a number of idle modes available; the deeper the mode is, the less power the processor needs. The tradeoff is that the cost of switching to and from deeper modes is higher; it takes more time and the content of some caches is also lost. In the Linux kernel, the cpuidle subsystem has the task of predicting which choice will be the most appropriate. Recently, Rafael Wysocki proposed a new governor for systems with tickless operation enabled that is expected to be more accurate than the existing menu governor.