Great nice descriptions thanks! On Mon, Mar 03, 2025 at 05:09:14AM +0000, jeffxu@xxxxxxxxxxxx wrote: > From: Jeff Xu <jeffxu@xxxxxxxxxx> > > This is V8 version, addressing comments from V7, without code logic > change. > > ------------------------------------------------------------------- > As discussed during mseal() upstream process [1], mseal() protects > the VMAs of a given virtual memory range against modifications, such > as the read/write (RW) and no-execute (NX) bits. For complete > descriptions of memory sealing, please see mseal.rst [2]. > > The mseal() 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. > > The system mappings are readonly only, memory sealing can protect > them from ever changing to writable or unmmap/remapped as different > attributes. > > System mappings such as vdso, vvar, vvar_vclock, > vectors (arm compact-mode), sigpage (arm compact-mode), > are created by the kernel during program initialization, and could > be sealed after creation. > > Unlike the aforementioned mappings, the uprobe mapping is not > established during program startup. However, its lifetime is the same > as the process's lifetime [3]. It could be sealed from creation. > > The vsyscall on x86-64 uses a special address (0xffffffffff600000), > which is outside the mm managed range. This means mprotect, munmap, and > mremap won't work on the vsyscall. Since sealing doesn't enhance > the vsyscall's security, it is skipped in this patch. If we ever seal > the vsyscall, it is probably only for decorative purpose, i.e. showing > the 'sl' flag in the /proc/pid/smaps. For this patch, it is ignored. > > It is important to note that the CHECKPOINT_RESTORE feature (CRIU) may > alter the system mappings during restore operations. UML(User Mode Linux) > and gVisor, rr are also known to change the vdso/vvar mappings. > Consequently, this feature cannot be universally enabled across all > systems. As such, CONFIG_MSEAL_SYSTEM_MAPPINGS is disabled by default. > > To support mseal of system mappings, architectures must define > CONFIG_ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS and update their special > mappings calls to pass mseal flag. Additionally, architectures must > confirm they do not unmap/remap system mappings during the process > lifetime. The existence of this flag for an architecture implies that > it does not require the remapping of thest system mappings during > process lifetime, so sealing these mappings is safe from a kernel > perspective. > > This version covers x86-64 and arm64 archiecture as minimum viable feature. > > While no specific CPU hardware features are required for enable this > feature on an archiecture, memory sealing requires a 64-bit kernel. Other > architectures can choose whether or not to adopt this feature. Currently, > I'm not aware of any instances in the kernel code that actively > munmap/mremap a system mapping without a request from userspace. The PPC > does call munmap when _install_special_mapping fails for vdso; however, > it's uncertain if this will ever fail for PPC - this needs to be > investigated by PPC in the future [4]. The UML kernel can add this support > when KUnit tests require it [5]. > > In this version, we've improved the handling of system mapping sealing from > previous versions, instead of modifying the _install_special_mapping > function itself, which would affect all architectures, we now call > _install_special_mapping with a sealing flag only within the specific > architecture that requires it. This targeted approach offers two key > advantages: 1) It limits the code change's impact to the necessary > architectures, and 2) It aligns with the software architecture by keeping > the core memory management within the mm layer, while delegating the > decision of sealing system mappings to the individual architecture, which > is particularly relevant since 32-bit architectures never require sealing. > > Prior to this patch series, we explored sealing special mappings from > userspace using glibc's dynamic linker. This approach revealed several > issues: > - The PT_LOAD header may report an incorrect length for vdso, (smaller > than its actual size). The dynamic linker, which relies on PT_LOAD > information to determine mapping size, would then split and partially > seal the vdso mapping. Since each architecture has its own vdso/vvar > code, fixing this in the kernel would require going through each > archiecture. Our initial goal was to enable sealing readonly mappings, > e.g. .text, across all architectures, sealing vdso from kernel since > creation appears to be simpler than sealing vdso at glibc. > - The [vvar] mapping header only contains address information, not length > information. Similar issues might exist for other special mappings. > - Mappings like uprobe are not covered by the dynamic linker, > and there is no effective solution for them. > > This feature's security enhancements will benefit ChromeOS, Android, > and other high security systems. > > Testing: > This feature was tested on ChromeOS and Android for both x86-64 and ARM64. > - Enable sealing and verify vdso/vvar, sigpage, vector are sealed properly, > i.e. "sl" shown in the smaps for those mappings, and mremap is blocked. > - Passing various automation tests (e.g. pre-checkin) on ChromeOS and > Android to ensure the sealing doesn't affect the functionality of > Chromebook and Android phone. > > I also tested the feature on Ubuntu on x86-64: > - With config disabled, vdso/vvar is not sealed, > - with config enabled, vdso/vvar is sealed, and booting up Ubuntu is OK, > normal operations such as browsing the web, open/edit doc are OK. > > Link: https://lore.kernel.org/all/20240415163527.626541-1-jeffxu@xxxxxxxxxxxx/ [1] > Link: Documentation/userspace-api/mseal.rst [2] > Link: https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM4XkRkL-NrCZxYAyg@xxxxxxxxxxxxxx/ [3] > Link: https://lore.kernel.org/all/CABi2SkV6JJwJeviDLsq9N4ONvQ=EFANsiWkgiEOjyT9TQSt+HA@xxxxxxxxxxxxxx/ [4] > Link: https://lore.kernel.org/all/202502251035.239B85A93@keescook/ [5] > > ------------------------------------------- > History: > > V8: > - Change ARCH_SUPPORTS_MSEAL_X to ARCH_SUPPORTS_MSEAL_X (Liam R. Howlett) > - Update comments in Kconfig and mseal.rst (Lorenzo Stoakes, Liam R. Howlett) > - Change patch header perfix to "mseal sysmap" (Lorenzo Stoakes) > - Remove "vm_flags =" (Kees Cook, Liam R. Howlett, Oleg Nesterov) > - Drop uml architecture (Lorenzo Stoakes, Kees Cook) > - Add a selftest to verify system mappings are sealed (Lorenzo Stoakes) > > V7: > https://lore.kernel.org/all/20250224225246.3712295-1-jeffxu@xxxxxxxxxx/ > - Remove cover letter from the first patch (Liam R. Howlett) > - Change macro name to VM_SEALED_SYSMAP (Liam R. Howlett) > - logging and fclose() in selftest (Liam R. Howlett) > > V6: > https://lore.kernel.org/all/20250224174513.3600914-1-jeffxu@xxxxxxxxxx/ > - mseal.rst: fix a typo (Randy Dunlap) > - security/Kconfig: add rr into note (Liam R. Howlett) > - remove mseal_system_mappings() and use macro instead (Liam R. Howlett) > - mseal.rst: add incompatible userland software (Lorenzo Stoakes) > - remove RFC from title (Kees Cook) > > V5 > https://lore.kernel.org/all/20250212032155.1276806-1-jeffxu@xxxxxxxxxx/ > - Remove kernel cmd line (Lorenzo Stoakes) > - Add test info (Lorenzo Stoakes) > - Add threat model info (Lorenzo Stoakes) > - Fix x86 selftest: test_mremap_vdso > - Restrict code change to ARM64/x86-64/UM arch only. > - Add userprocess.h to include seal_system_mapping(). > - Remove sealing vsyscall. > - Split the patch. > > V4: > https://lore.kernel.org/all/20241125202021.3684919-1-jeffxu@xxxxxxxxxx/ > - ARCH_HAS_SEAL_SYSTEM_MAPPINGS (Lorenzo Stoakes) > - test info (Lorenzo Stoakes) > - Update mseal.rst (Liam R. Howlett) > - Update test_mremap_vdso.c (Liam R. Howlett) > - Misc. style, comments, doc update (Liam R. Howlett) > > V3: > https://lore.kernel.org/all/20241113191602.3541870-1-jeffxu@xxxxxxxxxx/ > - Revert uprobe to v1 logic (Oleg Nesterov) > - use CONFIG_SEAL_SYSTEM_MAPPINGS instead of _ALWAYS/_NEVER (Kees Cook) > - Move kernel cmd line from fs/exec.c to mm/mseal.c and > misc. (Liam R. Howlett) > > V2: > https://lore.kernel.org/all/20241014215022.68530-1-jeffxu@xxxxxxxxxx/ > - Seal uprobe always (Oleg Nesterov) > - Update comments and description (Randy Dunlap, Liam R.Howlett, Oleg Nesterov) > - Rebase to linux_main > > V1: > - https://lore.kernel.org/all/20241004163155.3493183-1-jeffxu@xxxxxxxxxx/ > > -------------------------------------------------- > > > Jeff Xu (7): > mseal sysmap: kernel config and header change > selftests: x86: test_mremap_vdso: skip if vdso is msealed > mseal sysmap: enable x86-64 > mseal sysmap: enable arm64 > mseal sysmap: uprobe mapping > mseal sysmap: update mseal.rst > selftest: test system mappings are sealed. > > Documentation/userspace-api/mseal.rst | 20 ++++ > arch/arm64/Kconfig | 1 + > arch/arm64/kernel/vdso.c | 12 +- > arch/x86/Kconfig | 1 + > arch/x86/entry/vdso/vma.c | 7 +- > include/linux/mm.h | 10 ++ > init/Kconfig | 22 ++++ > kernel/events/uprobes.c | 3 +- > security/Kconfig | 21 ++++ > .../mseal_system_mappings/.gitignore | 2 + > .../selftests/mseal_system_mappings/Makefile | 6 + > .../selftests/mseal_system_mappings/config | 1 + > .../mseal_system_mappings/sysmap_is_sealed.c | 113 ++++++++++++++++++ > .../testing/selftests/x86/test_mremap_vdso.c | 43 +++++++ > 14 files changed, 254 insertions(+), 8 deletions(-) > create mode 100644 tools/testing/selftests/mseal_system_mappings/.gitignore > create mode 100644 tools/testing/selftests/mseal_system_mappings/Makefile > create mode 100644 tools/testing/selftests/mseal_system_mappings/config > create mode 100644 tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c > > -- > 2.48.1.711.g2feabab25a-goog >
