The mseal patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Userspace API > System Calls: https://www.kernel.org/doc/html/next/userspace-api/index.htm...

kernel.org/doc/html/next/userspace-api/mseal.html: https://www.kernel.org/doc/html/next/userspace-api/mseal.htm... :

Modern CPUs support memory permissions such as RW and NX bits. The memory permission feature improves security stance on memory corruption bugs, i.e. the attacker can’t just write to arbitrary memory and point the code to it, the memory has to be marked with X bit, or else an exception will happen.

Memory sealing additionally protects the mapping itself against modifications. This is useful to mitigate memory corruption issues where a corrupted pointer is passed to a memory management system. For example, such an attacker primitive can break control-flow integrity guarantees since read-only memory that is supposed to be trusted can become writable or .text pages can get remapped. Memory sealing can automatically be applied by the runtime loader to seal .text and .rodata pages and applications can additionally seal security critical data at runtime.

A similar feature already exists in the XNU kernel with the VM_FLAGS_PERMANENT flag [1] and on OpenBSD with the mimmutable syscall [2].

NX bit, Memory tagging, Modified Harvard architecture: https://news.ycombinator.com/item?id=36726077#36740262

TEE, SGX, .data, .code: https://news.ycombinator.com/item?id=33584502

Thanks! Another important bit:

sealing changes the lifetime of a mapping, i.e. the sealed mapping won’t be unmapped till the process terminates or the exec system call is invoked. Applications can apply sealing to any virtual memory region from userspace, but it is crucial to thoroughly analyze the mapping’s lifetime prior to apply the sealing.