Open Stack

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

> 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.

> IIUC, libvirt is set to be hypervisor agnostic so I'm not sure if
> these qemu specific features can get in there. However, if we only
> consider basic usage of Kata, libvirt-go should work w/o issues.

Hypervisor agnostic doesn't imply that we must stick to the lowest common
denominator. It simply means that if we have a concept implemented for one
hypervisor, we'll aim to implement it with the same APIs & configuration
syntax when we add to for a second hypervisor. A large portion of the
functionality in libvirt's QEMU driver is found only in QEMU and it is
perfectly ok that no other hypervisor will ever support it.

As a failsafe fallback, we do provide a way to pass arbitrary command line
arguments to QEMU, however, we tend to discourage its usage, as we prefer
to officially support any features that mgmt apps have a need for.

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 :|