Message-ID: <CABi2SkXiBv5nEu4cHBdW2GUrJUFNSEuY_OVwEp6af0hGD-U4VQ@mail.gmail.com>
Date: Tue, 25 Feb 2025 16:00:55 -0800
From: Jeff Xu <jeffxu@...omium.org>
To: Kees Cook <kees@...nel.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, "Berg, Benjamin" <benjamin.berg@...el.com>, 
	"Jason@...c4.com" <Jason@...c4.com>, "adobriyan@...il.com" <adobriyan@...il.com>, "deller@....de" <deller@....de>, 
	"gerg@...nel.org" <gerg@...nel.org>, "anna-maria@...utronix.de" <anna-maria@...utronix.de>, 
	"davem@...emloft.net" <davem@...emloft.net>, "avagin@...il.com" <avagin@...il.com>, 
	"mhocko@...e.com" <mhocko@...e.com>, "enh@...gle.com" <enh@...gle.com>, 
	"thomas.weissschuh@...utronix.de" <thomas.weissschuh@...utronix.de>, "hch@....de" <hch@....de>, 
	"hca@...ux.ibm.com" <hca@...ux.ibm.com>, "peterz@...radead.org" <peterz@...radead.org>, 
	"adhemerval.zanella@...aro.org" <adhemerval.zanella@...aro.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "ojeda@...nel.org" <ojeda@...nel.org>, 
	"jannh@...gle.com" <jannh@...gle.com>, "f.fainelli@...il.com" <f.fainelli@...il.com>, 
	"sroettger@...gle.com" <sroettger@...gle.com>, "ardb@...gle.com" <ardb@...gle.com>, 
	"jorgelo@...omium.org" <jorgelo@...omium.org>, "rdunlap@...radead.org" <rdunlap@...radead.org>, 
	"mark.rutland@....com" <mark.rutland@....com>, "Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>, 
	"vbabka@...e.cz" <vbabka@...e.cz>, "mpe@...erman.id.au" <mpe@...erman.id.au>, "oleg@...hat.com" <oleg@...hat.com>, 
	"willy@...radead.org" <willy@...radead.org>, "peterx@...hat.com" <peterx@...hat.com>, 
	"mike.rapoport@...il.com" <mike.rapoport@...il.com>, "mingo@...nel.org" <mingo@...nel.org>, 
	"rientjes@...gle.com" <rientjes@...gle.com>, "groeck@...omium.org" <groeck@...omium.org>, 
	"linus.walleij@...aro.org" <linus.walleij@...aro.org>, 
	"pedro.falcato@...il.com" <pedro.falcato@...il.com>, "ardb@...nel.org" <ardb@...nel.org>, 
	"42.hyeyoo@...il.com" <42.hyeyoo@...il.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>, 
	"johannes@...solutions.net" <johannes@...solutions.net>, 
	"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>, 
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>, 
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, 
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, 
	"aleksandr.mikhalitsyn@...onical.com" <aleksandr.mikhalitsyn@...onical.com>
Subject: Re: [PATCH v7 5/7] mseal, system mappings: enable uml architecture

On Tue, Feb 25, 2025 at 10:38 AM Kees Cook <kees@...nel.org> wrote:
>
> On Tue, Feb 25, 2025 at 03:31:06PM +0000, Lorenzo Stoakes wrote:
> > On Tue, Feb 25, 2025 at 07:06:13AM -0800, Kees Cook wrote:
> > >
> > >
> > > On February 25, 2025 2:37:11 AM PST, Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
> > > >On Tue, Feb 25, 2025 at 08:45:21AM +0000, Berg, Benjamin wrote:
> > > >> Hi,
> > > >>
> > > >> On Tue, 2025-02-25 at 06:22 +0000, Lorenzo Stoakes wrote:
> > > >> > On Mon, Feb 24, 2025 at 10:52:44PM +0000, jeffxu@...omium.org wrote:
> > > >> > > From: Jeff Xu <jeffxu@...omium.org>
> > > >> > >
> > > >> > > Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on UML, covering
> > > >> > > the vdso.
> > > >> > >
> > > >> > > Testing passes on UML.
> > > >> >
> > > >> > Maybe expand on this by stating that it has been confirmed by Benjamin (I
> > > >> > _believe_) that UML has no need for problematic relocation so this is known to
> > > >> > be good.
> > > >>
> > > >> I may well be misreading this message, but this sounds to me that this
> > > >> is a misinterpretation. So, just to clarify in case that is needed.
> > > >>
> > > >> CONFIG_MSEAL_SYSTEM_MAPPINGS does work fine for the UML kernel.
> > > >> However, the UML kernel is a normal userspace application itself and
> > > >> for this application to run, the host kernel must have the feature
> > > >> disabled.
> > > >>
> > > >> So, UML supports the feature. But it still *cannot* run on a host
> > > >> machine that has the feature enabled.
> > > >
> > > >Sigh ok. Apologies if I misunderstood.
> > > >
> > > >Is there any point having this for the 'guest' system? I mean security wise are
> > > >we concerned about sealing of system mappings?
> > >
> > > UML guests are used for testing. For example, it's the default target for KUnit's scripts. Having sealing working in the guest seems generally useful to me.
> > >
> >
> > 'Having sealing working' you mean system sealing? Because mseal works fine
> > (presumably in UML, not tried myself!)
>
> Sorry, yes, I mean "system mapping msealing".
>
> >
> > System msealing lacks any test in this series (I did ask for them...), certainly
> > no kunit tests, so this seems a bit theoretical? Unless you're talking about the
> > theoretical interaction of kunit tests and VDSO sealing?
>
> Right, I meant theoretical interaction, but it would be useful for
> future KUnit tests of system mapping msealing too.
>
> > I mean can't we just introduce this at the time if we believe this'd be useful?
>
> Perhaps adding it as part of adding some KUnit tests that exercise the
> system mapping msealing would be the most sensible.
>
> > Generally I'm not a fan of adding features mid-way through a series, the
> > revisions are meant to be refinements of the original, not an evolving thing.
> >
> > So in general I'd prefer this to be added if + when we need it for something.
>
> Yup, makes sense. And it may be that KUnit tests need to exercise more
> than what UML can support, so even the KUnit idea may be invalid.
>
> Jeff, let's leave off UML for this initial "minimum viable feature"
> series, unless there is a strong reason to keep it.
>
Sure.
It will be removed unless someone raises a strong reason to keep it.
UML can be added when future KUnit tests need it.

Thanks
-Jeff


> --
> Kees Cook

Powered by blists - more mailing lists