From: Markus Armbruster <armbru@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
qemu-devel@nongnu.org, "Stefan Hajnoczi" <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH-for-4.2] tracing: Allow to tune tracing options via the environment
Date: Sat, 06 Jul 2019 06:02:18 +0200 [thread overview]
Message-ID: <874l3zhktx.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <c4997dee-932c-eb57-23b9-4b51e8856f91@redhat.com> ("Philippe Mathieu-Daudé"'s message of "Fri, 5 Jul 2019 19:53:09 +0200")
Philippe Mathieu-Daudé <philmd@redhat.com> writes:
> On 7/5/19 3:19 PM, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé <philmd@redhat.com> 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.
>>>>>> 2. Name collision. What is the chance that existing users already
>>>>>> define environment variables with these names and that unexpected
>>>>>> behavior could result?
[...]
next prev parent reply other threads:[~2019-07-06 4:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-03 17:10 [Qemu-devel] [RFC PATCH-for-4.2] tracing: Allow to tune tracing options via the environment Philippe Mathieu-Daudé
2019-07-03 17:25 ` Daniel P. Berrangé
2019-07-03 17:29 ` Philippe Mathieu-Daudé
2019-07-04 10:24 ` Stefan Hajnoczi
2019-07-04 10:28 ` Daniel P. Berrangé
2019-07-05 8:07 ` Stefan Hajnoczi
2019-07-05 9:48 ` Philippe Mathieu-Daudé
2019-07-05 13:19 ` Markus Armbruster
2019-07-05 17:53 ` Philippe Mathieu-Daudé
2019-07-06 4:02 ` Markus Armbruster [this message]
2019-07-08 9:34 ` Daniel P. Berrangé
2019-07-08 10:27 ` Philippe Mathieu-Daudé
2019-07-08 10:38 ` Daniel P. Berrangé
2019-07-09 5:53 ` Markus Armbruster
2019-07-09 7:58 ` Stefan Hajnoczi
2019-07-03 21:58 ` no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874l3zhktx.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.