[libvirt PATCH 08/12] tools: load CPU count and CPU SKU from libvirt
Daniel P. Berrangé
berrange at redhat.com
Tue Oct 18 09:19:22 UTC 2022
On Sun, Oct 16, 2022 at 03:09:43PM -0400, Cole Robinson wrote:
> On 10/7/22 7:43 AM, Daniel P. Berrangé wrote:
> > When validating a SEV-ES guest, we need to know the CPU count and VMSA
> > state. We can get the CPU count directly from libvirt's guest info. The
> > VMSA state can be constructed automatically if we query the CPU SKU from
> > host capabilities XML. Neither of these is secure, however, so this
> > behaviour is restricted.
> >
> > Signed-off-by: Daniel P. Berrangé <berrange at redhat.com>
> > ---
> > docs/manpages/virt-qemu-sev-validate.rst | 4 ----
> > tools/virt-qemu-sev-validate.py | 23 +++++++++++++++++++++++
> > 2 files changed, 23 insertions(+), 4 deletions(-)
> >
> > diff --git a/docs/manpages/virt-qemu-sev-validate.rst b/docs/manpages/virt-qemu-sev-validate.rst
> > index 7ba7323e13..fcc13d68c8 100644
> > --- a/docs/manpages/virt-qemu-sev-validate.rst
> > +++ b/docs/manpages/virt-qemu-sev-validate.rst
> > @@ -356,7 +356,6 @@ Validate the measurement of a SEV-ES SMP guest booting from disk:
> >
> > # virt-dom-sev-validate \
> > --insecure \
> > - --num-cpus 2 \
> > --vmsa-cpu0 vmsa0.bin \
> > --vmsa-cpu1 vmsa1.bin \
> > --tk this-guest-tk.bin \
> > @@ -369,9 +368,6 @@ automatically constructed VMSA:
> >
> > # virt-dom-sev-validate \
> > --insecure \
> > - --cpu-family 23 \
> > - --cpu-model 49 \
> > - --cpu-stepping 0 \
> > --tk this-guest-tk.bin \
> > --domain fedora34x86_64
> >
> > diff --git a/tools/virt-qemu-sev-validate.py b/tools/virt-qemu-sev-validate.py
> > index 2505aff07f..5da1353e60 100755
> > --- a/tools/virt-qemu-sev-validate.py
> > +++ b/tools/virt-qemu-sev-validate.py
> > @@ -869,6 +869,14 @@ class LibvirtConfidentialVM(ConfidentialVM):
> > if self.policy is None:
> > self.policy = sevinfo["sev-policy"]
> >
> > + if self.is_sev_es() and self.num_cpus is None:
> > + if secure:
> > + raise InsecureUsageException(
> > + "Using CPU count from guest is not secure")
> > +
> > + info = self.dom.info()
> > + self.num_cpus = info[3]
> > +
> > if self.firmware is None:
> > if remote:
> > raise UnsupportedUsageException(
> > @@ -914,6 +922,21 @@ class LibvirtConfidentialVM(ConfidentialVM):
> > "Using cmdline string from XML is not secure")
> > self.kernel_table.load_cmdline(cmdlinenodes[0].text)
> >
> > + capsxml = self.conn.getCapabilities()
> > + capsdoc = etree.fromstring(capsxml)
> > +
> > + if self.is_sev_es() and self.vmsa_cpu0 is None:
> > + if secure:
> > + raise InsecureUsageException(
> > + "Using CPU SKU from capabilities is not secure")
> > +
> > + sig = capsdoc.xpath("/capabilities/host/cpu/signature")
> > + if len(sig) == 1:
>
> If this is missing, I'd make it fatal, libvirtd isn't new enough. Could
> happen if talking to a remote machine (or testing the script while f36
> fedora libvirtd is running, which I did :) ) . It's going to fail later
> anyways.
Makes sense.
With 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 :|
More information about the libvir-list
mailing list