Re: RFC: linux-user: preserving argv[0] of the original binary in context of binfmt-misc

[Peter Maydell]

On Sun, 14 Feb 2021 at 15:34, Michael Tokarev <mjt@tls.msk.ru> wrote:
> As known for a long time, qemu's linux-user, when invoked in context of 
> binfmt-misc mechanism,
> does not preserve the original argv[0] element, so some software which relies 
> on argv[0] is
> not functioning under qemu-user.  When run this way, argv[0] of the program 
> being run under
> qemu-user points to this qemu-user binary, instead of being what has been 
> used to spawn the
> original binary.
>
> There's an interpreter flag in binfmt handling in recent kernels, P, or 
> preserve, which meant
> to pass 3 extra first arguments to the binfmt interpeter, - namely, the path 
> to interpreter
> itself, the argv[0] as used when spawning the original binary, and the actual 
> path of the
> said binary. But qemu-user/main does not handle this situation, - it should 
> be prepared for
> this unusual way of being invoked.
>
> There are several hackish solutions exists on this theme used by downstreams, 
> which introduces
> a wrapper program especially for binfmt registration and nothing else, uses 
> this P flag, and
> uses -argv0 qemu-user argument to pass all the necessary information to 
> qemu-user.
>
> But these wrappers introduce a different issue: since the wrapper executes 
> the qemu binary,
> we can't use F binfmt-misc flag anymore without copying the qemu-user binary 
> inside any
> foreign chroot being used with it.
>
> So the possible solution is to made qemu-user aware of this in-kernel binfmt 
> mechanism,
> which I implemented for Debian for now, as a guinea pig :)

I've always felt that the fundamental problem is that the kernel has never
provided any way for the binfmt handler to know in what way it is being
invoked. So you can't have a handler that backwards-compatibly says "if the
user/distro/whatever installed me with the P flag then I should expect my
arguments like this, but if it didn't then I should do the other thing".

> Since the original problem is the proper handling of programs which depend on 
> their own
> name in argv[0], the proposed solution is also based on the program name, - 
> this time
> it is the name under which qemu-user binary is called.
>
> I introduced a special name for qemu-user binaries to be used _only_ for 
> binfmt registration.
> This is, in my case, /usr/libexec/qemu-binfmt/foo-binfmt-P - where "foo" is 
> the architecture
> name, and "-binfmt-P" is the literal suffix. This name is just a (sym)link to 
> /usr/bin/qemu-foo,
> - just an alternative name for qemu-foo, nothing more.

Mmm, you can work around the kernel's missing feature by using a particular
naming convention. I guess that's better than nothing but I think that if
we want to go this route we should try to get buy-in from more than one
distro that this is the right way to do it...

Alternatively, if anybody has a bright idea for how to get the kernel
to tell us how it's invoking us (ELF auxv entry???) maybe we could make
a proposal to the kernel folks.

thanks
-- PMM