|
From: | Joel Holdsworth |
Subject: | Re: [Qemu-devel] [PATCH v2 2/4] linux-user: pass environment arguments in execve |
Date: | Mon, 20 Jun 2016 22:27:50 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 |
On 20/06/16 21:29, Laurent Vivier wrote:
I do know what we test though: (a gstreamer unit test) -> (gst-plugin-scanner).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.
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.
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.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?
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.
[Prev in Thread] | Current Thread | [Next in Thread] |