Kernel Watch
Jon Masters summarises the latest happenings in the Linux kernel community, for your reading pleasure.
“SGX has been around since the introduction of Intel’s Skylake family…”
Linus Torvalds announced the fourth release candidate (RC) of what will become Linux version 4.20. This followed the customary two-week merge window prior to RC1, during which disruptive changes (such as new features) were pulled.
These included support for a new CPU architecture (C-SKY), a new ability for the kernel to track the source of memory pressure, and the merging (at last) of XArray, an optimised and more scalable data structure for use within the kernel in place of a radix tree. In addition, a number of cleanups were merged for previously disclosed CPU security issues.
According to Linus, he “did debate calling it [4.20] 5.0, but if we all help each other, I’m sure we can count to 20. It’s a nice round number, and I didn’t want to make a pattern of it. I think 5.0 happens next year, because then I really run out of fingers and toes”. He also pointed out that he’s considering making a firmer rule out of requiring maintainers to get their patches in early in the merge window. While “people generally kind of know about this” he “was starting to feel a bit tight there”. Otherwise, Linus is more or less happy, with the exception of the state of support for a security mitigation known as STIBP (see boxout, right).
A number of potential features almost went into 4.20, but didn’t quite pass muster with the community or were deemed to need further work. This includes the new I3C (the successor to I2C) subsystem as used on a number of future embedded devices, and a rewrite of the filesystem mounting code.
In his reply rejecting I3C, Linus noted that he wants “new stuff to be ready before the merge window, and I want to see the actual pull requests early. The two weeks [of the merge window] is not for development and to let people delay things a bit. It’s to make it possible to synchronise and work out issues”.
Meanwhile, development work continues on future features, as does dialogue around community management and involvement. One of the ways in which the collective kernel community is represented is through the Linux Technical Advisory Board (TAB), which is part of Linux Foundation. This month, saw the latest election of new representatives, who each serve a two-year term (the other half of the TAB remains until next year, and so on). Newly elected members included Kees Cook, who has been instrumental in improving Linux security.
Secure enclaves
Recent Intel microprocessors include support for a set of x86 instructions known as software guard extensions. These provide a mechanism for user application code to allocate regions of memory, known as enclaves, that are encrypted and can’t be read by even the Operating System kernel. SGX enables a number of use cases, such as DRM (digital rights management) as used in streaming video or other electronic media. In this example case, an encryption algorithm and its associated keys can be shipped as part of a regular application. The DRM operations running within the SGX “enclave” wouldn’t be visible to even the Linux kernel, thus rendering it harder to compromise DRM protections on digital content used by the application.
SGX has been around since the introduction of Intel’s Skylake family, but it’s not yet supported by upstream Linux kernels, which require additional patches in order to be able to load and manage enclaves. –65As a stop-gap alternative, Intel provided open source thirdparty driver code on github beginning in 2016. In recent kernel development cycles, an effort has been made to upstream support for SGX1 through a set of RFC (Request For Comment) development patches. But there’s one problem that the developers are “grappling with”, according to Andy Lutomirski.
The code within an enclave is protected from other application and kernel code by means of a special entry and exit process. An application causes an enclave to begin running by making a call to the EENTER (Enclave Enter) instruction. This can, “as part of its normal-ish operation, raise an exception”. An exception is a mechanism through which hardware signals to the Operating System that it needs assistance. Some
exceptions are purely intended for the OS, but others are exposed to application code. The kernel does this using a concept known as a signal. An example of a signal would be SEGV (segmentation violation) that you may have seen when an application accesses an illegal memory location and crashes.
Signals are processed by application signal handlers, which must be registered in advance or the default handler is called. That handler typically kills the application (which is usually undesirable). SGX impacts traditional signal handling because support for entering its enclaves is likely to be implemented using library code. “And signal handling in libraries is unpleasant at best”. As a consequence, Andy proposed a means to “register a [per thread] handler that gets a chance to act on an exception caused by a user instruction before a signal is delivered”.
This led to a spirited conversation in which various opinions about SGX and its current hardware/software interface were expressed, ultimately culminating in the suggestion that enclaves be treated more like separate thread contexts and managed as such. It’s clear, however, that there’s not yet a consensus on how to implement SGX in upstream kernels.