From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53411) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHJDX-0000bM-RU for qemu-devel@nongnu.org; Mon, 20 Jul 2015 18:07:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZHJDR-00039q-1M for qemu-devel@nongnu.org; Mon, 20 Jul 2015 18:07:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59688) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHJDQ-00039Y-TE for qemu-devel@nongnu.org; Mon, 20 Jul 2015 18:07:16 -0400 References: <20150713200936.GK1606@HEDWIG.INI.CMU.EDU> <1436961645.25906.20.camel@intel.com> <20150720211935.GC1606@HEDWIG.INI.CMU.EDU> From: Laszlo Ersek Message-ID: <55AD710C.9040203@redhat.com> Date: Tue, 21 Jul 2015 00:07:08 +0200 MIME-Version: 1.0 In-Reply-To: <20150720211935.GC1606@HEDWIG.INI.CMU.EDU> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] RFC: guest-side retrieval of fw_cfg file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" , Matt Fleming Cc: gleb@cloudius-systems.com, rjones@redhat.com, jordan.l.justen@intel.com, mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org, kraxel@redhat.com, pbonzini@redhat.com On 07/20/15 23:19, Gabriel L. Somlo wrote: > The code to build nested ksets (represending sub-sub-directories of > /sys/firmware/fw_cfg/...) and cleaning them up on exit doesn't promise > to be *too* horrible or bulky, but as I was getting ready to start > writing it, I realized that, in theory, nothing is to stop the fw_cfg > device from having files named e.g. > > "etc/foo" > > and > > "etc/foo/bar" > > That doesn't happen right now on the qemu side, but it could in > theory, and I have no idea how I'd deal with the file/directory > duality of "foo" in this situation, short of refusing to load the > module, or leaving out one fw_cfg file or the other. Unless there's > a way around this, I think it's safer to either stick with the default > 's/\//!/g' scheme of the kobject library, or implement something like > systemd's string escaping scheme that's been suggested earlier in this > thread... > > Or maybe leaving out the occasional poorly-named file is still better > than giving up the ability to run find on the fw_cfg sysfs folder ? I assume once you have "etc/foo" in place (ie. as part of the filesystem), where "foo" is not a directory, then the attempt to create "etc/foo/bar" will cause whatever kernel API is in use to return ENOTDIR. Since you are checking return values anyway :), just barf a warning into syslog, and either skip the fw_cfg file, or abort module loading completely, as you see fit. This is a user error -- you should punish the user for it, not yourself. :) ... I just love "find", sorry. :) Anyway, I don't envision myself as a user of this feature any time soon, so please feel free to ignore me. Thanks Laszlo