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

[Jeff Xu <jeffxu@google.com>]

Hi Chris, Lorenzo,

On Tue, Oct 27, 2026 at 04:57:04PM +0000, Lorenzo Stoakes (ARM) wrote:
> > 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 for working on this series!

Could we please keep the test coverage for the unsealed [vdso] case and
avoid unconditionally skipping whenever [vdso] is unsealed?

There are two regressions I'd love for us to still be able to catch:

1. Kernel or config regressions when sealing is expected to be on:
    Distros/platforms such as ChromeOS and Android enable
    CONFIG_MSEAL_SYSTEM_MAPPINGS=y. Originally this test lived in its own
    selftest directory with `CONFIG_MSEAL_SYSTEM_MAPPINGS=y` in its
    `config` fragment specifically so that if a kernel change accidentally
    broke system mapping sealing completely, [vdso] being unsealed would
    trigger a hard FAIL rather than silently turning into a SKIP in CI
    (whereas `run_vmtests.sh` runs on kernels with
    `MSEAL_SYSTEM_MAPPINGS=n`).

2. Regressions in the new `no_mseal_sys_mappings` boot parameter itself:
    When booted with `no_mseal_sys_mappings` (or when unsealed), running
    the assertions in Patch 3 (verifying system mappings have no `sl` flag
    and that `munmap()` / `mremap()` -- and ideally `mprotect(PROT_READ |
    PROT_WRITE)` -- on [vdso] succeed) directly verifies that the boot
    parameter works and doesn't regress.

If we move the test into `tools/testing/selftests/mm/`, perhaps we could:
- Check `/proc/cmdline` for `no_mseal_sys_mappings` and actively test the
   unsealed behavior when it is set (rather than skipping), and
- Either enable `CONFIG_MSEAL_SYSTEM_MAPPINGS=y` in `selftests/mm/config`,
   or keep strict failure as an option (e.g. `./sysmap_is_sealed` fails if
   unsealed without the boot param, while `run_vmtests.sh` passes a flag
   like `--allow-disabled` when `CONFIG_MSEAL_SYSTEM_MAPPINGS` may not be
   enabled), so CI environments that expect sealing still catch a broken
   seal.

Thanks,
Jeff