qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gabriel L. Somlo
Subject: Re: [Qemu-devel] [PATCH v2] vl.c: disallow command line fw cfg without opt/
Date: Wed, 16 Mar 2016 14:15:41 -0400
User-agent: Mutt/1.5.24 (2015-08-30)

On Wed, 16 Mar 2016 at 18:50:57 +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 16, 2016 at 05:29:45PM +0100, Markus Armbruster wrote:
> > "Michael S. Tsirkin" <address@hidden> 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 <address@hidden>
> > 
> > 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.

As the author of the feature, I feel I should jump back in and clarify:

It's a way to pass arbitrary blobs to any type of guest, with two
important properties: 1. asynchronous, and 2. out-of-band. When I
started looking, all existing methods involved either having the host
start polling for the guest to bring up qga and be ready to accept an
out-of-band connection (i.e., *not* asynchronous), or have the guest
mount some special cdrom or floppy image prepared by the host (i.e.,
*not* out of band).

fw_cfg is both asynchronous and out-of-band, so it appeared to be the
perfect choice.

> 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.

Enforcing the "opt/" prefix was clearly on the table when I submitted
the feature (and totally acceptable for my own needs). At the time, however,
most of the advice I received on the list was to leave it as a warning
only (i.e., "mechanism, not policy"), especially since other respondents
expressed interest in passing in non-"/opt" blobs for easier development
and debugging of alternative firmware (such as OVMF, iirc).

Having a mis-use of this feature become "institutionalized" over time was
seen as a low/negligible risk at the time. Do we have any new reasons
to worry about it ?

Thanks much,
--Gabriel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]