Re: [Xen-devel] [PATCH v3] libxl: QED disks support

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Cedric Bosdonnat writes ("Re: [PATCH v3] libxl: QED disks support"):
> On Mon, 2016-12-12 at 17:36 +0000, Ian Jackson wrote:
> > Specifically:
> > 
> >  * Does the qed format contain a builtin way to refer to other files,
> >    like qcow does ?  Paradoxically, if it does not, then it is a
> >    bigger risk for us: because then it might be reasonable for a user
> >    to feed an untrusted qed image file to xl, for use with a
> >    likewise-untrusted guest.  That means that image-handling bugs in
> >    qed would be security bugs which we might have to do security
> >    response for.
> 
> QED does support backing files, not sure if this is a good or bad news
> on the security topic.

It's bad news from on the general security front, because (if I
understand you correctly) it means that a malicious QED image can
cause qemu to access any file on the disk.

But it is good news from the point of view of the Xen Project Security
Team because it means that any situation where a malicious QED image
can cause qemu to malfunction cannot itself be a security bug :-).

> > So I would be happy with this patch if it came with a hunk editing
> > docs/misc/qemu-xen-security to say something like:
> > 
> >  +  - backing storage image format: raw, qcow, qcow2, vhd
> > 
> > (And we might want to drop vhd...)
> 
> I'm not the one deciding what is supported and what is not. Just tell
> me what I should add in the patch regarding that and I'll add it.

Sure.

Please add, for now, this line:

  - backing storage image format: raw, qcow, qcow2, vhd

to docs/misc/qemu-xen-security, after "- storage".

I am certainly open to being convinced that we should add qed to this
list, but I would like someone who understands it to make the case
(ie, explain why the risk is low).

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel