On Thu, Jan 16, 2025 at 5:02 PM Benjamin Berg <benjamin@xxxxxxxxxxxxxxxx> 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. > > > 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. -- Pedro
