Re: [Qemu-devel] [PATCH v2] vl.c: disallow command line fw cfg without opt/

[Michael S. Tsirkin]

On Thu, Mar 17, 2016 at 11:09:24AM +0100, Markus Armbruster wrote:
> 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.

As usual, very well put.

This makes complete sense to me. I would rate the current interface
rather as attempting to trap users.  The only way to figure it out is to
read the source, and the source includes ovmf and maybe other firmware.
Here is a proposal trying to address the above, including a way to do
stupid things:

QEMU command line:
        A. -fw-cfg RFQDN/PATH prepends usr/. So users will not get conflicts
           with QEMU hardware

        B. -fw-cfg org.qemu/unsupported/XXX as a hack, removes
                org.qemu/unsupported/ and leaves just XXX,
                for people who want to break^?^?^?^?^?debug QEMU hardware

        C. -fw-cfg opt/FOO accepts any path, for backwards compatibility

        D. any other use fails

QEMU Documentation
        Document the above in the man page


OVMF:
        Can use the compatible opt/ovmf/ for now.

        Long term: take one of two paths:

        A. Move part of values passed to OVMF into QEMU codebase

        If it's commonly needed for guests to boot, we should provide
        sane defaults and a friendly interface, with
        range checking etc.

        or

        B. Gradually transition OVMF to look up paths in usr/org.uefi/: if
        nothing is found there, look up in opt/ovmf/ for backwards
        compatibility.

        This makes sense if the feature is esoteric and very rarely
        used.


-- 
MST