Google Proposes New mseal() Memory Sealing Syscall For Linux
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.
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 mseal() will need to go back to the drawing board before it will be considered by Linus Torvalds.
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.
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.
17 Comments