[libvirt PATCH 0/5] Support AMD SEV firmware with -bios instead of pflash

Daniel P. Berrangé posted 5 patches 1 week, 3 days ago
Test syntax-check failed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/libvirt tags/patchew/20220114190715.128033-1-berrange@redhat.com
docs/formatdomain.rst                         | 24 +++++-
src/conf/domain_conf.c                        |  8 +-
src/qemu/qemu_firmware.c                      | 25 +++++++
.../usr/share/qemu/firmware/62-ovmf-sev.json  | 27 +++++++
tests/qemufirmwaretest.c                      |  4 +-
.../os-firmware-efi-sev.x86_64-6.0.0.args     | 43 +++++++++++
.../qemuxml2argvdata/os-firmware-efi-sev.xml  | 74 +++++++++++++++++++
tests/qemuxml2argvtest.c                      |  1 +
8 files changed, 197 insertions(+), 9 deletions(-)
create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/62-ovmf-sev.json
create mode 100644 tests/qemuxml2argvdata/os-firmware-efi-sev.x86_64-6.0.0.args
create mode 100644 tests/qemuxml2argvdata/os-firmware-efi-sev.xml

[libvirt PATCH 0/5] Support AMD SEV firmware with -bios instead of pflash

Posted by Daniel P. Berrangé 1 week, 3 days ago
The firmware distros have given people for use with AMD SEV thus far has
just been one of the regular OVMF builds. This is sufficient for booting
a guest with SEV enabled, but is useless if you want to actually
validate the guest measurement. The NVRAM store is untrustworthy since
it is not included in the measurement. We need to supply a dedicated
build of OVMF without NVRAM support enabled. While it is possible to
use with pflash, we then get a problem with firmware selection as there
is no easy way to make it prefer the firmware without NVRAM. Also the
firmware descriptor treats the NVRAM template as a mandatory field
today and libvirt enforces that.

While we could invent a new feature flag 'sev-stateless' for the
firmware descriptors, and/or make the NVRAM template path optional,
it makes more sense if the firmware descriptor just reports the SEV
firmware as type=memory instead of type=flash.

If the libvirt XML parses the <loader type='rom'/> attribute when
doing firmware auto-selection, we trivially enable a way for a mgmt
app to indicate that it wants the SEV firmware without NVRAM
support.

This series does all the plumbing we need.

The only minor issue is that QEMU support for -bios with SEV enabled
firmware is broken:

  https://lists.gnu.org/archive/html/qemu-devel/2022-01/msg02957.html

Daniel P. Berrangé (5):
  docs: explain that some UEFI images can use 'rom' instead of 'pflash'
  conf: parse loader 'type' even when doing firmware auto select
  qemu: filter firmware selection based on loader type
  tests: add firmware descriptor for SEV dedicated build
  tests: add a test for selecting a firmware without NVRAM

 docs/formatdomain.rst                         | 24 +++++-
 src/conf/domain_conf.c                        |  8 +-
 src/qemu/qemu_firmware.c                      | 25 +++++++
 .../usr/share/qemu/firmware/62-ovmf-sev.json  | 27 +++++++
 tests/qemufirmwaretest.c                      |  4 +-
 .../os-firmware-efi-sev.x86_64-6.0.0.args     | 43 +++++++++++
 .../qemuxml2argvdata/os-firmware-efi-sev.xml  | 74 +++++++++++++++++++
 tests/qemuxml2argvtest.c                      |  1 +
 8 files changed, 197 insertions(+), 9 deletions(-)
 create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/62-ovmf-sev.json
 create mode 100644 tests/qemuxml2argvdata/os-firmware-efi-sev.x86_64-6.0.0.args
 create mode 100644 tests/qemuxml2argvdata/os-firmware-efi-sev.xml

-- 
2.33.1


Re: [libvirt PATCH 0/5] Support AMD SEV firmware with -bios instead of pflash

Posted by Daniel P. Berrangé 3 days, 14 hours ago
On Fri, Jan 14, 2022 at 07:07:10PM +0000, Daniel P. Berrangé wrote:
> The firmware distros have given people for use with AMD SEV thus far has
> just been one of the regular OVMF builds. This is sufficient for booting
> a guest with SEV enabled, but is useless if you want to actually
> validate the guest measurement. The NVRAM store is untrustworthy since
> it is not included in the measurement. We need to supply a dedicated
> build of OVMF without NVRAM support enabled. While it is possible to
> use with pflash, we then get a problem with firmware selection as there
> is no easy way to make it prefer the firmware without NVRAM. Also the
> firmware descriptor treats the NVRAM template as a mandatory field
> today and libvirt enforces that.
> 
> While we could invent a new feature flag 'sev-stateless' for the
> firmware descriptors, and/or make the NVRAM template path optional,
> it makes more sense if the firmware descriptor just reports the SEV
> firmware as type=memory instead of type=flash.
> 
> If the libvirt XML parses the <loader type='rom'/> attribute when
> doing firmware auto-selection, we trivially enable a way for a mgmt
> app to indicate that it wants the SEV firmware without NVRAM
> support.
> 
> This series does all the plumbing we need.
> 
> The only minor issue is that QEMU support for -bios with SEV enabled
> firmware is broken:
> 
>   https://lists.gnu.org/archive/html/qemu-devel/2022-01/msg02957.html

Well turns out the concept is unfixably broken on the QEMU side
with SEV enabled UEFI firmware. So I'm going to ditch the first
docs patch.

I figure it is still possibly useful to be able to controla
auto-firmware selection based on 'type', even if it doesn't
help my sev use case, so might as well leave keep that now
I've implemented it.

> 
> Daniel P. Berrangé (5):
>   docs: explain that some UEFI images can use 'rom' instead of 'pflash'
>   conf: parse loader 'type' even when doing firmware auto select
>   qemu: filter firmware selection based on loader type
>   tests: add firmware descriptor for SEV dedicated build
>   tests: add a test for selecting a firmware without NVRAM
> 
>  docs/formatdomain.rst                         | 24 +++++-
>  src/conf/domain_conf.c                        |  8 +-
>  src/qemu/qemu_firmware.c                      | 25 +++++++
>  .../usr/share/qemu/firmware/62-ovmf-sev.json  | 27 +++++++
>  tests/qemufirmwaretest.c                      |  4 +-
>  .../os-firmware-efi-sev.x86_64-6.0.0.args     | 43 +++++++++++
>  .../qemuxml2argvdata/os-firmware-efi-sev.xml  | 74 +++++++++++++++++++
>  tests/qemuxml2argvtest.c                      |  1 +
>  8 files changed, 197 insertions(+), 9 deletions(-)
>  create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/62-ovmf-sev.json
>  create mode 100644 tests/qemuxml2argvdata/os-firmware-efi-sev.x86_64-6.0.0.args
>  create mode 100644 tests/qemuxml2argvdata/os-firmware-efi-sev.xml
> 
> -- 
> 2.33.1
> 
> 

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

Re: [libvirt PATCH 0/5] Support AMD SEV firmware with -bios instead of pflash

Posted by Erik Skultety 3 days, 14 hours ago
On Fri, Jan 21, 2022 at 02:16:14PM +0000, Daniel P. Berrangé wrote:
> On Fri, Jan 14, 2022 at 07:07:10PM +0000, Daniel P. Berrangé wrote:
> > The firmware distros have given people for use with AMD SEV thus far has
> > just been one of the regular OVMF builds. This is sufficient for booting
> > a guest with SEV enabled, but is useless if you want to actually
> > validate the guest measurement. The NVRAM store is untrustworthy since
> > it is not included in the measurement. We need to supply a dedicated
> > build of OVMF without NVRAM support enabled. While it is possible to
> > use with pflash, we then get a problem with firmware selection as there
> > is no easy way to make it prefer the firmware without NVRAM. Also the
> > firmware descriptor treats the NVRAM template as a mandatory field
> > today and libvirt enforces that.
> > 
> > While we could invent a new feature flag 'sev-stateless' for the
> > firmware descriptors, and/or make the NVRAM template path optional,
> > it makes more sense if the firmware descriptor just reports the SEV
> > firmware as type=memory instead of type=flash.
> > 
> > If the libvirt XML parses the <loader type='rom'/> attribute when
> > doing firmware auto-selection, we trivially enable a way for a mgmt
> > app to indicate that it wants the SEV firmware without NVRAM
> > support.
> > 
> > This series does all the plumbing we need.
> > 
> > The only minor issue is that QEMU support for -bios with SEV enabled
> > firmware is broken:
> > 
> >   https://lists.gnu.org/archive/html/qemu-devel/2022-01/msg02957.html
> 
> Well turns out the concept is unfixably broken on the QEMU side
> with SEV enabled UEFI firmware. So I'm going to ditch the first
> docs patch.
> 
> I figure it is still possibly useful to be able to controla
> auto-firmware selection based on 'type', even if it doesn't
> help my sev use case, so might as well leave keep that now
> I've implemented it.

In any case, in context of patch 2/5, shouldn't autoselect haven been left
untouched and instead pick the type automatically, say in
qemuValidateDomainDefBoot or similar depending on whether the domain has
LaunchSecurity SEV defined in the XML?

Erik

Re: [libvirt PATCH 0/5] Support AMD SEV firmware with -bios instead of pflash

Posted by Daniel P. Berrangé 3 days, 14 hours ago
On Fri, Jan 21, 2022 at 03:40:23PM +0100, Erik Skultety wrote:
> On Fri, Jan 21, 2022 at 02:16:14PM +0000, Daniel P. Berrangé wrote:
> > On Fri, Jan 14, 2022 at 07:07:10PM +0000, Daniel P. Berrangé wrote:
> > > The firmware distros have given people for use with AMD SEV thus far has
> > > just been one of the regular OVMF builds. This is sufficient for booting
> > > a guest with SEV enabled, but is useless if you want to actually
> > > validate the guest measurement. The NVRAM store is untrustworthy since
> > > it is not included in the measurement. We need to supply a dedicated
> > > build of OVMF without NVRAM support enabled. While it is possible to
> > > use with pflash, we then get a problem with firmware selection as there
> > > is no easy way to make it prefer the firmware without NVRAM. Also the
> > > firmware descriptor treats the NVRAM template as a mandatory field
> > > today and libvirt enforces that.
> > > 
> > > While we could invent a new feature flag 'sev-stateless' for the
> > > firmware descriptors, and/or make the NVRAM template path optional,
> > > it makes more sense if the firmware descriptor just reports the SEV
> > > firmware as type=memory instead of type=flash.
> > > 
> > > If the libvirt XML parses the <loader type='rom'/> attribute when
> > > doing firmware auto-selection, we trivially enable a way for a mgmt
> > > app to indicate that it wants the SEV firmware without NVRAM
> > > support.
> > > 
> > > This series does all the plumbing we need.
> > > 
> > > The only minor issue is that QEMU support for -bios with SEV enabled
> > > firmware is broken:
> > > 
> > >   https://lists.gnu.org/archive/html/qemu-devel/2022-01/msg02957.html
> > 
> > Well turns out the concept is unfixably broken on the QEMU side
> > with SEV enabled UEFI firmware. So I'm going to ditch the first
> > docs patch.
> > 
> > I figure it is still possibly useful to be able to controla
> > auto-firmware selection based on 'type', even if it doesn't
> > help my sev use case, so might as well leave keep that now
> > I've implemented it.
> 
> In any case, in context of patch 2/5, shouldn't autoselect haven been left
> untouched and instead pick the type automatically, say in
> qemuValidateDomainDefBoot or similar depending on whether the domain has
> LaunchSecurity SEV defined in the XML?

Well there's already usage of SEV with existing guests with UEFI
split firmware with pflash. I didn't want to change it to prefer
ROM based firmware because that's a significant semantic change
that means you loose persistence of NVRAM variables. THe new
SEV firmware is not necessarily compatible with the currently
use SEV firmware from a guest OS POV, because it uses embedded
grub rather than invoking grub from the guest disk image.

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

Re: [libvirt PATCH 0/5] Support AMD SEV firmware with -bios instead of pflash

Posted by Erik Skultety 3 days, 14 hours ago
On Fri, Jan 21, 2022 at 02:44:02PM +0000, Daniel P. Berrangé wrote:
> On Fri, Jan 21, 2022 at 03:40:23PM +0100, Erik Skultety wrote:
> > On Fri, Jan 21, 2022 at 02:16:14PM +0000, Daniel P. Berrangé wrote:
> > > On Fri, Jan 14, 2022 at 07:07:10PM +0000, Daniel P. Berrangé wrote:
> > > > The firmware distros have given people for use with AMD SEV thus far has
> > > > just been one of the regular OVMF builds. This is sufficient for booting
> > > > a guest with SEV enabled, but is useless if you want to actually
> > > > validate the guest measurement. The NVRAM store is untrustworthy since
> > > > it is not included in the measurement. We need to supply a dedicated
> > > > build of OVMF without NVRAM support enabled. While it is possible to
> > > > use with pflash, we then get a problem with firmware selection as there
> > > > is no easy way to make it prefer the firmware without NVRAM. Also the
> > > > firmware descriptor treats the NVRAM template as a mandatory field
> > > > today and libvirt enforces that.
> > > > 
> > > > While we could invent a new feature flag 'sev-stateless' for the
> > > > firmware descriptors, and/or make the NVRAM template path optional,
> > > > it makes more sense if the firmware descriptor just reports the SEV
> > > > firmware as type=memory instead of type=flash.
> > > > 
> > > > If the libvirt XML parses the <loader type='rom'/> attribute when
> > > > doing firmware auto-selection, we trivially enable a way for a mgmt
> > > > app to indicate that it wants the SEV firmware without NVRAM
> > > > support.
> > > > 
> > > > This series does all the plumbing we need.
> > > > 
> > > > The only minor issue is that QEMU support for -bios with SEV enabled
> > > > firmware is broken:
> > > > 
> > > >   https://lists.gnu.org/archive/html/qemu-devel/2022-01/msg02957.html
> > > 
> > > Well turns out the concept is unfixably broken on the QEMU side
> > > with SEV enabled UEFI firmware. So I'm going to ditch the first
> > > docs patch.
> > > 
> > > I figure it is still possibly useful to be able to controla
> > > auto-firmware selection based on 'type', even if it doesn't
> > > help my sev use case, so might as well leave keep that now
> > > I've implemented it.
> > 
> > In any case, in context of patch 2/5, shouldn't autoselect haven been left
> > untouched and instead pick the type automatically, say in
> > qemuValidateDomainDefBoot or similar depending on whether the domain has
> > LaunchSecurity SEV defined in the XML?
> 
> Well there's already usage of SEV with existing guests with UEFI
> split firmware with pflash. I didn't want to change it to prefer
> ROM based firmware because that's a significant semantic change
> that means you loose persistence of NVRAM variables. THe new
> SEV firmware is not necessarily compatible with the currently
> use SEV firmware from a guest OS POV, because it uses embedded
> grub rather than invoking grub from the guest disk image.

Hmm, so let me ask if I understand correctly: You want to keep firmware
autoselection with SEV as is even though you won't be able to do measurements
and instead let the user provide an explicit type 'rom' setting hinting libvirt
to pick the right firmware build complying with the confidentiality rules for
SEV measurements?

Erik

Re: [libvirt PATCH 0/5] Support AMD SEV firmware with -bios instead of pflash

Posted by Daniel P. Berrangé 3 days, 14 hours ago
On Fri, Jan 21, 2022 at 03:51:51PM +0100, Erik Skultety wrote:
> On Fri, Jan 21, 2022 at 02:44:02PM +0000, Daniel P. Berrangé wrote:
> > On Fri, Jan 21, 2022 at 03:40:23PM +0100, Erik Skultety wrote:
> > > On Fri, Jan 21, 2022 at 02:16:14PM +0000, Daniel P. Berrangé wrote:
> > > > On Fri, Jan 14, 2022 at 07:07:10PM +0000, Daniel P. Berrangé wrote:
> > > > > The firmware distros have given people for use with AMD SEV thus far has
> > > > > just been one of the regular OVMF builds. This is sufficient for booting
> > > > > a guest with SEV enabled, but is useless if you want to actually
> > > > > validate the guest measurement. The NVRAM store is untrustworthy since
> > > > > it is not included in the measurement. We need to supply a dedicated
> > > > > build of OVMF without NVRAM support enabled. While it is possible to
> > > > > use with pflash, we then get a problem with firmware selection as there
> > > > > is no easy way to make it prefer the firmware without NVRAM. Also the
> > > > > firmware descriptor treats the NVRAM template as a mandatory field
> > > > > today and libvirt enforces that.
> > > > > 
> > > > > While we could invent a new feature flag 'sev-stateless' for the
> > > > > firmware descriptors, and/or make the NVRAM template path optional,
> > > > > it makes more sense if the firmware descriptor just reports the SEV
> > > > > firmware as type=memory instead of type=flash.
> > > > > 
> > > > > If the libvirt XML parses the <loader type='rom'/> attribute when
> > > > > doing firmware auto-selection, we trivially enable a way for a mgmt
> > > > > app to indicate that it wants the SEV firmware without NVRAM
> > > > > support.
> > > > > 
> > > > > This series does all the plumbing we need.
> > > > > 
> > > > > The only minor issue is that QEMU support for -bios with SEV enabled
> > > > > firmware is broken:
> > > > > 
> > > > >   https://lists.gnu.org/archive/html/qemu-devel/2022-01/msg02957.html
> > > > 
> > > > Well turns out the concept is unfixably broken on the QEMU side
> > > > with SEV enabled UEFI firmware. So I'm going to ditch the first
> > > > docs patch.
> > > > 
> > > > I figure it is still possibly useful to be able to controla
> > > > auto-firmware selection based on 'type', even if it doesn't
> > > > help my sev use case, so might as well leave keep that now
> > > > I've implemented it.
> > > 
> > > In any case, in context of patch 2/5, shouldn't autoselect haven been left
> > > untouched and instead pick the type automatically, say in
> > > qemuValidateDomainDefBoot or similar depending on whether the domain has
> > > LaunchSecurity SEV defined in the XML?
> > 
> > Well there's already usage of SEV with existing guests with UEFI
> > split firmware with pflash. I didn't want to change it to prefer
> > ROM based firmware because that's a significant semantic change
> > that means you loose persistence of NVRAM variables. THe new
> > SEV firmware is not necessarily compatible with the currently
> > use SEV firmware from a guest OS POV, because it uses embedded
> > grub rather than invoking grub from the guest disk image.
> 
> Hmm, so let me ask if I understand correctly: You want to keep firmware
> autoselection with SEV as is even though you won't be able to do measurements
> and instead let the user provide an explicit type 'rom' setting hinting libvirt
> to pick the right firmware build complying with the confidentiality rules for
> SEV measurements?

That's what this series did at least.

My new approach is to express the different ypes of 'pflash' build

 - 'split' - traditional CODE & VARS files separated
 - 'combined' -  CODE & VARS merged in a single file
 - 'stateless' - CODE only, no VARS


so a user wanting a measurable SEV launch would request a 'stateless'
firmware to be found.

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