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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b8cf08ef-0125-466f-89d2-d499cbdcd3aa@lucifer.local>
Date: Tue, 11 Mar 2025 13:42:01 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Heiko Carstens <hca@...ux.ibm.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Jeff Xu <jeffxu@...omium.org>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Kees Cook <kees@...nel.org>,
        Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-hardening@...r.kernel.org
Subject: Re: [PATCH mm-unstable 0/2] mseal system mappings fix + s390
 enablement

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.