Re: [Qemu-devel] [PATCH v2 2/4] linux-user: pass environment arguments in execve

[Joel Holdsworth <joel.holdsworth@vcatechnology.com>]

On 20/06/16 21:29, Laurent Vivier wrote:
>
> Le 20/06/2016 à 21:51, Joel Holdsworth a écrit :
>> On 15/06/16 20:59, Laurent Vivier wrote:
>>> Le 14/06/2016 à 21:26, Joel Holdsworth a écrit :
>>>> Previously, when emulating execve(2), qemu would execute a child
>>>> instance of the emulator with the environment variables provided by
>>>> the parent process. This caused problems with qemu if any of the
>>>> variables affected the child emulator's behaviour e.g.
>>>> LD_LIBRARY_PATH.
>>> The best way to avoid that is to use a statically linked qemu.
>> Stepping back a bit; the problem I'm trying to solve is this...
>>
>> There are some processes that invoke a helper process to do some work
>> for them e.g. gstreamer's gst-plugin-scanner. Previously qemu would
>> attempt to execute the helper executable as if it were machine-native,
>> which won't work. These patches modify qemu so that it will (optionally)
>> run the child process inside a child instance of qemu.
> If the context is to use qemu to have a cross build/test environment, I
> like the idea, but you should use chroot/binfmt to do that.
>
> Even without the architecture change, the build/test environment must be
> isolated (chroot) from the host environment to know exactly what you
> build/test.
I do know what we test though: (a gstreamer unit test) -> 
(gst-plugin-scanner).

chroot+binfmt is a fine solution for testing a whole user-space, but 
rather overkill for just a single program.

Also, chroot and binfmt require root permissions. Also the libraries 
have to be installed in a rootfs tree - which isn't how my use case works.



>> My experience as a user was that it took a couple of hours of searching
>> through strace logs to figure out what the issue was. gstreamer would
>> just fail with a generic error about the helper. These patches are meant
>> to make qemu do the right thing.
>>
>> Saying to the user that they should make a static linked build of qemu
>> isn't very practical. Having a command line argument is a much easier
>> solution for the user, that doesn't force them not to used
>> shared-library builds. The distros aren't going to go for that.
> You can provide the RPM/DEB with the statically linked qemu.
> (it will have no dependencies)

Users could do that, but as far as I'm concerned that isn't really 
satisfactory.

The current behaviour was quite unexpected to me - there were no 
warnings, and the need to link qemu statically isn't documented 
anywhere. If you really believe that static linking is the best answer 
here, then shouldn't the shared library option be removed? Because with 
the shared-library build, qemu-user is somewhat "broken".

But the distros won't like that because of the induced bloat.

>> Moreover, LD_LIBRARY_PATH is just one example. LD_PRELOAD is another.
>> Timezone and locale environment variables are also an issue.
> all LD_ are for the ld.so, the dynamic loader, and with a statically
> linked qemu, you don't use the host ld.so (see ld.so(8)).
>
> Why timezone and local environment variables are also an issue?
All these environment variables affect the behaviour of qemu's glibc - 
these are examples of the the parent-guest being able to modify the 
behaviour of the child-host if the execve qemu wrapper patch is 
integrated. The correct way to pass the execve environ to the child qemu 
wrapper is through -E and -U arguments.


> Child qemu instance should just ignore it. Thanks, Laurent 

The child qemu can't control what glibc will respond to.

There are a lot of environment variables that can affect it: 
http://www.scratchbox.org/documentation/general/tutorials/glibcenv.html

For example with LANG=, the parent-guest process might want to run the 
child-guest in Japanese, but the child-qemu should still run in English.