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

[Laurent Vivier]

Le 05/03/2021 à 18:53, Peter Maydell a écrit :
> 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.

My patch has been merged in v5.12:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2347961b11d4079deace3c81dceed460c08a8fc1

And I will push soon the qemu part:

https://patchew.org/QEMU/20210222105004.1642234-1-laurent@vivier.eu/

Thanks,
Laurent