FPT, the Southeast Asia’s leading IT company, has joined the Automotive Grade Linux project at the Linux Foundation, marking an important stage in FPT’s automotive technology development.

[...]

AGL is an open source project that is changing the way automotive manufacturers build software. Adopting an open platform across the industry enables automakers and suppliers to share and reuse the same code base, which reduces development costs, decreases time-to-market for new products and reduces fragmentation across the industry.

Intel's "Software Guard Extensions" (SGX) feature allows the creation of encrypted "enclaves" that cannot be accessed from the rest of the system. Normal code can call into an enclave, but only code running inside the enclave itself can access the data stored there. SGX is pitched as a way of protecting data from a hostile kernel; for example, an encryption key stored in an enclave should be secure even if the system as a whole is compromised. Support for SGX has been under development for over three years; LWN covered it in 2016. But, as can be seen from the response to the latest revision of the SGX patch set, all that work has still not answered an important question: what protects the kernel against a hostile enclave?
The proposed API for creating and controlling enclaves is complex, so one would expect it to come with comprehensive documentation. The actual API documentation turns out to be a little sparse, though. One starts by opening /dev/sgx/enclave; there are no privilege checks in the kernel, so the ability to open and act upon this file is determined solely by its permission bits. The SGX_IOC_ENCLAVE_CREATE ioctl() command will begin the process of setting up an enclave in the system. Each page of code or data must then be added with a separate SGC_IOC_ENCLAVE_ADD_PAGE call; the contents of those pages will be encrypted by the processor so that they will be unreadable outside of the enclave. When that process is complete, the enclave is completed with an SGX_IOC_ENCLAVE_INIT operation. At that point, the system loses its ability to manipulate the contents of the enclave; it can call into the enclave to ask for services, but cannot read or modify any of the data stored therein.

After 20 revisions of the patch set over three years, the authors of this work (which was posted by Jarkko Sakkinen) might well be forgiven for thinking that it must be about ready for merging. This posting evoked a new round of opposition, though, that seems clear to delay things for at least a couple more rounds.

The most vocal critic is Greg Wettstein, who has clearly been working with SGX and Intel's out-of-tree driver for some time. His complaints put off some developers with their tone and verbosity, and not all of them were seen as being entirely valid. He was, for example, unhappy that the user-space API has changed from previous versions of the patch set, breaking his current code. But, since this functionality has never been supported in a mainline kernel, there was little sympathy on offer. Some of his other observations, though, needed to be taken more seriously.

This description is true for the most part (at least on filesystems supporting this bit), but Wong noticed an important exception: a process that opens a file for writing prior to the setting of the immutable bit will still be able to write to the file after the bit is set for as long as it holds the file descriptor open. So while many operations on an immutable file are blocked, modifying the data in the file using open file descriptors is still allowed. The file is not yet, in other words, fully immutable.

That behavior is both inconsistent and surprising; Wong set out to change it by making the system actually behave the way the man page says it will. Doing that requires two types of changes, the first of which is easier than the second. Whenever a process attempts to write to a file descriptor, a call is made to generic_write_checks() to ensure that the operation can be allowed. Adding a check for immutability to that function will cause write() calls to fail immediately once a file has been marked immutable. A similar check needs to be added to do_mmap() to prevent the creation of a writable memory mapping from a file descriptor. Those changes close off the most obvious ways to change an immutable file.

The remaining problem is that writable memory mappings of the file may already exist, and those, too, can be used to modify a file that has since been marked immutable. User-space code need not make any system calls to write to a memory-mapped region, so there isn't a single, simple place to add a check like there is with write() and mmap(). The good news is that most of the needed machinery to prevent such writes is already in place, thanks to how filesystems manage writable mappings now.

The problem that a filesystem implementation has to solve is that it, too, will get no notification when a process writes to a region of memory that has a file mapped into it; user space simply dereferences a pointer and stores data there. But the filesystem needs to know when that happens so it can ensure that the newly written data eventually finds its way to persistent storage. The trick that is used here is to write-protect the pages in memory. When user space attempts to write to one of those pages, a page fault will result; the kernel can then make the page writable and notify the filesystem that the page has been written to. When the filesystem code eventually writes the modified page(s) back to disk, it can once again write-protect those pages to mark them as being clean and to catch any subsequent modifications.

As has been recently discussed here, developers for the filesystem and memory-management subsystems have been grappling for years with the problems posed by the get_user_pages() mechanism. This function maps memory into the kernel's address space for direct access by the kernel or peripheral devices, but that kind of access can create confusion in the filesystem layers, which may not be expecting that memory to be written to at any given time. A new patch set from Jérôme Glisse tries to chip away at a piece of the problem, but a complete solution is not yet in view.
The problem with get_user_pages() is relatively simple to understand: filesystems go to great lengths to track whether any given file page in memory is in a clean state — whether it matches the data in persistent storage — or not. When necessary, they use the memory-management subsystem to prevent changes to specific pages so that those pages can be written in a known state; once a page is clean it can be made writable again. Pointers to pages obtained by get_user_pages() bypass this mechanism, though; peripheral devices remain able to write data to those pages at any time. A poorly timed write can lead to data corruption or kernel crashes, neither of which is likely to be the behavior the user of the system is hoping for. Things get even more complicated if the pages in question are stored in persistent memory.

The above-linked article covered a nascent plan to track pages that have references created by get_user_pages(), perhaps by playing tricks with the page reference counts. Recent reference-counting changes might just have thrown a spanner into that works, though; the implementation of this plan has not yet been posted. Glisse's patch set is intended to work with it once it is around, though; in particular, it is designed to get the block layer to do its part to ensure that the tracking is correct. To do so, it creates a new mechanism to track the origin of pages that are given to the block layer with I/O requests.