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]
