From: Markus Armbruster <armbru@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
"Gabriel L. Somlo" <somlo@cmu.edu>,
Laszlo Ersek <lersek@redhat.com>,
qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2] vl.c: disallow command line fw cfg without opt/
Date: Thu, 17 Mar 2016 11:09:24 +0100 [thread overview]
Message-ID: <87fuvpv2jv.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <1458053080-29170-1-git-send-email-mst@redhat.com> (Michael S. Tsirkin's message of "Tue, 15 Mar 2016 16:47:17 +0200")
Top level reply, because this isn't in reply to any specific message in
the thread, more like in reply to all of them.
FW CFG's primary user is QEMU, which uses it to expose configuration
information (in the widest sense) to Firmware. Thus the name FW CFG.
FW CFG can also be used by others for their own purposes. QEMU is
merely acting as transport then.
I think there are actually three separate questions that should not be
mixed up.
1. Is it a good idea to offer FW CFG as a transport to others?
I have no opinion on this myself, but I trust Gerd's and Laszlo's
judgement. Their answer seems to be a clear yes.
2. Is it a good idea to let users mess with QEMU's use of FW CFG?
I think this is a special case of a more general question: should we
try to protect the user from himself?
We should definitely try not to trap the user. Obvious usage should
be as safe as we can make it. Risky usage should be marked in the
docs and/or warn on use.
However, we should not try to stop our users from doing stupid
things, as that would also stop them from doing clever things.
3. How should the FW CFG name space be shared among its users?
Bad things can happen if others use the namespace in ways that
conflict with QEMU's use, or conflict with another "other".
This isn't an issue specific to FW CFG. For instance, upstream QEMU
and the various downstream QEMUs all use the QMP command name space,
and bad things can happen if they conflict. The difference is they'd
conflict at compile time. Conflicts are easier to detect, but just
as hard to resolve.
QMP's solution is to reserve part of the name space for "others"
(downstreams), and subdivide the reserved part further via RFQDN:
owning a DNS domain name makes you own that RFQDN subdivision.
For FW CFG, we did only the first half, namely reserving part of the
name space for others: /opt/. We neglected to spell out rules for
its safe sharing, i.e. the second part.
I don't think it's too late to fix that: amend the specification to
stipulate that owning a DNS domain name makes you own /opt/RFQDN/.
Throw in known existing uses like /opt/ovmf/ as special cases.
next prev parent reply other threads:[~2016-03-17 10:09 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-15 14:47 [Qemu-devel] [PATCH v2] vl.c: disallow command line fw cfg without opt/ Michael S. Tsirkin
2016-03-16 16:29 ` Markus Armbruster
2016-03-16 16:50 ` Michael S. Tsirkin
2016-03-16 18:15 ` Gabriel L. Somlo
2016-03-16 18:35 ` Laszlo Ersek
2016-03-16 18:43 ` Michael S. Tsirkin
2016-03-16 19:15 ` Laszlo Ersek
2016-03-16 20:22 ` Michael S. Tsirkin
2016-03-16 20:24 ` Michael S. Tsirkin
2016-03-16 20:31 ` Michael S. Tsirkin
2016-03-17 8:49 ` Laszlo Ersek
2016-03-17 9:40 ` Paolo Bonzini
2016-03-17 11:32 ` Michael S. Tsirkin
2016-03-17 13:12 ` Paolo Bonzini
2016-03-17 13:15 ` Michael S. Tsirkin
2016-03-17 8:42 ` Gerd Hoffmann
2016-03-17 9:43 ` Laszlo Ersek
2016-03-17 10:22 ` Gerd Hoffmann
2016-03-17 13:28 ` Laszlo Ersek
2016-03-17 13:35 ` Michael S. Tsirkin
2016-03-17 13:37 ` Paolo Bonzini
2016-03-17 16:59 ` Gerd Hoffmann
2016-03-17 13:23 ` Michael S. Tsirkin
2016-03-17 9:49 ` Laszlo Ersek
2016-03-17 10:09 ` Markus Armbruster [this message]
2016-03-17 13:13 ` Michael S. Tsirkin
2016-03-17 13:30 ` Paolo Bonzini
2016-03-17 13:49 ` Laszlo Ersek
2016-03-17 13:49 ` Michael S. Tsirkin
2016-03-17 13:55 ` Paolo Bonzini
2016-03-17 14:17 ` Michael S. Tsirkin
2016-03-17 14:50 ` Paolo Bonzini
2016-03-17 15:40 ` Michael S. Tsirkin
2016-03-17 17:17 ` Gerd Hoffmann
2016-03-17 19:35 ` Paolo Bonzini
2016-03-17 19:55 ` Michael S. Tsirkin
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=87fuvpv2jv.fsf@blackfin.pond.sub.org \
--to=armbru@redhat.com \
--cc=kraxel@redhat.com \
--cc=lersek@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=somlo@cmu.edu \
/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.