+Vlastimil Jeff... :) Please review https://www.kernel.org/doc/html/latest/process/submitting-patches.html You didn't cc- mantainers of code you are changing. And you reference my name without cc'ing me here. I'm sure there's some relevant Taylor Swift lyric... On Mon, Nov 25, 2024 at 08:20:20PM +0000, jeffxu@xxxxxxxxxxxx wrote: > From: Jeff Xu <jeffxu@xxxxxxxxxxxx> > > Seal vdso, vvar, sigpage, uprobes and vsyscall. > > Those mappings are readonly or executable only, sealing can protect > them from ever changing or unmapped during the life time of the process. > For complete descriptions of memory sealing, please see mseal.rst [1]. > > System mappings such as vdso, vvar, and sigpage (for arm) are > generated by the kernel during program initialization, and are > 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 [2]. It is sealed from creation. > > The vdso, vvar, sigpage, and uprobe mappings all invoke the > _install_special_mapping() function. As no other mappings utilize this > function, it is logical to incorporate sealing logic within > _install_special_mapping(). This approach avoids the necessity of > modifying code across various architecture-specific implementations. > > The vsyscall mapping, which has its own initialization function, is > sealed in the XONLY case, it seems to be the most common and secure > case of using vsyscall. > > It is important to note that the CHECKPOINT_RESTORE feature (CRIU) may > alter the mapping of vdso, vvar, and sigpage during restore > operations. Consequently, this feature cannot be universally enabled > across all systems. > > Currently, memory sealing is only functional in a 64-bit kernel > configuration. > > To enable this feature, the architecture needs to be tested to > confirm that it doesn't unmap/remap system mappings during the > the life time of the process. After the architecture enables > ARCH_HAS_SEAL_SYSTEM_MAPPINGS, a distribution can set > CONFIG_SEAL_SYSTEM_MAPPING to manage access to the feature. > Alternatively, kernel command line (exec.seal_system_mappings) > enables this feature also. > > This feature is tested using ChromeOS and Android on X86_64 and ARM64, > therefore ARCH_HAS_SEAL_SYSTEM_MAPPINGS is set for X86_64 and ARM64. > Other architectures can enable this after testing. No specific hardware > features from the CPU are needed. > > This feature's security enhancements will benefit ChromeOS, Android, > and other secure-by-default systems. > > [1] Documentation/userspace-api/mseal.rst > [2] https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM4XkRkL-NrCZxYAyg@xxxxxxxxxxxxxx/ > > History: > V4: > 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. refactor (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 (1): > exec: seal system mappings > > .../admin-guide/kernel-parameters.txt | 11 ++++++ > Documentation/userspace-api/mseal.rst | 4 ++ > arch/arm64/Kconfig | 1 + > arch/x86/Kconfig | 1 + > arch/x86/entry/vsyscall/vsyscall_64.c | 8 +++- > include/linux/mm.h | 12 ++++++ > init/Kconfig | 25 ++++++++++++ > mm/mmap.c | 10 +++++ > mm/mseal.c | 39 +++++++++++++++++++ > security/Kconfig | 24 ++++++++++++ > 10 files changed, 133 insertions(+), 2 deletions(-) > > -- > 2.47.0.338.g60cca15819-goog >
