From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF6jc-0001Ij-9n for qemu-devel@nongnu.org; Mon, 20 Jun 2016 17:27:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF6jY-00017H-0k for qemu-devel@nongnu.org; Mon, 20 Jun 2016 17:27:55 -0400 Received: from mail-it0-x22c.google.com ([2607:f8b0:4001:c0b::22c]:37482) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF6jX-00017B-Pt for qemu-devel@nongnu.org; Mon, 20 Jun 2016 17:27:51 -0400 Received: by mail-it0-x22c.google.com with SMTP id f6so82798ith.0 for ; Mon, 20 Jun 2016 14:27:51 -0700 (PDT) References: <1465932382-28645-1-git-send-email-joel.holdsworth@vcatechnology.com> <1465932382-28645-3-git-send-email-joel.holdsworth@vcatechnology.com> <3dd5c191-ebb0-63da-1c97-f28a578fc9b3@vivier.eu> <57684939.3020207@vcatechnology.com> From: Joel Holdsworth Message-ID: <57685FD6.5020509@vcatechnology.com> Date: Mon, 20 Jun 2016 22:27:50 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v2 2/4] linux-user: pass environment arguments in execve List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Vivier , qemu-devel@nongnu.org Cc: riku.voipio@iki.fi, Vasileios.Kalintiris@imgtec.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.