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

[enh <enh@google.com>]

On Fri, Jan 17, 2025 at 1:20 PM Jeff Xu <jeffxu@chromium.org> wrote:
>
> On Thu, Jan 16, 2025 at 9:18 AM Pedro Falcato <pedro.falcato@gmail.com> wrote:
> >
> > On Thu, Jan 16, 2025 at 5:02 PM Benjamin Berg <benjamin@sipsolutions.net> 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@oracle.com> 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.
> > >
> > >
> > > 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
> > >
> > > UML is a bit of a niche and I am not sure it is worth worrying about it
> > > too much.
> >
> > I've been absent from this patch series in general, but this gave me
> > an idea: what if we let userspace seal these mappings itself? Since
> > glibc is already sealing things, it might as well seal these?
> > And then systems that _do_ care about this would set the glibc tunable
> > and deal with the breakage.
> >
> > Is there something seriously wrong with this approach? Besides maybe
> > not having a super easy way to discover these mappings atm, I feel
> > like it would solve all of the policy issues people have been talking
> > about in these threads.
> >
> There are technical difficulties to seal vdso/vvar from the glibc
> side. The dynamic linker lacks vdso/vvar mapping size information, and
> architectural variations for vdso/vvar also means sealing from the
> kernel side is a simpler solution. Adhemerval has more details in case
> clarification is needed from the glibc side.

as a maintainer of a different linux libc, i've long wanted a "tell me
everything there is to know about this vma" syscall rather than having
to parse /proc/maps...

...but in this special case, is the vdso/vvar size ever anything other
than "one page" in practice?

> Additionally, uprobe mapping can't be sealed by the dynamic linker,
> dynamic linker can only apply sealing during execve() and dlopen(),
> uprobe mapping isn't created during those two calls.
>
> -Jeff
>
>
> > --
> > Pedro