From: Chris Down <chris@chrisdown.name>
To: Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <liam@infradead.org>,
Lorenzo Stoakes <ljs@kernel.org>
Cc: Jeff Xu <jeffxu@google.com>, David Hildenbrand <david@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>, Jann Horn <jannh@google.com>,
Pedro Falcato <pfalcato@suse.de>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Kees Cook <kees@kernel.org>,
Andrey Vagin <avagin@gmail.com>,
Alexander Mikhalitsyn <alexander@mihalicyn.com>,
Shuah Khan <shuah@kernel.org>, Oleg Nesterov <oleg@redhat.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Jiri Olsa <jolsa@kernel.org>, Thomas Gleixner <tglx@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Huacai Chen <chenhuacai@kernel.org>,
WANG Xuerui <kernel@xen0n.name>, Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Jonathan Corbet <corbet@lwn.net>,
Randy Dunlap <rdunlap@infradead.org>,
linux-mm@kvack.org, linux-hardening@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-trace-kernel@vger.kernel.org, x86@kernel.org,
linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-team@meta.com
Subject: [PATCH v2 0/8] mseal sysmap: Choose system mapping sealing at boot
Date: Tue, 3 Nov 2026 23:17:43 +0800 [thread overview]
Message-ID: <cover.1793718940.git.chris@chrisdown.name> (raw)
System mapping sealing is currently a build time choice. Hosts which
want it and hosts which need to move or unmap these mappings therefore
need separate kernels, which is not ideal. Let's allow the administrator
to choose at boot time.
v2:
- Skip destructive vDSO tests on unsealed 32-bit x86 mappings
- Move the sysmap tests into selftests/mm (Lorenzo)
- Use shared vm_util helpers in the sysmap tests (Lorenzo)
- Use PROCMAP_QUERY for the vDSO lookup (Lorenzo)
- Keep test changes in separate patches (Lorenzo)
- Put the enforcement tests before the kernel changes (Lorenzo)
- Move MSEAL_SYSTEM_MAPPINGS to mm/Kconfig (Lorenzo)
- Remove VM_SEALED_SYSMAP (Lorenzo)
- Seal mappings in __install_special_mapping() (Lorenzo)
- Leave a sealed uprobe trampoline mapped if optimisation fails
- Replace the boolean parameter with no_mseal_sys_mappings (Lorenzo)
- Drop MSEAL_SYSTEM_MAPPINGS_DEFAULT_ON (Lorenzo)
- Drop the CHECKPOINT_RESTORE dependency (Lorenzo)
- Document the software which sealing breaks (Lorenzo)
- Keep Kconfig default-n regardless of CHECKPOINT_RESTORE (Andrei)
- Retain sealing by default when built in, with no_mseal_sys_mappings as
the boot-time opt-out (Lorenzo)
- Explain the security rationale (Lorenzo)
- Describe the Meta/Reverie use case (Lorenzo)
- Skip general checks on unsealed kernels (Lorenzo)
- Add expect_sealed for strict CI checks (Jeff)
- Use the existing -T filter to exclude strict checks when needed (Jeff)
- Test that no_mseal_sys_mappings leaves mappings unsealed (Jeff)
- Add the vDSO mprotect() enforcement test (Jeff)
v1: https://lore.kernel.org/r/cover.1793094611.git.chris@chrisdown.name
Chris Down (8):
selftests/mm: Move sysmap_is_sealed into mm
selftests/mm: Skip sysmap_is_sealed when system mappings aren't sealed
selftests/mm: Test that the seal on system mappings is enforced
mm/mseal: Move MSEAL_SYSTEM_MAPPINGS to mm/Kconfig
uprobes/x86: Leave sealed trampolines in place on optimisation failure
mm/mseal: Seal system mappings in __install_special_mapping()
mm/mseal: Add no_mseal_sys_mappings boot parameter
selftests/mm: Check that no_mseal_sys_mappings unseals system mappings
.../admin-guide/kernel-parameters.txt | 7 +
Documentation/userspace-api/mseal.rst | 12 +-
arch/arm64/kernel/vdso.c | 9 +-
arch/loongarch/kernel/vdso.c | 3 +-
arch/riscv/kernel/vdso.c | 2 +-
arch/s390/kernel/vdso.c | 2 +-
arch/x86/entry/vdso/vma.c | 5 +-
arch/x86/kernel/uprobes.c | 2 +-
include/linux/mm.h | 6 -
init/Kconfig | 5 +-
kernel/events/uprobes.c | 2 +-
lib/vdso/datastore.c | 2 +-
mm/Kconfig | 23 ++
mm/mseal.c | 12 +
mm/vma.c | 2 +
mm/vma.h | 8 +
security/Kconfig | 21 --
tools/testing/selftests/Makefile | 1 -
tools/testing/selftests/mm/Makefile | 1 +
tools/testing/selftests/mm/config | 1 +
tools/testing/selftests/mm/run_vmtests.sh | 6 +
tools/testing/selftests/mm/sysmap_is_sealed.c | 259 ++++++++++++++++++
tools/testing/selftests/mm/vm_util.c | 5 +
tools/testing/selftests/mm/vm_util.h | 1 +
.../mseal_system_mappings/.gitignore | 2 -
.../selftests/mseal_system_mappings/Makefile | 6 -
.../selftests/mseal_system_mappings/config | 1 -
.../mseal_system_mappings/sysmap_is_sealed.c | 119 --------
28 files changed, 345 insertions(+), 180 deletions(-)
create mode 100644 tools/testing/selftests/mm/sysmap_is_sealed.c
delete mode 100644 tools/testing/selftests/mseal_system_mappings/.gitignore
delete mode 100644 tools/testing/selftests/mseal_system_mappings/Makefile
delete mode 100644 tools/testing/selftests/mseal_system_mappings/config
delete mode 100644 tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c
base-commit: 734a9da61a5bc5d82b496a86bacc097d11dc6871
--
2.54.0
next reply other threads:[~2026-11-03 15:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 15:17 Chris Down [this message]
2026-11-03 15:17 ` [PATCH v2 1/8] selftests/mm: Move sysmap_is_sealed into mm Chris Down
2026-11-03 15:18 ` [PATCH v2 2/8] selftests/mm: Skip sysmap_is_sealed when system mappings aren't sealed Chris Down
2026-11-03 15:18 ` [PATCH v2 3/8] selftests/mm: Test that the seal on system mappings is enforced Chris Down
2026-11-03 15:18 ` [PATCH v2 4/8] mm/mseal: Move MSEAL_SYSTEM_MAPPINGS to mm/Kconfig Chris Down
2026-11-03 15:18 ` [PATCH v2 5/8] uprobes/x86: Leave sealed trampolines in place on optimisation failure Chris Down
2026-11-03 15:18 ` [PATCH v2 6/8] mm/mseal: Seal system mappings in __install_special_mapping() Chris Down
2026-11-03 15:18 ` [PATCH v2 7/8] mm/mseal: Add no_mseal_sys_mappings boot parameter Chris Down
2026-11-03 15:19 ` [PATCH v2 8/8] selftests/mm: Check that no_mseal_sys_mappings unseals system mappings Chris Down
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1793718940.git.chris@chrisdown.name \
--to=chris@chrisdown.name \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=alexander@mihalicyn.com \
--cc=aou@eecs.berkeley.edu \
--cc=avagin@gmail.com \
--cc=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=jeffxu@google.com \
--cc=jmorris@namei.org \
--cc=jolsa@kernel.org \
--cc=kees@kernel.org \
--cc=kernel-team@meta.com \
--cc=kernel@xen0n.name \
--cc=liam@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=palmer@dabbelt.com \
--cc=paul@paul-moore.com \
--cc=peterz@infradead.org \
--cc=pfalcato@suse.de \
--cc=pjw@kernel.org \
--cc=rdunlap@infradead.org \
--cc=rppt@kernel.org \
--cc=serge@hallyn.com \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=svens@linux.ibm.com \
--cc=tglx@kernel.org \
--cc=vbabka@kernel.org \
--cc=vincenzo.frascino@arm.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox