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

[Riku Voipio <voipio@kos.to>]

   20.6.2016 22.51 Joel Holdsworth <joel.holdsworth@vcatechnology.com>
   kirjoitti:
   >
   > On 15/06/16 20:59, Laurent Vivier wrote:
   > >
   > > Le 14/06/2016 `a 21:26, Joel Holdsworth a ecrit :
   > >> 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.
   >
   > 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.

   Actually at least Debian and Ubuntu already ship static qemu-user
   binaries. Using static qemu-user and binfmt_misc is the standard way
   people use qemu-user.

   >
   > Moreover, LD_LIBRARY_PATH is just one example. LD_PRELOAD is another.
   > Timezone and locale environment variables are also an issue.
   >
   > In an ideal world, it wouldn't even be necessary to add an argument -
   > qemu would just do the right thing automatically. Though I'm not sure
   > how that could be done correctly, so a command line option is a good
   > compromise for a starting point.
   >
   >
   > >
   > >> This patch solves this issue by passing the environment variables
   > >> with '-E' arguments to the child qemu instance. The call to
   > >> execve(2) is replaced by a call to execv(2) so that the parent
   > >> emulator's environment variable state is propagated into the
   child.
   > >>
   > >> Any variables from the host environment that are not in the in the
   > >> execve() call are removed with a '-U' argument.
   > > Run ./scripts/checkpatch.pl on your patch...
   > >
   > > and add your Signed-off-by here.
   > Sure ok.
   >
   >
   > > The environment is already managed in linux-user/main.c:main(), I
   don't
   > > understand why the qemu_execve() special case should differ from
   the
   > > general case.
   > Maybe I've missed something, but the problem I'm trying to solve here
   is
   > the issue of correctly propagating the guest environment variables
   into
   > the child process.
   >
   > The parent guest process (running inside qemu-user) constructs a set
   of
   > environment variables and passes them to execve. However, if the
   parent
   > qemu-user decides to run a child instance of qemu-user it should run
   > with the same environment variables as the parent, but with
   environment
   > variables the parent-guest passed through the arguments for the
   child-guest.
   >
   > If gstreamer decides to run gst-plugin-scanner with a certain
   environ,
   > that is for the child qemu guest, not the child qemu instance itself.
   >
   >