On Thu, Jul 04, 2019 at 11:28:37AM +0100, Daniel P. Berrangé wrote:
> On Thu, Jul 04, 2019 at 11:24:57AM +0100, Stefan Hajnoczi wrote:
> > On Wed, Jul 03, 2019 at 06:25:01PM +0100, Daniel P. Berrangé wrote:
> > > On Wed, Jul 03, 2019 at 07:10:05PM +0200, Philippe Mathieu-Daudé wrote:
> > > > @@ -306,6 +308,13 @@ bool trace_init_backends(void)
> > > > openlog(NULL, LOG_PID, LOG_DAEMON);
> > > > #endif
> > > >
> > > > + trace_init_file(getenv("QEMU_TRACE_LOGFILE"));
> > > > + trace_init_events(getenv("QEMU_TRACE_EVENTFILE"));
> > > > + trace_env = getenv("QEMU_TRACE_EVENTS");
> > > > + if (trace_env) {
> > > > + trace_enable_events(trace_env);
> > > > + }
> > > > +
> > >
> > > I don't think it is a nice idea to add this via environment variables
> > > to QEMU itself. Why not modify libqtest qtest_init_without_qmp_handshake
> > > to read the env vars and then pass a suitable -trace arg when spawning
> > > QEMU ?
> >
> > What is the concern about adding these environment variables to QEMU?
> >
> > It is convenient to be able to use tracing even if QEMU is invoked by
> > something you cannot modify/control.
> >
> > The main issues I see with environment variables are:
> >
> > 1. Security. Is there a scenario where an attacker can use environment
> > variables to influence the behavior of a QEMU process running at a
> > different trust level?
> >
> > 2. Name collision. What is the chance that existing users already
> > define environment variables with these names and that unexpected
> > behavior could result?
>
> One of the biggest problems with QEMU in general has been poorly modelled
> & defined interfaces for configuration. At runtime we've solved this with
> QMP. At startup we're still fighting the horror of QemuOpts in general and
> haven't got startup modelling to be on a par with that offered by QEMU.
> It was even worse when Audio didn't even use QemuOpts and instead used
> an arbitrary set of poorly defined env variables. To me adding yet another
> way to configure QEMU via env vars is moving in the opposite direction to
> what we want.In this case the environment variables are optional and meant for cases where the user cannot change the QEMU command-line. I think they serve a different purpose from the audio subsystem environment variables and I'd be happy to merge them. Philippe: Have you tried adding the environment variable to libqtest as Dan suggested and did it work for your use case? Stefan
signature.asc
Description: PGP signature
