[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: linux-user: preserving argv[0] of the original binary in contex
From: |
Laurent Vivier |
Subject: |
Re: RFC: linux-user: preserving argv[0] of the original binary in context of binfmt-misc |
Date: |
Fri, 5 Mar 2021 19:07:08 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 |
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