-- On Fri, Jun 14, 2024 at 3:12 PM <cuiyudong123@xxxxxxx> wrote: > > From: Yudong Cui <cuiyudong@xxxxxxxxxx> > > Translate the following documents into Chinese: > > - userspace-api/mseal.rst > > Signed-off-by: Yudong Cui <cuiyudong@xxxxxxxxxx> > > --- > V1 -> V2: Resolved compilation warnings and optimized the translation of documentation > V2 -> V3: Fix code formatting errors > --- > --- > .../zh_CN/userspace-api/index.rst | 1 + > .../zh_CN/userspace-api/mseal.rst | 186 ++++++++++++++++++ > 2 files changed, 187 insertions(+) > create mode 100644 Documentation/translations/zh_CN/userspace-api/mseal.rst > > diff --git a/Documentation/translations/zh_CN/userspace-api/index.rst b/Documentation/translations/zh_CN/userspace-api/index.rst > index 5b14721c8264..b7da307ec6bb 100644 > --- a/Documentation/translations/zh_CN/userspace-api/index.rst > +++ b/Documentation/translations/zh_CN/userspace-api/index.rst > @@ -27,6 +27,7 @@ Linux 内核用户空间API指南 > ebpf/index > sysfs-platform_profile > futex2 > + mseal > > TODOList: > > diff --git a/Documentation/translations/zh_CN/userspace-api/mseal.rst b/Documentation/translations/zh_CN/userspace-api/mseal.rst > new file mode 100644 > index 000000000000..598bb5f1562c > --- /dev/null > +++ b/Documentation/translations/zh_CN/userspace-api/mseal.rst > @@ -0,0 +1,185 @@ > +.. SPDX-License-Identifier: GPL-2.0 > +.. include:: ../disclaimer-zh_CN.rst > + > +:Original: Documentation/userspace-api/mseal.rst > + > +:翻译: > + > + 崔玉栋 cuiyudong <cuiyudong@xxxxxxxxxx> > + > +========== > +mseal 简介 > +========== > + > +:作者: Jeff Xu <jeffxu@xxxxxxxxxxxx> > + > +现代cpu支持诸如RW和NX位的内存权限。这个内存权限特性提高了内存损坏bug的安全性。 > +攻击者不能只是写入任意内存并将代码指向它，内存必须用X位标记，否则会发生异常。 How about the following translation？ 现代处理器支持诸如RW和NX位的内存权限。这个内存权限特性提高了内存破坏漏洞（memory corruption bug）的利用门槛。 为了防止攻击者无法写入任意内存并进行执行，内存必须标记了NX位，否则会发生异常。 这里我解释一下，NX 位是为了防止一种早期的攻击。早期内存默认带有RWX权限。攻击者可在某内存区域写入恶意代码， 并将程序执行流导向该内存区域从而发起攻击。而 NX 位的作用是限制内存只能带RW 或 X 权限， 从而防止该攻击。所以我觉得我们这部分要意译。 Refer to details in https://en.wikipedia.org/wiki/NX_bit. Moreover, I prefer to translate memory corruption bug to "内存破坏漏洞", i.e., a general vulnerability with high severity. > + > +内存封装还额外保护了映射本身不被修改。这对于缓解内存损坏问题很有用， ditto, "内存破坏漏洞" > +在这些问题中，一个损坏的指针被传递给内存管理系统。例如， > +这样的攻击者原语可以破坏控制流完整性保证，因为应该被信任的只读内存可能变得可写， > +或者 .text 页面可能会被重新映射。运行时加载程序可以自动应用内存密封来 > +密封.text和.rodata页面，并且应用程序可以在运行时额外密封安全关键数据。 > + > +类似的特性已经存在于XNU内核中 > +VM_FLAGS_PERMANENT 标志 [1] 和 OpenBSD 上的可变系统调用 [2]。 > + > +用户 API > +======== > +mseal() > +----------- > +The mseal() 系统调用具有以下签名: > + > +``int mseal(void addr, size_t len, unsigned long flags)`` > + > +**addr/len**: 虚拟内存地址范围。 > + > +由 ``addr``/``len`` 设置的地址范围必须满足: > + - 起始地址必须在已分配的VMA中。 > + - 起始地址必须与页面对齐。 > + - 结束地址 (``addr`` + ``len``) 必须在已分配的VMA中。 > + - 起始地址和结束地址之间没有间隙 (未分配的内存) 。 > + > +这个 ``len`` 将由内核隐式地进行分页对齐。 > + > +**flags**: 保留供将来使用。 > + > +**返回值**: > + > +- ``0``: 成功。 > + > +- ``-EINVAL``: > + - 无效的输入 ``flags``。 > + - 起始地址 (``addr``) 未对齐页。 > + - 地址范围 (``addr`` + ``len``) 溢出。 > + > +- ``-ENOMEM``: > + - 起始地址 (``addr``) 未分配。 > + - 结束地址 (``addr`` + ``len``) 未分配。 > + - 一个间隙 (unallocated memory) 起始地址和结束地址之间。 > + > +- ``-EPERM``: > + - 内存密封仅在64位CPU上支持，32位不受支持。 > + > +- 对于上述错误情况，用户可以期望给定的内存范围为未修改，即没有部分更新。 > + > +- 可能还有其他未在此处列出的内部错误/情况，例如， > + 在合并/拆分VMA（虚拟内存区域）时发生错误，或者 > + 进程达到了支持的最大VMA数量。在这些情况下， > + 给定内存范围可能会发生部分更新。然而，这些情况应该很罕见。 > + > +**内存密封后的阻塞操作**: > + 取消映射，移动到另一个位置，并缩小大小，通过munmap()和mremap()， > + 可以留下一个空白的空间，因此可以用具有一组新属性的VMA替换。 > + > + 通过mremap()，将不同的VMA移动或扩展到当前位置。 > + > + 通过mmap(MAP_FIXED)修改VMA。 > + > + 通过 mremap() 进行的大小扩展似乎不会对已密封的 VMA（虚拟内存区域） > + 造成任何特定的风险。尽管如此，由于使用场景不明确，这一点还是被包括了进来。 > + 无论如何，用户都可以依赖合并操作来扩展已密封的 VMA。 > + > + mprotect() 和 pkey_mprotect()。 > + > + 对于匿名内存一些破坏性的 madvice() 行为 (例如 MADV_DONTNEED) > + 当用户没有对这块写权限时。这些行为可以通过丢弃页面来改变区域内容， > + 实际上是匿名内存的 memset(0) 。 > + > + 对于阻塞的操作，内核将返回 -EPERM 。 > + > + 对于阻塞操作，可以期望给定的地址不会被修改， > + 即不会发生部分更新。请注意，这与现有的内存管理系统调用行为不同， > + 后者在发现错误并返回给用户空间之前会进行部分更新。举个例子来说： > + > + 假设代码序列如下: > + > + - ptr = mmap(null, 8192, PROT_NONE); > + - munmap(ptr + 4096, 4096); > + - ret1 = mprotect(ptr, 8192, PROT_READ); > + - mseal(ptr, 4096); > + - ret2 = mprotect(ptr, 8192, PROT_NONE); > + > + ret1 将变成 -ENOMEM, ptr指向的页更新为PROT_READ。 > + > + ret2 将变成 -EPERM, 这个页面仍然是 PROT_READ。 > + > +**注意**: > + > +- mseal() 仅适用于64位CPU，不支持32位CPU。 > + > +- 用户可以多次调用 mseal() , 对已经密封的内存执行 mseal() 是一个无操作（不报错）。 > + > +- 不支持munseal() 。 > + > +用例: > +===== > +- glibc: > + 在加载 ELF 可执行文件时，动态链接器可以对非可写内存段应用密封操作。 > + > +- Chrome 浏览器: 保护部分对安全敏感的数据结构。 > + > +关于哪些内存应该被密封的注意事项: > +================================= > + > +重要的是要注意，密封会改变映射的生命周期，即已密封的映射在进程终止 > +或执行 exec 系统调用之前不会被取消映射。应用程序可以从用户空间对任何虚拟 > +内存区域应用密封，但在应用密封之前，彻底分析映射的生命周期是至关重要的。 > + > +例如: > + > +- aio/shm > + > + aio/shm 可以代表用户空间调用 mmap()/munmap() , 例如 ksys_shmdt() 在shm.c中。 > + 这些映射的生命周期并不与进程的生命周期绑定。如果这些内存区域从用户空间被密封， > + 那么 munmap() 将失败，导致在进程的生命周期内 VMA（虚拟内存区域）地址空间中 > + 出现泄漏。 > +- Brk (heap) > + > + 目前，用户空间的应用程序可以通过调用 malloc() 和 mseal() 来密封堆（heap）的 > + 部分内存。让我们假设以下来自用户空间的调用: > + > + - ptr = malloc(size); > + - mprotect(ptr, size, RO); > + - mseal(ptr, size); > + - free(ptr); > + > + 技术上，在 mseal() 被添加之前，用户可以通过调用 mprotect(RO) > + 来改变堆的保护属性。只要用户在调用 free() 之前将保护属性改回 RW（读写）， > + 这块内存范围就可以被重用。 > + > + 然而，引入 mseal() 之后，堆的部分内存将被密封，用户仍然可以释放这部分内存， > + 但内存将保持为 RO（只读）。如果堆管理器重新使用这个地址来分配另一块内存， > + 进程可能在不久后崩溃。因此，不要对任何可能会被回收的内存应用密封， > + 这是非常重要的。 > + > + 此外，即使应用程序从未对指针 ptr 调用 free()，堆管理器也可能会 > + 调用 brk 系统调用来缩小堆的大小。在内核中，brk 缩小操作会调用 munmap()。 > + 因此，根据 ptr 的位置，brk 缩小操作的结果是不确定的。 > + > +其他说明: > +========= > +正如 Jann Horn 在 [3] 中指出的那样, > +仍然有几种方法可以写入 RO（只读）内存，这在某种程度上是设计上的考虑。 > +这些情况不会被 mseal() 涵盖。如果应用程序想要阻止这类情况， > +可以考虑使用沙箱工具（如 seccomp、LSM 等）。 > + > +这些情况是: > + > +- 通过/proc/self/mem接口写入只读内存。 > +- 通过ptrace(如PTRACE_POKETEXT)写入只读内存。 > +- userfaultfd。 > + > +这个补丁的灵感来自于 Stephen Röttger’s 在 V8 CFI（控制流完整性）中的工作 [4]。 > +ChromeOS中的Chrome浏览器将是此API的第一个用户。 > + > +参考: > +===== > +[1] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/osfmk/mach/vm_statistics.h#L274 > + > +[2] https://man.openbsd.org/mimmutable.2 > + > +[3] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ426FkcgnfUGLvA@xxxxxxxxxxxxxx > + > +[4] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQMyXgeaRHo/edit#heading=h.bvaojj9fu6hc > -- > 2.33.0 > >
