On Tue, Nov 26, 2024 at 8:40 AM Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> wrote: > > +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... > I apologize, this shouldn't happen again. Thanks for reminding me -Jeff > > 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 > >
