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: > > #!/bin/bash > 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. With regards, Daniel -- |: 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 :|
