Re: [Qemu-devel] RFC: guest-side retrieval of fw_cfg file

[Laszlo Ersek <lersek@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