linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: "Berg, Benjamin" <benjamin.berg@intel.com>,
	"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>,
	"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>,
	"johannes@sipsolutions.net" <johannes@sipsolutions.net>,
	"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 10:38:42 -0800	[thread overview]
Message-ID: <202502251035.239B85A93@keescook> (raw)
In-Reply-To: <de5577b5-5d9d-4173-99f7-8c156c53f175@lucifer.local>

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@oracle.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@chromium.org wrote:
> > >> > > From: Jeff Xu <jeffxu@chromium.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.

-- 
Kees Cook


  reply	other threads:[~2025-02-25 18:38 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
2025-02-25 15:06         ` Kees Cook
2025-02-25 15:31           ` Lorenzo Stoakes
2025-02-25 18:38             ` Kees Cook [this message]
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=202502251035.239B85A93@keescook \
    --to=kees@kernel.org \
    --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.berg@intel.com \
    --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=johannes@sipsolutions.net \
    --cc=jorgelo@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