Google engineers recently submitted a new patch to the Linux kernel , hoping to add a system call "mseal() syscall " named mseal().
According to reports, Google's architecture-independent system call was originally used by the Chrome browser on Chrome OS. At that time Glibc was also conducting similar experiments in the dynamic linker to encapsulate all non-writable segments at startup.
mseal() prevents system calls from modifying the metadata of virtual addresses . Initial support is for encapsulation of mprotect/pkey_mprotect, munmap, mmap and mremap calls. To provide better protection in the Chrome and V8 JavaScript engines, developers are looking to make the metadata of virtual memory regions immutable.
Glibc's solution is to add encapsulation in the dynamic linker so that all non-writable segments are encapsulated at startup, which will automatically benefit all applications as well.
Linus Torvalds expressed reservations about the model proposed by mseal() syscall. At present, this proposal has not been directly accepted and needs to be revised to evolve into a form suitable for upstream.
Linus said:
"I have no problem with adding some kind of 'lock down memory mappings' model, but that's not the case.
First, the most obvious problem is that the submitted information is of no value.
In addition, the more fundamental problem is much more serious - "ON_BEHALF_OF_KERNEL" and "ON_BEHALF_OF_USERSPACE" are completely illogical as a whole, and the entire concept needs to be rewritten. Because this is the "literal" system call definition of remap_file_pages(). "