Re: [PATCH 1/3] mseal sysmap: Add mseal_system_mappings= boot parameter

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Wed, Oct 28, 2026 at 12:37:05AM +0800, Chris Down wrote:
> Hi Lorenzo,
>
> Thanks for the quick and thorough review!

No worries!

>
> Lorenzo Stoakes (ARM) writes:
> > The existing implementation is a bit of a mess, so any work that extends it
> > has to put in the work to improve things first.
> >
> > I _hate_ VM_SEALED_SYSMAP. It's a hack. A tasteful way of doing this is
> > really required for a series touching this to be taken, honestly.
> >
> > See below for implementation ideas.
>
> That's fair, I'll do the cleanup first in v2.

Thanks!

>
> > (Also it's the merge window, so no more revisions until -rc1, when you need
> > to resend, thanks.)
>
> Sure, I'll wait until after -rc1.

Yup :) we are a bit inundated with AI fixes these days.

>
> > Could we have some actual justification for the use of the feature please?
> > So far I've seen arm-waving.
>
> Sure. At Meta, we build sealing into the kernel for our VM hosts, and we'd
> like it on as much of the rest of the fleet as possible. The problem is that
> the rest of the fleet also runs things which it breaks. Just as one example
> among many, Reverie (which Hermit our deterministic execution tool is built
> on) patches the vDSO of the processes it traces by injecting an
> mprotect()[0].
>
> So right now the hosts which want sealing need their own kernel image, and
> this option is one of the things which forces that. We're working towards
> hopefully running one kernel across the fleet, and with a boot parameter we
> can build it with CONFIG_MSEAL_SYSTEM_MAPPINGS=y, keep sealing on by
> default, and turn it off only on the hosts which run those tools.
>
> Let me know if you'd like more information. I can also put that in the
> commit message for v2.

Great, thanks for the background! Yeah it'd be good to include all that!

I guess I'm fishing for the security justification, but maybe that ship sailed
:) but it'd be helpful to also include that.

>
> 0: https://docs.rs/reverie-core/latest/reverie/vdso/index.html
>
> > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > > index e75344f4e0cd..b1ec9a8a979e 100644
> > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > @@ -4270,6 +4270,13 @@ Kernel parameters
> > >  	MTD_Region=	[MTD] Format:
> > >  			<name>,<region-number>[,<base>,<size>,<buswidth>,<altbuswidth>]
> > >
> > > +	mseal_system_mappings=
> > > +			[KNL,EARLY] Under CONFIG_MSEAL_SYSTEM_MAPPINGS,
> > > +			whether system mappings are sealed for this boot.
> > > +			See Documentation/userspace-api/mseal.rst.
> > > +			Format: <bool>
> > > +			Default: 1 (enabled).
> >
> > You _have_ to duplicate the list of things this breaks here please.
>
> Will do.

Thanks!

>
> > Let's negate things first. Make the boot flag 'no_mseal_sys_mappings'
> > rather than confusingly implying mseal_system_mappings=1 could enable it
> > even with a config option not provided.
> >
> > Then add something like:
> >
> > static inline bool mseal_system_mappings(void)
> > {
> >        return IS_ENABLED(CONFIG_MSEAL_SYSTEM_MAPPINGS) &&
> >               !mseal_system_mappings_disabled;
> > }
> >
> > And call that in _install_special_mapping().
>
> Makes sense. I'll call it in __install_special_mapping(), since that's where
> we already have a vma_flags_t, so it can just set VMA_SEALED_BIT without
> going near the legacy flags at all, if that sounds good? Then
> VM_SEALED_SYSMAP and all of its users can hopefully go away.

Yeah I typo'd that haha, doh! And it just happens to be a function :) yes
__install_special_mapping().

>
> > The LLM overlords tell me that only uprobe trampolines would see a delta
> > from this given the ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS restriction.
> >
> > This would improve things a lot.
>
> Yes, but there is a wrinkle. Since 07c308eb2bcf ("uprobes/x86: Do not leak
> trampoline vma mapping on optimization failure"), __arch_uprobe_optimize()
> unmaps a trampoline it has just created if swbp_optimize() fails, and with
> the trampoline sealed that would now fail with -EPERM. I can see two ways to
> deal with that:
>
> One is to seal trampolines too, and just leave a sealed trampoline in place
> on that path. It's already a WARN_ON_ONCE(), and get_uprobe_trampoline()
> reuses any trampoline which is in reach, so nothing is really leaked.
>
> Another way would be to keep trampolines unsealed, but that means bringing
> back some kind of per-mapping opt-in, which is exactly what we're trying to
> get rid of.
>
> What do you think? Either way I'll Cc Jiri and Oleg on it.

I think the easiest would be to just seal them too.

>
> > > +#define VM_SEALED_SYSMAP	(mseal_sysmap_enabled ? VM_SEALED : VM_NONE)
> >
> > No, you don't use the legacy VMA flags API for new work. Sorry.
> >
> > See above as to a pointer as to how this should look.
>
> Sure thing.

Thanks, but with the proposed alternative approach, we can just yeet this from
the code anyway! :)

>
> > >  static bool range_contains_unmapped(unsigned long start, unsigned long end)
> > >  {
> > >  	VMA_ITERATOR(vmi, current->mm, start);
> > > diff --git a/security/Kconfig b/security/Kconfig
> > > index f7bf6cdc6229..d5e83af1bfc6 100644
> > > --- a/security/Kconfig
> > > +++ b/security/Kconfig
> > > @@ -67,6 +67,8 @@ config MSEAL_SYSTEM_MAPPINGS
> > >  	  of writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Therefore
> > >  	  this config can't be enabled universally.
> > >
> > > +	  Sealing can be turned off at boot with "mseal_system_mappings=0".
> > > +
> >
> > 'With this configuration option set, sealing can...' right now this reads a
> > little like it's defaulted on.
> >
> > Also can we move this Kconfig option out of security and into mm please?
> > This is explicitly an mm feature, and it should never have been added there
> > (mm needs to know if somebody sets this default=y or something for
> > instance).
>
> Sure thing.

Thank!

>
> > Tests as separate commits please.
>
> Happy to do so, but aren't you worried about bisect safety? Or would you
> suggest another way?
>
> > This seems total overkill, you're checking whether a boot parameter works?
>
> It was mostly there so that the existing test wouldn't fail when booted with
> mseal_system_mappings=0, which meant parsing a bool. With a negated flag it
> can be a lot simpler, but I'm not sure which of these you'd prefer:
>
> One option is to skip if [vdso] isn't sealed, and otherwise expect all
> system mappings to be sealed. Then there's parsing at all, and it also stops
> failing on kernels built without CONFIG_MSEAL_SYSTEM_MAPPINGS, which matters
> more once it's in run_vmtests.sh. The downside is that it can't notice
> sealing being broken entirely.
>
> Another is to check /proc/cmdline for no_mseal_sys_mappings and expect the
> mappings to be unsealed if it's there. That's only a few lines now, but the
> test still fails on kernels without the option, as it does today.
>
> Do you have a preference between the two?
>

Yeah it's awkward, really moving the tests to mm we'd have to skip them if the
vdso isn't sealed, then assume a sealed vdso for a new process = feature
enabled.

I guess at that point it's redundant to check if disabled?

> Thanks a lot for the review!

No worries!

--
Cheers, Lorenzo