From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYqm7-00087M-Fs for qemu-devel@nongnu.org; Fri, 20 Mar 2015 02:51:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYqm4-0006Uf-7R for qemu-devel@nongnu.org; Fri, 20 Mar 2015 02:51:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYqm3-0006US-Vm for qemu-devel@nongnu.org; Fri, 20 Mar 2015 02:51:16 -0400 Message-ID: <550BC35A.3040606@redhat.com> Date: Fri, 20 Mar 2015 07:51:06 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1426724311-9343-1-git-send-email-somlo@cmu.edu> <1426724311-9343-5-git-send-email-somlo@cmu.edu> In-Reply-To: <1426724311-9343-5-git-send-email-somlo@cmu.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 4/5] fw_cfg: prohibit insertion of duplicate fw_cfg file names List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: matt.fleming@intel.com, mdroth@linux.vnet.ibm.com, rjones@redhat.com, jordan.l.justen@intel.com, qemu-devel@nongnu.org, gleb@cloudius-systems.com, gsomlo@gmail.com, kraxel@redhat.com, pbonzini@redhat.com, armbru@redhat.com On 03/19/15 01:18, Gabriel L. Somlo wrote: > Exit with an error (instead of simply logging a trace event) > whenever the same fw_cfg file name is added multiple times via > one of the fw_cfg_add_file[_callback]() host-side API calls. > > Signed-off-by: Gabriel Somlo > --- > hw/nvram/fw_cfg.c | 11 ++++++----- > trace-events | 1 - > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c > index 659de4c..a5fd512 100644 > --- a/hw/nvram/fw_cfg.c > +++ b/hw/nvram/fw_cfg.c > @@ -505,18 +505,19 @@ void fw_cfg_add_file_callback(FWCfgState *s, const char *filename, > index = be32_to_cpu(s->files->count); > assert(index < FW_CFG_FILE_SLOTS); > > - fw_cfg_add_bytes_read_callback(s, FW_CFG_FILE_FIRST + index, > - callback, callback_opaque, data, len); > - > pstrcpy(s->files->f[index].name, sizeof(s->files->f[index].name), > filename); > for (i = 0; i < index; i++) { > if (strcmp(s->files->f[index].name, s->files->f[i].name) == 0) { > - trace_fw_cfg_add_file_dupe(s, s->files->f[index].name); > - return; > + error_report("duplicate fw_cfg file name: %s", > + s->files->f[index].name); > + exit(1); > } > } > > + fw_cfg_add_bytes_read_callback(s, FW_CFG_FILE_FIRST + index, > + callback, callback_opaque, data, len); > + > s->files->f[index].size = cpu_to_be32(len); > s->files->f[index].select = cpu_to_be16(FW_CFG_FILE_FIRST + index); > trace_fw_cfg_add_file(s, index, s->files->f[index].name, len); > diff --git a/trace-events b/trace-events > index 1275b70..a340c5a 100644 > --- a/trace-events > +++ b/trace-events > @@ -195,7 +195,6 @@ ecc_diag_mem_readb(uint64_t addr, uint32_t ret) "Read diagnostic %"PRId64"= %02x > # hw/nvram/fw_cfg.c > fw_cfg_select(void *s, uint16_t key, int ret) "%p key %d = %d" > fw_cfg_read(void *s, uint8_t ret) "%p = %d" > -fw_cfg_add_file_dupe(void *s, char *name) "%p %s" > fw_cfg_add_file(void *s, int index, char *name, size_t len) "%p #%d: %s (%zd bytes)" > > # hw/block/hd-geometry.c > Here's an idea I had this morning. This series gives equal rank to fw_cfg file names that originate internally and those that come from the user, via the command line. That means that whenever qemu developers want to introduce a new fw_cfg file, they can never be sure that the new name will not conflict with something a user has already been passing in via the command line, for whatever purposes. (Because, well, that's the goal of this patchset, to empower the user to pass in fw_cfg files independently of qemu developers.) This looks brittle. How about: (a) advising users in the docs txt *and in the manual* to use some kind of fw_cfg file name prefix, like "usr/" or "opt/", and then steering clear of such prefixes in qemu, as far as developers are concerned. Or, (b) automatically prepending "opt/" or "usr/" to all fw_cfg file names that come via -fw_cfg (equiv. via [fw_cfg] in the config file), and, for developers, steering clear of those prefixes in qemu's source. The C standard and the POSIX standard define lists of identifier prefixes (well, patterns) that are reserved for various uses. If a program violates that, it might not compile on some platform, or with the next release of the compiler on the same platform etc. I think we should posit something like this. Personally I vote (a). Document it, but don't enforce it. (Assuming that a user-specified fw_cfg file gains traction, and becomes popular to the point that qemu wants to expose it itself, then qemu can just generate the same file with (eg.) an "etc/" prefix. And then firmware (or other guest code) can start looking for the file under both prefixes, and give priority to... well, that's another policy question; but we're talking mechanism thus far. :)) Thoughts about (a) vs. (b) vs. neither? Thanks Laszlo