On Tue, Feb 25, 2025 at 10:38 AM Kees Cook <kees@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxx wrote: > > > >> > > From: Jeff Xu <jeffxu@xxxxxxxxxxxx> > > > >> > > > > > >> > > 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
