Re: [Qemu-devel] live snapshot wiki updated

[Jes Sorensen]

On 07/19/11 18:46, Daniel P. Berrange wrote:
> On Tue, Jul 19, 2011 at 04:14:27PM +0100, Stefan Hajnoczi wrote:
>> For fd-passing perhaps we have an opportunity to use a callback
>> mechanism (QEMU request: filename -> libvirt response: fd) and do all
>> the image format parsing in QEMU.
> 
> The reason why libvirt does the parsing of file headers to determine
> backing files is to maintain the trust boundary. Everything run from
> the exec() of QEMU onwards is considered untrusted code. So having
> QEMU parsing the file headers & passing back open() requests to libvirt
> is breaking the trust boundary.

Pardon, but I fail to see the issue here. If QEMU passes a filename back
to libvirt, libvirt still gets to make the decision whether or not it is
legitimate for QEMU to get that file descriptor or not. It doesn't
change anything wrt who actually opens the file, hence the 'trust' is
unchanged.

> NB, i'm not happy about libvirt having to have knowledge of file format
> headers, but we needed something more efficient & reliable than invoking
> qemu-img info & parsing the output. Ideally QEMU (or something else)
> would provide a library libblockformat.so with stable APIs for at least
> reading metadata about image formats. If it had APIs for image creation,
> etc too that would be a bonus, but we're more or less ok spawning qemu-img
> for those cases currently.

Even having a library for libvirt to link against is suboptimal here.
Two processes shouldn't be fighting over the internals of metadata, the
ownership of the metadata belongs solely with QEMU. In addition you have
the constant issue of dependencies there, hence if QEMU is updated and
it provides a newer block format library, it may prevent libvirt from
running forcing an update of libvirt as well. That is not acceptable for
development.

Cheers,
Jes