谷歌提议为Linux内核调用一个新的mseal（）内存密封系统。谷歌打算将这种独立于体系结构的系统调用最初由Chrome操作系统上的谷歌Chrome网络浏览器使用，而Glibc在启动时在动态链接器中使用以密封所有不可写段的实验正在进行中。
利用mseal（）将防止系统调用修改虚拟地址的元数据。最初支持的是对mprotect/pkey_mprotect、munmap、mmap和mremap调用进行密封。为了在Google Chrome和V8 JavaScript引擎中获得更好的保护，人们正在寻求使虚拟内存区域的元数据不可变。Glibc为在启动时将密封添加到动态链接器中以密封所有不可写的段所做的工作也将自动惠及所有应用程序。感兴趣的人可以在
此内核修补程序系列
。
但它不会立即被接受，在演变成合适的上游形式之前可能需要一些修改。。。Linus Torvalds自己已经
表达的
对拟议模式的一些保留意见：
所以我不反对添加某种“锁定内存映射”模型，但事实并非如此。
首先，简单的事情是：提交消息毫无价值。拥有
检查mmap的密封件（2）
由于提交消息根本不可接受，因此从该系列中随机选择一个示例（7/8）。
但这并不重要，因为我认为更根本的问题要严重得多：
-整个“ON_BEHALF_OF_KERNEL”和“ON_BEHALF_OF_USERSPACE”只是完全的噪声，完全不合逻辑。整个概念需要重新设计。
。。。
基督这就是remap_file_page（）系统调用定义。在这种情况下，“ON_BEHALF_OF_KERNEL”根本没有任何意义。
。。。
不管怎样，这一切都是对这个系列以这种形式发出的响亮的NAK。我的抱怨不是某种小的“解决这个问题”。这些都是根本问题。
So mseal() will need to go back to the drawing board before it will be considered by Linus Torvalds.
