Open Stack

On Tue, Jul 17, 2018 at 05:39:36PM +0800, Tao Peng wrote:
> On Tue, Jul 17, 2018 at 5:05 PM, Daniel P. Berrangé <berrange at redhat.com> wrote:
> > On Tue, Jul 17, 2018 at 10:50:35AM +0800, Tao Peng wrote:
> >> On Tue, Jul 17, 2018 at 6:32 AM, Boeuf, Sebastien
> >> <sebastien.boeuf at intel.com> wrote:
> >> > Hi Stefan,
> >> >
> >> > Thanks for bringing up this topic.
> >> >
> >> > About better isolation, we have 2 issues opened here:
> >> > https://github.com/kata-containers/runtime/issues/344
> >> > https://github.com/kata-containers/runtime/issues/345
> >> > They're about cgroups and namespaces for the qemu process itself. You've mentioned it's not worth isolating the process through namespaces but I think it is since the kernel running inside the VM is very likely to be different from the kernel running on the host, meaning the exploit might be harder on the host itself even if it happened inside the guest.
> >> >
> >> > Now, I agree that running the VM as root is also a real breach regarding security and we also have an issue to address this concern here: https://github.com/kata-containers/runtime/issues/389
> >> > I think you summarized the blockers pretty well right now. If qemu is not root, we have some issues accessing the files on the host through 9p, but you also seem to provide a solution here and it'd be great if you could comment on the Github issue.
> >> > One small thing that needs to happen too is to make sure we run kata-runtime with a user that at least can have access to /dev/kvm, but other than that, nothing else I can think of.
> >> >
> >> > Last thing, about libvirt-go, is there all the support needed by Kata (hotplug of a bunch of different device types) ?
> >> >
> >> libvirt-go does have that and runv is using libvirt-go
> >> (https://github.com/hyperhq/runv/tree/master/hypervisor/libvirt) for a
> >> long time. Last I checked, there are still a few missing pieces of
> >> libvirt though:
> >> 1. vsock -- runv only supports vsock through the qemu hypervisor
> >
> > Libvirt does support vsock now
> >
> Sorry I meant to say libvirt-go -- I only checked libvirt-go -- and
> vsock does not show up there yet,
> https://github.com/libvirt/libvirt-go/search?q=vsock&unscoped_q=vsock.
> Now that libvirt does support vsock, we only need to add the missing
> piece to libvirt-go.

There is nothing special needed by libvirt-go - it is simply an API binding
to libvirt and there are no custom APIs involved in vsock - it was simply a
new part of the XML schema which doesn't involve API changes.

There is a separate libvirt-go-xml package which maps the XML schemas into
Go structs, and that does have support for vsock

> 
> >> 2. vm templating -- runv works around it by using a customized qemu wrapper
> >
> > I'm not sure what you're meaning by vm templating here ? As a conceptual design
> > policy, libvirt tends to focus on providing the mechanism, and leaves policy
> > upto the mgmt application to decide. What most people describe as "templating"
> > is a usage a policy decision around disk images. Libvirt has APIs for managing
> > and manipulating storage volumes, which can be used to implement templating
> > concepts. Offhand I can't think of a reason why it would require use of a
> > custom qemu wrapper.
> >
> This one is still WiP to get it merged by qemu upstream -- we want to
> allow qemu to do migration without copying shared memory. Basically a
> new migration capability "bypass-share-memory" is added before qemu
> starts migration. We use this capability to implement so-called vm
> templating feature in both runv and kata.

Ok, as & when QEMU merges that, it is something we could expose via
libvirt in some manner.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|