On Thu, Nov 10, 2011 at 10:57 AM, Markus Armbruster <armbru@xxxxxxxxxx> wrote: > Sasha Levin <levinsasha928@xxxxxxxxx> writes: > >> On Thu, Nov 10, 2011 at 9:57 AM, Markus Armbruster <armbru@xxxxxxxxxx> wrote: > [...] >>> Start with a clean read/write raw image. Probing declares it raw. >>> Guest writes QCOW signature to it, with a backing file of its choice. >>> >>> Restart with the same image. Probing declares it QCOW2. Guest can read >>> the backing file. Oops. >> >> Thats an excellent scenario why you'd want to have 'Secure KVM' with >> seccomp filters :) > > Yup. > > For what it's worth, sVirt (use SELinux to secure virtualization) > mitigates the problem. Doesn't mean we couldn't use "Secure KVM". How does it do it do that? You have a hypervisor trying to read arbitrary files on the host FS, no? >> I'm actually not sure why KVM tool got QCOW support in the first >> place. You can have anything QCOW provides if you use btrfs (among >> several other FSs). > > Maybe it's just me, but isn't it weird to have a filesystem (QCOW2) > sitting in the kernel sources that you can't mount(2)? > It's not really a filesystem, it's a disk image :) When we did the initial QCOW patches this issue (in some form) came up. The main concern there was that we shouldn't be duplicating QCOW code and instead be using a 'libdiskimage' or something like that. Since nothing like that existed at that time, and splitting it out of QEMU wasn't trivial, we ended up agreeing on doing a rewrite of the code. The point you raised could be solved if we do end up having a usermode lib which can handle disk images. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
