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" <m...@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 <m...@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.
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
