Re: [Qemu-devel] [RFC] Writeable files in fw_cfg

[David Woodhouse]

On Sun, 2013-01-27 at 10:29 -0600, Anthony Liguori wrote:
> David Woodhouse <address@hidden> writes:
> 
> > For OVMF we really want to have a way to store non-volatile variables,
> > other than the dirty hack that currently puts them on a file in the EFI
> > system partition.
> >
> > It looks like we've supported writing to fw_cfg items fairly much since
> > they were introduced, but we've never actually made use of that.
> >
> > This WIP patch kills the existing fw_cfg_add_callback() because I can't
> > see how it would ever be useful, and it doesn't seem to have been used
> > for years, if ever. And adds something slightly more useful.
> >
> > Other then the obvious bits that need finishing, any objections?
> 
> The main issue is malicious guests.  The administrator has to be aware
> of and in control of how much disk space the guest can use.  The
> secondary issue is how to tie into the block layer so things like live
> migration work.
> 
> This is why "use a flash device" is an attractive answer here because it
> gives a fixed sized storage pool that's configurable by the
> administrator. 

That part is fixable simply by imposing a maximum size, surely?

> Since it's backed by a block device, it supports all of
> the features needed for non-volatile storage (snapshotting, live copy,
> etc.).
> 
> The only real downside is that it's opaque to the host.  If it's
> desirable to have something that's visible to the host, then I think we
> would still need to make use of BlockDriverState as the means to make it
> non-volatile.

I don't really care about it being visible to the host. The important
thing is that it's easily usable from the guest firmware at runtime, and
not on a device that the OS might be trying to use. Their current trick
is a file on the EFI system partition, which is definitely *not*
acceptable. It doesn't work after the OS has booted, so even basic tasks
like "install an OS and hope the installer can set the boot variables to
boot into it" are broken.

For exposing it to the guest, writeable fw_cfg definitely seems like the
most attractive answer. I'll look at backing it with BlockDriverState. I
don't even think we need a file system on it; it can just be a
fixed-size device exposed as-is, surely?

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature