Open Stack

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.

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

>> 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.
>
Thanks for the explanation! Now I understand libvirt policy better and
it looks straight-forward to add the "bypass-share-memory" migration
capability to libvirt when the qemu community accepts the patch. So
the two points I listed are not hard blockers for libvirt support in
kata.

Cheers,
Tao