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

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Mar 16, 2016 at 05:29:45PM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > Allowing arbitary file names on command line is setting us up for
> > failure: future guests will look for a specific QEMU-specified name and
> > will get confused finding a user file there.
> >
> > We do warn but people are conditioned to ignore warnings by now,
> > so at best that will help users debug problem, not avoid it.
> >
> > Disable this by default, so distros don't get to deal with it,
> > but leave an option for developers to configure this in,
> > with scary warnings so people only do it if they know
> > what they are doing.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
> I'm having a hard time to see the point.

Frankly, I am having a hard time to see the point of exposing fw cfg to
users at all.  It was designed as an internal interface between QEMU PC
hardware and firmware.  As a PC maintainer, I do not like it that users
get to poke at PC internals.

So it is yet another way to pass binaries to Linux guests.  Don't we
have enough of these?  But Gerd likes it for some reason, and merged it.
OK.

But please find a way to make sure it does not conflict with its current
usage in PC.  Asking that all files have an "opt/" prefix is one way
but only if it is enforced.

This is polluting global namespace.


> There are *countless* ways
> users can mess up their guests from the command line or the monitor.
> Yet we get so hung up on this rather obscure one to attempt to catch
> some (but far from all) misuses that may trigger it, and then, because
> that interferes with debugging, add a *configure* option to suppress it
> again.

In fact, how does it interfere with debugging? debugging what? by whom?
I think we should figure that out instead of carrying more opaque binaries
around.

E.g. if people want to replace built-in ACPI tables, say so,
and we'll look at sane ways to do this that do not
involve poking at acpi internals.


> Misuse of -fw_cfg isn't even a molehill, but adding a configure option
> *is* making a mountain out of it.
> 

Yea. That configure hack is an attempt at a compromise.

But maybe the real fix is to rip fw cfg tweaking from
command line out completely, at least for 2.6.

> If you know what "fw cfg" is (few users do), and know how to put the
> user-specified fw cfg files feature to use (even fewer), you're damn
> well expected to know to stick to /opt or else.  We already print a
> reminder.  That's as far as I'd want us to go.

What happens is that inevitable someone finds a bug, and then
finds a work around, and blog posts spring up advertising
the fix, and you can never go back again.

Or a tool uses this, no one notices for years,
and after an update someone gets to debug it
until finally the warning is noticed.
Or more likely it all ends up in the launchpad/bugzilla,
with yet another useful tool broken for no good reason.


-- 
MST