From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36800) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agYkX-00053i-28 for qemu-devel@nongnu.org; Thu, 17 Mar 2016 10:18:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agYkT-0002aY-00 for qemu-devel@nongnu.org; Thu, 17 Mar 2016 10:18:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48615) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agYkS-0002Zy-R0 for qemu-devel@nongnu.org; Thu, 17 Mar 2016 10:18:00 -0400 Date: Thu, 17 Mar 2016 16:17:57 +0200 From: "Michael S. Tsirkin" Message-ID: <20160317160429-mutt-send-email-mst@redhat.com> References: <1458053080-29170-1-git-send-email-mst@redhat.com> <87fuvpv2jv.fsf@blackfin.pond.sub.org> <20160317143531-mutt-send-email-mst@redhat.com> <56EAB17A.1000400@redhat.com> <20160317153528-mutt-send-email-mst@redhat.com> <56EAB768.2000406@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56EAB768.2000406@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2] vl.c: disallow command line fw cfg without opt/ List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Laszlo Ersek , "Gabriel L. Somlo" , Gerd Hoffmann , Markus Armbruster , qemu-devel@nongnu.org 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