Message-ID: <47a3d0c82e716c1838d76d079c89d230d2d1fe19.camel@sipsolutions.net>
Date: Tue, 25 Feb 2025 14:59:32 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Benjamin Berg
	 <benjamin@...solutions.net>
Cc: "jeffxu@...omium.org" <jeffxu@...omium.org>, "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>, 
 "keescook@...omium.org"	 <keescook@...omium.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>,
 "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, 2025-02-25 at 13:41 +0000, Lorenzo Stoakes wrote:
> > I figured it is not a lot of churn and there isn't really any cost to
> > enabling the feature.
> > 
> > That said, the only possible real-life use case I can see is doing MM
> > subsystem testing using UML. We certainly do not need the feature to
> > run our UML based wireless stack and driver tests.
> 
> OK ack - my concern is users getting confused about this ironic host
> vs. client thing, must disable the security feature in the _actual kernel_
> to enable it in the client.

Well, s/to enable it in the client/to run the client/, I guess.

I'm still a bit disappointed in the whole thing anyway - if this does
get enabled in e.g. ChromeOS (as it looks like), then it'll mean that
gvisor/rr/UML will never run on chromebooks, which ... I mean yeah who's
going to do that, so it's more of a purist disappointment I guess. Can't
run kunit on a chromebook then, for example. This looks much different
for more general purpose distros too.

I also don't really want to reopen a discussion that was probably had
before, but I did wonder now what the security downsides of having an
opt-out, e.g. a new ELF property, for skipping the sealings would be.
Perhaps, depending on the impact, even making that mean "no system
mappings at all", at least for UML I believe they're not needed in the
first place.


> I'm not sure this is really worth it?
> 
> I mean I agree this isn't a _huge_ amount added here and I don't want to be
> difficult - Jeff, Kees are you really keen on having this? Do you have
> specific use cases in mind or was this just a 'because we can':>)

There's always kunit that can run with UML, but I don't see tests being
added for this feature, in fact the only thing here is _disabling_ a
test. Maybe it should come with tests and then it'd be more interesting
;-)

The commit says "Testing passes on UML" but I'm not sure I see what
testing that might have been, per the cover letter Benjamin did that?

> I guess if intent is to slowly add architectures, it's not totally insane
> since we kinda know this one is ok so if that's what it is, probably won't
> oppose it _too_ badly.

I think it still makes _some_ sense to have it for the testing aspect,
but perhaps might then make sense to split it out of the series to avoid
all the confusion and submit it to UML separately later? Or just leave
it since you can always test with qemu.

johannes

Powered by blists - more mailing lists