系统映射封存在启动选择 · v2

System mapping sealing is an mm feature, but its test has its own directory under tools/testing/selftests rather than living with the other mm tests. Let’s move it into tools/testing/selftests/mm and

Now that sysmap_is_sealed runs with the other mm tests, it also runs on kernels built without CONFIG_MSEAL_SYSTEM_MAPPINGS, where it fails. Userspace can’t tell whether the option is enabled, but a se

sysmap_is_sealed checks that system mappings are marked as sealed in smaps, but not that the seal is actually enforced. The rest of this series changes how system mappings get sealed, so let’s make su

MSEAL_SYSTEM_MAPPINGS is in security/Kconfig, but it’s an mm feature, it’s implemented in mm, and changes to it need to go past mm. Let’s move it to mm/Kconfig, next to the other VMA features. No fun

If swbp_optimize() fails, __arch_uprobe_optimize() unmaps the trampoline it has just created. The next patch seals all special mappings when CONFIG_MSEAL_SYSTEM_MAPPINGS is enabled, which includes upr

VM_SEALED_SYSMAP isn’t really a VMA flag, it’s an alias for VM_SEALED or VM_NONE depending on CONFIG_MSEAL_SYSTEM_MAPPINGS. Every caller of _install_special_mapping() on an architecture which supports

CONFIG_MSEAL_SYSTEM_MAPPINGS seals each process’ system mappings, such as the vDSO, when they are created. These are read-only or execute-only mappings which every process trusts, so sealing them mean

Booting with no_mseal_sys_mappings currently makes check_sealed skip and expect_sealed fail, so nothing checks that the parameter actually turns sealing off. So let’s check /proc/cmdline for it, and