[PATCH 2/2] qemu_process: Start QEMU for caps probing more robustly
Daniel P. Berrangé
berrange at redhat.com
Thu Mar 17 16:23:17 UTC 2022
On Wed, Mar 16, 2022 at 04:39:36PM +0100, Michal Privoznik wrote:
> When probing QEMU capabilities, we look at whatever <emulator/>
> was specified in the domain XML and execute it with couple of
> arguments (-daemonize being one of them) Then, we use
> virCommandSetErrorBuffer() to read stderr of the child process
> hoping to read possible error message just before the process
> daemonized itself. Well, this works as long as the emulator
> binary behaves.
> If the binary is evil and basically does the following:
> sleep 1h
> then virCommandRun() called from qemuProcessQMPLaunch() doesn't
> return for whole hour (because it's stuck in reading stderr of
> the child process). This behavior of ours is very suboptimal.
> The solution is to not rely on the binary behaving correctly on
> -daemonize argument but to daemonize the process ourselves (via
> virCommandDaemonize()) and then wait for the monitor to show up
> with a timeout. This in turn means, that we can no longer use
> virCommandSetErrorBuffer() but we can do the equivalent with
> virCommandSetErrorFD() and a bit of code.
> Sure, this doesn't shield us from malicious binaries 100% but
> helps preventing depletion of worker threads.
I don't think malicious binaries is a threat we need to
even contemplate. Any scenario that triggers this involves
privileged access to libvirt.
I absolutely don't want us to inject a timeout into the
startup process, as they are inherantly fragile. We worked
hard to eliminate them in normal QEMU startup, and don't
think we want them in capabilities probing either.
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
More information about the libvir-list