Google Proposes New mseal() Memory Sealing Syscall For Linux

Written by Michael Larabel in Linux Kernel on 17 October 2023 at 06:32 AM EDT. 17 Comments
LINUX KERNEL
Google is proposing a new mseal() memory sealing system call for the Linux kernel. Google intends for this architecture independent system call to be initially used by the Google Chrome web browser on Chrome OS while experiments are underway for use by Glibc in the dynamic linker to seal all non-writable segments at startup.

Leveraging mseal() will prevent system calls from modifying the metadata of virtual addresses. Initially supported is sealing against mprotect/pkey_mprotect, munmap, mmap, and mremap calls. Making the virtual memory area's metadata immutable is being sought for better protections within Google Chrome and the V8 JavaScript engine. The work being done by Glibc to add sealing into the dynamic linker for sealing all non-writable segments at start-up time would also benefit all applications automatically. Those interested can see more background information within this kernel patch series.

DDR5 memory


But it's not going to be accepted straight-away and will likely take some revisions before evolving into a suitable form for upstreaming... Linus Torvalds himself has already expressed some reservations around the proposed model:
So I have no objections to adding some kind of "lock down memory mappings" model, but this isn't it.

First off, the simple stuff: the commit messages are worthless. Having

check seal for mmap(2)

as the commit message is not even remotely acceptable, to pick one random example from the series (7/8).

But that doesn't matter much, since I think the more fundamental problems are much worse:

- the whole "ON_BEHALF_OF_KERNEL" and "ON_BEHALF_OF_USERSPACE" is just complete noise and totally illogical. The whole concept needs to be redone.
...
Christ. That's *literally* the remap_file_pages() system call definition. No way in hell does "ON_BEHALF_OF_KERNEL" make any sense in this context.
...
Anyway, this is all a resounding NAK on this series in this form. My complaints are not some kind of small "fix this up". These are fundamental issues.

So mseal() will need to go back to the drawing board before it will be considered by Linus Torvalds.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via MichaelLarabel.com.

Popular News This Week