From: Johannes Berg <johannes@sipsolutions.net>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Benjamin Berg <benjamin@sipsolutions.net>
Cc: "jeffxu@chromium.org" <jeffxu@chromium.org>,
"Jason@zx2c4.com" <Jason@zx2c4.com>,
"adobriyan@gmail.com" <adobriyan@gmail.com>,
"deller@gmx.de" <deller@gmx.de>,
"gerg@kernel.org" <gerg@kernel.org>,
"anna-maria@linutronix.de" <anna-maria@linutronix.de>,
"davem@davemloft.net" <davem@davemloft.net>,
"avagin@gmail.com" <avagin@gmail.com>,
"mhocko@suse.com" <mhocko@suse.com>,
"enh@google.com" <enh@google.com>,
"thomas.weissschuh@linutronix.de"
<thomas.weissschuh@linutronix.de>, "hch@lst.de" <hch@lst.de>,
"hca@linux.ibm.com" <hca@linux.ibm.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"adhemerval.zanella@linaro.org" <adhemerval.zanella@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"ojeda@kernel.org" <ojeda@kernel.org>,
"jannh@google.com" <jannh@google.com>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"sroettger@google.com" <sroettger@google.com>,
"ardb@google.com" <ardb@google.com>,
"jorgelo@chromium.org" <jorgelo@chromium.org>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
"vbabka@suse.cz" <vbabka@suse.cz>,
"mpe@ellerman.id.au" <mpe@ellerman.id.au>,
"oleg@redhat.com" <oleg@redhat.com>,
"willy@infradead.org" <willy@infradead.org>,
"keescook@chromium.org" <keescook@chromium.org>,
"peterx@redhat.com" <peterx@redhat.com>,
"mike.rapoport@gmail.com" <mike.rapoport@gmail.com>,
"mingo@kernel.org" <mingo@kernel.org>,
"rientjes@google.com" <rientjes@google.com>,
"groeck@chromium.org" <groeck@chromium.org>,
"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"pedro.falcato@gmail.com" <pedro.falcato@gmail.com>,
"ardb@kernel.org" <ardb@kernel.org>,
"42.hyeyoo@gmail.com" <42.hyeyoo@gmail.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-hardening@vger.kernel.org"
<linux-hardening@vger.kernel.org>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"aleksandr.mikhalitsyn@canonical.com"
<aleksandr.mikhalitsyn@canonical.com>
Subject: Re: [PATCH v7 5/7] mseal, system mappings: enable uml architecture
Date: Tue, 25 Feb 2025 14:59:32 +0100 [thread overview]
Message-ID: <47a3d0c82e716c1838d76d079c89d230d2d1fe19.camel@sipsolutions.net> (raw)
In-Reply-To: <19e81e87-7430-4e23-ac67-dbb987496dd4@lucifer.local>
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
next prev parent reply other threads:[~2025-02-25 14:00 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 22:52 [PATCH v7 0/7] mseal system mappings jeffxu
2025-02-24 22:52 ` [PATCH v7 1/7] mseal, system mappings: kernel config and header change jeffxu
2025-02-25 6:05 ` Lorenzo Stoakes
2025-02-26 1:33 ` Jeff Xu
2025-02-26 6:04 ` Lorenzo Stoakes
2025-02-28 0:04 ` Jeff Xu
2025-02-28 10:32 ` Lorenzo Stoakes
2025-02-25 15:22 ` Liam R. Howlett
2025-02-25 15:37 ` Lorenzo Stoakes
2025-02-26 0:04 ` Jeff Xu
2025-02-24 22:52 ` [PATCH v7 2/7] selftests: x86: test_mremap_vdso: skip if vdso is msealed jeffxu
2025-02-25 6:15 ` Lorenzo Stoakes
2025-02-25 22:37 ` Jeff Xu
2025-02-26 5:58 ` Lorenzo Stoakes
2025-02-24 22:52 ` [PATCH v7 3/7] mseal, system mappings: enable x86-64 jeffxu
2025-02-25 1:03 ` Kees Cook
2025-02-26 0:21 ` Jeff Xu
2025-02-25 8:08 ` Thomas Weißschuh
2025-02-26 0:48 ` Jeff Xu
2025-02-26 7:35 ` Thomas Weißschuh
2025-02-27 21:44 ` Jeff Xu
2025-02-24 22:52 ` [PATCH v7 4/7] mseal, system mappings: enable arm64 jeffxu
2025-02-25 6:20 ` Lorenzo Stoakes
2025-02-25 22:26 ` Jeff Xu
2025-02-26 5:25 ` Lorenzo Stoakes
2025-02-26 17:11 ` Liam R. Howlett
2025-02-26 17:17 ` Jeff Xu
2025-02-26 17:43 ` Lorenzo Stoakes
2025-02-26 18:14 ` Lorenzo Stoakes
2025-02-28 0:48 ` Jeff Xu
2025-02-28 10:31 ` Lorenzo Stoakes
2025-02-24 22:52 ` [PATCH v7 5/7] mseal, system mappings: enable uml architecture jeffxu
2025-02-25 6:22 ` Lorenzo Stoakes
2025-02-25 8:45 ` Berg, Benjamin
2025-02-25 10:37 ` Lorenzo Stoakes
2025-02-25 12:24 ` Benjamin Berg
2025-02-25 13:41 ` Lorenzo Stoakes
2025-02-25 13:59 ` Johannes Berg [this message]
2025-02-25 15:06 ` Kees Cook
2025-02-25 15:31 ` Lorenzo Stoakes
2025-02-25 18:38 ` Kees Cook
2025-02-26 0:00 ` Jeff Xu
2025-02-24 22:52 ` [PATCH v7 6/7] mseal, system mappings: uprobe mapping jeffxu
2025-02-25 6:24 ` Lorenzo Stoakes
2025-02-26 0:06 ` Jeff Xu
2025-02-26 5:57 ` Lorenzo Stoakes
2025-02-26 16:26 ` Oleg Nesterov
2025-02-26 16:33 ` Oleg Nesterov
2025-02-26 16:45 ` Lorenzo Stoakes
2025-02-26 18:01 ` Oleg Nesterov
2025-02-26 18:06 ` Lorenzo Stoakes
2025-02-26 18:19 ` Liam R. Howlett
2025-02-26 18:20 ` Oleg Nesterov
2025-02-26 18:25 ` Lorenzo Stoakes
2025-02-27 23:38 ` Jeff Xu
2025-02-28 10:39 ` Lorenzo Stoakes
2025-02-27 21:48 ` Jeff Xu
2025-02-24 22:52 ` [PATCH v7 7/7] mseal, system mappings: update mseal.rst jeffxu
2025-02-24 23:03 ` [PATCH v7 0/7] mseal system mappings Pedro Falcato
2025-02-24 23:07 ` Jeff Xu
2025-02-25 6:09 ` Lorenzo Stoakes
2025-02-25 10:32 ` Lorenzo Stoakes
2025-02-26 0:17 ` Jeff Xu
2025-02-26 6:00 ` Lorenzo Stoakes
2025-02-27 23:43 ` Jeff Xu
2025-02-28 10:32 ` Lorenzo Stoakes
2025-02-25 15:18 ` Lorenzo Stoakes
2025-02-26 0:12 ` Jeff Xu
2025-02-26 5:42 ` your mail Lorenzo Stoakes
2025-02-28 0:55 ` Jeff Xu
2025-02-28 9:35 ` Lorenzo Stoakes
2025-02-28 17:24 ` Jeff Xu
2025-02-28 17:30 ` Lorenzo Stoakes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47a3d0c82e716c1838d76d079c89d230d2d1fe19.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=42.hyeyoo@gmail.com \
--cc=Jason@zx2c4.com \
--cc=Liam.Howlett@oracle.com \
--cc=adhemerval.zanella@linaro.org \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aleksandr.mikhalitsyn@canonical.com \
--cc=anna-maria@linutronix.de \
--cc=ardb@google.com \
--cc=ardb@kernel.org \
--cc=avagin@gmail.com \
--cc=benjamin@sipsolutions.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=enh@google.com \
--cc=f.fainelli@gmail.com \
--cc=gerg@kernel.org \
--cc=groeck@chromium.org \
--cc=hca@linux.ibm.com \
--cc=hch@lst.de \
--cc=jannh@google.com \
--cc=jeffxu@chromium.org \
--cc=jorgelo@chromium.org \
--cc=keescook@chromium.org \
--cc=linus.walleij@linaro.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mark.rutland@arm.com \
--cc=mhocko@suse.com \
--cc=mike.rapoport@gmail.com \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=ojeda@kernel.org \
--cc=oleg@redhat.com \
--cc=pedro.falcato@gmail.com \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=rientjes@google.com \
--cc=sroettger@google.com \
--cc=thomas.weissschuh@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox