Re: [libvirt] [Qemu-devel] live snapshot wiki updated

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.