Re: [PATCH v4 1/1] exec: seal system mappings

[Lorenzo Stoakes]

On Thu, Jan 16, 2025 at 06:01:47PM +0100, Benjamin Berg wrote:
> Hi Lorenzo,
>
> On Thu, 2025-01-16 at 15:48 +0000, Lorenzo Stoakes wrote:
> > On Wed, Jan 15, 2025 at 12:20:59PM -0800, Jeff Xu wrote:
> > > On Wed, Jan 15, 2025 at 11:46 AM Lorenzo Stoakes
> > > <lorenzo.stoakes@xxxxxxxxxx> wrote:
> >
> > [SNIP]
> > >
> > > > I've made it abundantly clear that this (NACKed) series cannot allow the
> > > > kernel to be in a broken state even if a user sets flags to do so.
> > > >
> > > > This is because users might lack context to make this decision and
> > > > incorrectly do so, and now we ship a known-broken kernel.
> > > >
> > > > You are now suggesting disabling the !CRIU requirement. Which violates my
> > > > _requirements_ (not optional features).
> > > >
> > > Sure, I can add CRIU back.
> > >
> > > Are you fine with UML and gViso not working under this CONFIG ?
> > > UML/gViso doesn't use any KCONFIG like CRIU does.
> >
> > Yeah this is a concern, wouldn't we be able to catch UML with a flag?
> >
> > Apologies my fault for maybe not being totally up to date with this, but what
> > exactly was the gViso (is it gVisor actually?)
>
> UML is a separate architecture. It is a Linux kernel running as a
> userspace application on top of an unmodified host kernel.
>
> So really, UML is a mostly weird userspace program for the purpose of
> this discussion. And a pretty buggy one too--it got broken by rseq
> already.
>
> What UML now does is:
>  * Execute a tiny static binary
>  * map special "stub" code/data pages at the topmost userspace address
>    (replacing its stack)
>  * continue execution inside the "stub" pages
>  * unmap everything below the "stub" pages
>  * use the unmap'ed area for userspace application mappings
>
> I believe that the "unmap everything" step will fail with this feature.
>

Ahhh interesting.

>
> Now, I am sure one can come up with solutions, e.g.:
>    1. Simply print an explanation if the unmap() fails
>    2. Find an address that is guaranteed to be below the VDSO and use a
>       smaller address space for the UML userspace.
>    3. Somehow tell the host kernel to not install the VDSO mappings
>    4. Add the host VDSO pages as a sealed VMA within UML to guard them
>

Right.

> UML is a bit of a niche and I am not sure it is worth worrying about it
> too much.
>
> Benjamin

Well in that case then it's number_of_things_to_worry_about--; here :)

Cheers Benjamin!

[snip]