Re: [PATCH mm-unstable 0/2] mseal system mappings fix + s390 enablement

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Tue, Mar 11, 2025 at 02:37:36PM +0100, Heiko Carstens wrote:
> On Tue, Mar 11, 2025 at 01:02:47PM +0000, Lorenzo Stoakes wrote:
> > On Tue, Mar 11, 2025 at 01:33:24PM +0100, Heiko Carstens wrote:
> > > When rebasing the mseal series on top of the generic vdso data storage
> > > the VM_SEALED_SYSMAP vm flag for the vvar mapping got lost. Add that again.
> >
> > I'm confused by this? Some merge patch resolution thing?
>
> See my other mail.
>
> > > Also add s390 support for MSEAL_SYSTEM_MAPPINGS.
> >
> > 'Also' = the whole thing this series does?
> >
> > Can you confirm that s390 absolutely does not rely upon
> > moving/manipulating/etc. the VDSO, VVAR, etc. mappings?
> >
> > You should say that here.
>
> Just like for arm64, and x86_64 the s390 part is just adding the new
> vm flag to the _install_mappings() call in vdso code. Otherwise there
> is nothing to be considered.

No, they are not just adding a flag, they are enabling the sealing of
system mappings, if a user chooses to make use of it, which already breaks
a number of useland applications that rely on remapping these.

if the architecture code ever needs to unmap/remap these, then this breaks
your architecture.

I think it would be sensible to clearly indicate that enabling this feature
does not break the s390 architecture and you've confirmed that by checking
the code and ensuring that nowhere does it rely upon doing this.

Likely that's the case, but I'd suggest you ought to make sure...

x86-64 and arm64 were checked for this and confirmed to not ever need this.

This is why we're restricting by architecture.