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

[Laurent Vivier]

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.

> 
> 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)

> 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?

> 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.

Child qemu instance should just ignore it.

Thanks,
Laurent