[libvirt] [PATCH 4/4] qemu: caps: Format SEV platform data into qemuCaps cache
Erik Skultety
eskultet at redhat.com
Thu Aug 16 07:02:55 UTC 2018
On Wed, Aug 15, 2018 at 06:23:28PM +0200, Peter Krempa wrote:
> On Wed, Aug 15, 2018 at 17:02:08 +0200, Erik Skultety wrote:
> > Since we're not saving the platform-specific data into a cache, we're
> > not going to populate the structure, which in turn will cause a crash
> > upon calling virNodeGetSEVInfo because of a NULL pointer dereference.
> > Ultimately, we should start caching this data along with host-specific
> > capabilities like NUMA and SELinux stuff into a separate cache, but for
> > the time being, this is a semi-proper fix for a potential crash.
> >
> > Backtrace (requires libvirtd restart to load qemu caps from cache):
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1612009
> > Signed-off-by: Erik Skultety <eskultet at redhat.com>
> > ---
> > src/qemu/qemu_capabilities.c | 100 ++++++++++++++++++++++
> > tests/domaincapsschemadata/qemu_2.12.0.x86_64.xml | 5 +-
> > tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 6 ++
> > 3 files changed, 110 insertions(+), 1 deletion(-)
>
> ACK. I could not find any place where the data would be used by any code
> which would get it from the local copy from the @vm object, since that
> is not serialized in the domain status XML.
Thanks, note that this data is only supposed to serve the guest owner to
establish trust with the firmware in order to start a guest, therefore I
don't even expect this data to be used somewhere in the code ever. Yes, some of
the fields are re-used with launch-security data within the domain, but that is
a separate data structure not affected by the one this patch is about.
Erik
More information about the libvir-list
mailing list