Re: Add support for enabling Secure Encrypted Virtualization in the GUI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 4/19/22 1:21 PM, Daniel P. Berrangé wrote:
> On Tue, Apr 19, 2022 at 12:05:29PM -0400, Cole Robinson wrote:
>> On 4/4/22 11:49 AM, Charles Arnold wrote:
>>> On 4/4/22 6:50 AM, Daniel P. Berrangé wrote:
>>>> On Fri, Apr 01, 2022 at 12:13:17PM -0600, Charles Arnold wrote:
>>>>>  From d700e8cee7cd525c0022b5a9a440f64c4ab149f0 Mon Sep 17 00:00:00 2001
>>>>> From: Charles Arnold <carnold@xxxxxxxx>
>>>>> Date: Fri, 1 Apr 2022 12:01:21 -0600
>>>>> Subject: [PATCH 1/1] Add support for enabling Secure Encrypted
>>>>> Virtualization
>>>>>   in the GUI
>>>>> Add an "Enable Launch Security" checkbox on the Details memory tab.
>>>>> Do the minimal configuration required for libvirt to enable this feature
>>>>> on compatible hardware.
>>>> Don't we need to turn on the 'iommu' option for all virtio devices
>>>> too, and disable PXE on any NICs ?
>>> I used to enumerate through the virtio devices in an old version of this
>>> patch
>>> for virt-manager and enable iommu but it really wasn't reasonable for
>>> virt-manager to track which virtio devices needed iommu enabled.
>>> Additionally,
>>> libvirt will sometimes add a device when a VM is created. This patch
>>> leans on libvirt to do the right thing when sev is enabled similar to what
>>> happens when launch security is specified on the virt-install command line.
>> Yeah, I would still like to see libvirt do this unless there's a good
>> reason why it can't. From my July 2020 mail
>>> if sev
>>> launchSecurity _requires_ every virtio device to have iommu='on' then
>>> libvirt should be setting that itself. It doesn't need to hardcode it
>>> into the XML, it can set it at VM startup time. If the user set an
>>> explicit value in the XML then honor that but otherwise fill it in at
>>> runtime when it is required. Trying to deal with this in an app where we
>>> want to advertise turning the config off is basically an impossible
>>> problem to know if we are going to undo any explicit user config or not.
>> danpb does this sound reasonable? If so I can work on this.
> Something automagic sounds ok
>> Also, anyone know if TDX and SNP will require virtio iommu setting as well?
> I expect SNP will, but no idea about TDX.

So apparently qemu 6.0.0+ already does this for us:

Which is strange because some of my sev testing definitely failed with
an iommu sounding error in the guest kernel until I enabled iommu on
virtio-blk, but I can't reproduce now. Maybe I was using an older qemu,
I think the host was fedora 34 at the time

I'll send a patch for libvirt docs

I'll give this patch another look too


[Index of Archives]     [Linux Virtualization]     [KVM Development]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Video 4 Linux]

  Powered by Linux