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

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

On Thu, Mar 17, 2016 at 02:55:52PM +0100, Paolo Bonzini wrote:
> 
> 
> On 17/03/2016 14:49, Michael S. Tsirkin wrote:
> >> On 17/03/2016 14:13, Michael S. Tsirkin wrote:
> >>>
> >>> QEMU command line:
> >>> 	A. -fw-cfg RFQDN/PATH prepends usr/. So users will not get conflicts
> >>> 	   with QEMU hardware
> >>
> >> Alternative: no need to prepend usr/, I think.
> > 
> > I personally dislike telling user "do X". I don't see a reason not to be
> > friendly and do X. The rare case where users do not want X can be
> > easily enabled.
> 
> I wouldn't include usr/ at all in the paths.  The RFQDN recommendation
> is enough to avoid clashes with etc/ and opt/.

Yes but then we need a blacklist. And usr/ is not visible to
users so I do not see a problem with it.


> >>> 	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
> >>
> >> Alternative: fail on:
> >>
> >> - a blacklist of etc/* files including etc/system-states,
> >> etc/smbios/smbios-tables, etc/smbios/smbios-anchor,
> >> etc/reserved-memory-end, etc/pvpanic-port, etc/e820, and possibly
> >> etc/boot-menu-wait
> > 
> > We can not predict the future. Future firmware will look for
> > files under etc/mst. Users using this firmware with
> > current QEMU will get a nasty surprise where it previously
> > worked.
> > 
> > Besides, it is way easier to maintain and understand a simple rule than
> > a blacklist.
> 
> The reason for the blacklist is that these are files owned by QEMU but
> traditionally under etc/.  The error can be simply "fw_cfg file %s is
> provided by QEMU".  If a file is added in the future that is owned by
> QEMU, it will be under org.qemu/* so the blacklist will not grow.


Yes, but a new prefix seems like a cleaner way.

> >> Likewise SeaBIOS would switch from etc/ to an org.seabios/ prefix (for
> >> stuff usable from both Coreboot and QEMU, e.g.
> >> org.seabios/bootsplash.bmp) or org.qemu/ (for stuff that is specific to
> >> QEMU).
> >>
> >> Files that could be moved from etc/ to org.qemu/ correspond to the ones
> >> that are blacklisted in (B), e.g. etc/system-states ->
> >> org.qemu/system-states.
> > 
> > I am not sure about moving things into usr/org.qemu.
> > These are system files, not user-provided ones.
> > But we can argue about future plans down the road.
> 
> Does it make more sense if it's just org.qemu, not usr/org.qemu?
> 
> Thanks,
> 
> Paolo

I am not sure, let's discuss after 2.6.

-- 
MST