Re: [Qemu-devel] [RFC PATCH-for-4.2] tracing: Allow to tune tracing options via the environment

[Philippe Mathieu-Daudé]

On 7/8/19 11:34 AM, Daniel P. Berrangé wrote:
> On Sat, Jul 06, 2019 at 06:02:18AM +0200, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé <address@hidden> writes:
>>
>>> On 7/5/19 3:19 PM, Markus Armbruster wrote:
>>>> Philippe Mathieu-Daudé <address@hidden> writes:
>>>>> On 7/5/19 10:07 AM, Stefan Hajnoczi wrote:
>>>>>> 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:
>> [...]
>>>>>>>> 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?
>>>>
>>>> The common (and sad) solution for this is to require whatever runs $PROG
>>>> at a different trust level to scrub the environment.
>>>
>>> I hope people concerned by security build QEMU with the NOP trace backend.
>>
>> I sure hope at least one of our tracing backends (other than nop) can be
>> used safely in production.

I'm not saying production and security are orthogonal, but recent trend
in security seems to reduce code exposure by disabling component, so I'd
not be surprise if people who primary concern is strong security to use
the NOP trace backend as default.

> AFAIK, *all* of the trace backends are safe for use in production. The
> only questions are around performance in production.  If anyone knows of
> any security problems with specific backends we should either address them,
> or document the backend is unsafe.

I hope the tracing backend/frontends are safe. Now the trace events log
a bunch of interesting information, so I'd not be surprise if some
security researcher open a "QEMU information leak" CVE because we log
various guest pointers i.e.

Anyway, to stop bikeshedding this thread, can you add few lines about
why not use getenv() in the HACKING?

Thanks,

Phil.