The kernel's page cache works to improve performance by minimizing disk I/O and increasing the sharing of physical memory. But, like other performance-enhancing techniques that involve resources shared across security boundaries, the page cache can be abused as a way to extract information that should be kept secret. A recent paper [PDF] by Daniel Gruss and colleagues showed how the page cache can be targeted for a number of different attacks, leading to an abrupt change in how the mincore() system call works at the end of the 5.0 merge window. But subsequent discussion has made it clear that mincore() is just the tip of the iceberg; it is unclear what will really need to be done to protect a system against page-cache attacks or what the performance cost might be.

The page cache holds copies of portions of files (in 4KB pages on most systems) in main memory. When a process needs to access data from a file, the presence of that data in the page cache eliminates the need to read it from disk, speeding things considerably. Multiple processes accessing the same files (such as the C library, for example) will share the same copies in the page cache, reducing the amount of memory that is required by the current workload. On systems hosting containers, much of the runtime system can be shared in this manner.

All of this is good, but it has been known for some time that this kind of shared caching can disclose information between processes. If an attacker can determine which files are currently represented in the page cache, they can learn about what processes running in the system are doing. When the attacker can observe when specific pages are brought into the cache, they can make conclusions about when specific accesses are being made. For example, it is possible to figure out when a specific function has been called by noting when the page containing that function appears in the cache. Gruss and company have been able to demonstrate a number of exploits, including covert channels and keystroke timing, that can be accomplished with this information.

There are two components to a successful page-cache attack. One of them is being able to determine whether a given page is in the cache, preferably without perturbing the state of the cache in the process. The other half of the problem, though, is the ability to evict specific pages from the cache; that is required to be able to see when a target accesses those pages. In the paper, this is done simply by faulting in enough other pages to force the target pages out; as it turns out, though, there may be an easier way.

Hardware memory encryption is, or will soon be, available on multiple generic CPUs. In its absence, data is stored — and passes between the memory chips and the processor — in the clear. Attackers may be able to access it by using hardware probes or by directly accessing the chips, which is especially problematic with persistent memory. One new memory-encryption offering is Intel's Multi-Key Total Memory Encryption (MKTME) [PDF]; AMD's equivalent is called Secure Encrypted Virtualization (SEV). The implementation of support for this feature is in progress for the Linux kernel. Recently, Alison Schofield proposed a user-space API for MKTME, provoking a long discussion on how memory encryption should be exposed to the user, if at all.

Filesystem encryption options offer a wide choice of possibilities; their use is now standard practice in a number of settings, protecting user data when it is at rest. On the other hand, data stored in main memory is kept in the clear, as are exchanges between memory chips and the processors. In a virtualized environment, if attackers can find a way to read memory from neighbor virtual machines, they can access the data from those machines. Physical attacks are possible by removing memory chips or spying on the memory buses. This is becoming a more serious threat with persistent-memory technologies, where the data stays in the clear even after power is removed. Memory-encryption technologies are aiming to address some of those attacks.

Memory encryption has been available in Intel chips for some time in the form of Total Memory Encryption (TME). It uses a single, CPU-generated key for all of memory; users can control the usage of TME in the boot-level firmware. A new standard, which will be available in upcoming chips, is MKTME, an extension of TME that supports different encryption settings (including disabling encryption) at the page level, and more keys. Different keys can be used at the same time for different memory regions. The main use case for MKTME seems to be adding more protection in systems with multiple virtual machines (see these slides from LinuxCon China [PDF]). The encryption algorithm supported is AES-XTS 128 with the physical address being taken into account as a type of nonce.

Lower-level support for MKTME in the Linux kernel was submitted in September 2018. Memory encryption was also one of the subjects discussed at the 2018 Linux Storage, Filesystem, and Memory-Management Summit. The recent patch set from Schofield goes further, adding the user interface to set up the encryption and (optionally) keys, assign key identifiers to memory regions; the patch set also adds a key store to support CPU hotplug.

Arguably, the most notable characteristic of persistent memory is that it is persistent: it retains its contents over power cycles. One other important aspect of these persistent-memory arrays that, we are told, will soon be everywhere, is their sheer size and low cost; persistent memory is a relatively inexpensive way to attach large amounts of memory to a system. Large, cheap memory arrays seem likely to be attractive to users who may not care about persistence and who can live with slower access speeds. Supporting such users is the objective of a pair of patch sets that have been circulating in recent months.

Current kernels treat persistent memory as a device. The memory managed by that device can host a filesystem or be mapped directly into a process's address space (or both), but it will only be used by processes that ask for it explicitly. This patch set from Dave Hansen can change that behavior, though. It creates a new device driver that takes any persistent memory assigned to it and hotplugs it into the system as a range of ordinary RAM; after that, it will be given over to processes to satisfy normal memory-allocation requests. A portion (or all) of the system's persistent memory can be given over to this use, as the system administrator wishes.

Persistent memory used in this mode looks like ordinary memory, but the two are still not exactly the same. In particular, while persistent memory is fast, it is still not as fast as normal RAM. So users may well want to ensure that some applications use regular memory (DRAM) while others are relegated to persistent memory that is masquerading as the regular variety. When persistent memory is added to the system in this way, it shows up under one or more special NUMA nodes, so the usual memory-policy mechanisms can be used to control which processes use it. As Hansen suggested, a cloud provider could use this mechanism to offer two classes of virtual machines, with the cheaper ones confined mostly to the slower, persistent memory.

Read-copy update (RCU) is a synchronization mechanism that was added to the Linux kernel in October 2002. RCU is most frequently described as a replacement for reader-writer locking, but has also been used in a number of other ways. RCU is notable in that readers do not directly synchronize with updaters, which makes RCU read paths extremely fast; that also permits RCU readers to accomplish useful work even when running concurrently with updaters. Although the basic idea behind RCU has not changed in decades following its introduction into DYNIX/ptx, the API has evolved significantly over the five years since the 2014 edition of the RCU API, to say nothing of the nine years since the 2010 edition of the RCU API.

Arm Holdings has been developing their next-generation "Komeda" Direct Rendering Manager driver and they believe it's ready for mainline integration with the upcoming Linux 5.1 cycle.

The Komeda driver is their new software solution for the Mali D71 and newer display processors. The M71 brought with it a large redesign to Arm's display IP that is now more modularized and enough alterations that it was better for them to develop a new driver.