[libvirt] [PATCH] libvirt.spec.in: Add the Secure Boot-variant OVMF binaries
Currently the RPM spec doesn't add the 'secboot'-variant OVMF binaries (an unintentional omission, checking with Cole on #virt, OFTC) for 'x86_64' and 'ia32'. Add them. This way, getDomainCapabilities() will report all the OVMF binaries that are present on the system. E.g. on Fedora 29, if you only have the edk2-ovmf-20190308stable-1.fc29.noarch package installed, then running `virsh domcapabilities` will enumerate _both_ the OVMF binaries (instead of just the OVMF_CODE.fd): $> virsh getdomcapabilities ... <loader supported='yes'> <value>/usr/share/edk2/ovmf/OVMF_CODE.fd</value> <value>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</value> ... ( Learnt this from a discussion with Michal Privoznik in this bug, comment#2: https://bugzilla.redhat.com/show_bug.cgi?id=1733940 -- RFE: Report firmware (FW) paths in domainCapabilities based on FW descriptor files ) Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> --- I only did a cursory check on if I missed to add any other valid paths for other architectures. --- libvirt.spec.in | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index b13b863928..99950495a7 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1135,10 +1135,17 @@ exit 1 # Nightly edk2.git-arm LOADERS="$LOADERS:/usr/share/edk2.git/arm/QEMU_EFI-pflash.raw:/usr/share/edk2.git/arm/vars-template-pflash.raw" - # Fedora edk2-ovmf + # Fedora edk2-ovmf, x86_64 LOADERS="$LOADERS:/usr/share/edk2/ovmf/OVMF_CODE.fd:/usr/share/edk2/ovmf/OVMF_VARS.fd" + # Fedora edk2-ovmf, x86_64, with Secure Boot + LOADERS="$LOADERS:/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd:/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd" # Fedora edk2-ovmf-ia32 LOADERS="$LOADERS:/usr/share/edk2/ovmf-ia32/OVMF_CODE.fd:/usr/share/edk2/ovmf-ia32/OVMF_VARS.fd" + # Fedora edk2-ovmf-ia32, with Secure Boot. (NB: Unlike x86_64, for + # 'ia32', there is no secboot-variant "VARS" file (NVRAM template). + # So the NVRAM template for 'ovmf-ia32/OVMF_CODE.secboot.fd' is the + # same as the one for the non-secboot variant.) + LOADERS="$LOADERS:/usr/share/edk2/ovmf-ia32/OVMF_CODE.secboot.fd:/usr/share/edk2/ovmf-ia32/OVMF_VARS.fd" # Fedora edk2-aarch64 LOADERS="$LOADERS:/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2/aarch64/vars-template-pflash.raw" # Fedora edk2-arm -- 2.20.1
On 7/30/19 12:11 PM, Kashyap Chamarthy wrote:
Currently the RPM spec doesn't add the 'secboot'-variant OVMF binaries (an unintentional omission, checking with Cole on #virt, OFTC) for 'x86_64' and 'ia32'. Add them.
This way, getDomainCapabilities() will report all the OVMF binaries that are present on the system. E.g. on Fedora 29, if you only have the edk2-ovmf-20190308stable-1.fc29.noarch package installed, then running `virsh domcapabilities` will enumerate _both_ the OVMF binaries (instead of just the OVMF_CODE.fd):
$> virsh getdomcapabilities ... <loader supported='yes'> <value>/usr/share/edk2/ovmf/OVMF_CODE.fd</value> <value>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</value> ...
( Learnt this from a discussion with Michal Privoznik in this bug, comment#2:
https://bugzilla.redhat.com/show_bug.cgi?id=1733940 -- RFE: Report firmware (FW) paths in domainCapabilities based on FW descriptor files )
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> --- I only did a cursory check on if I missed to add any other valid paths for other architectures. ---
For the change: Reviewed-by: Cole Robinson <crobinso@redhat.com> But I'm not sure how much we care now that firmware.repo is in the mix. I'll leave it up to Michal whether to apply - Cole
libvirt.spec.in | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in index b13b863928..99950495a7 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1135,10 +1135,17 @@ exit 1 # Nightly edk2.git-arm LOADERS="$LOADERS:/usr/share/edk2.git/arm/QEMU_EFI-pflash.raw:/usr/share/edk2.git/arm/vars-template-pflash.raw"
- # Fedora edk2-ovmf + # Fedora edk2-ovmf, x86_64 LOADERS="$LOADERS:/usr/share/edk2/ovmf/OVMF_CODE.fd:/usr/share/edk2/ovmf/OVMF_VARS.fd" + # Fedora edk2-ovmf, x86_64, with Secure Boot + LOADERS="$LOADERS:/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd:/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd" # Fedora edk2-ovmf-ia32 LOADERS="$LOADERS:/usr/share/edk2/ovmf-ia32/OVMF_CODE.fd:/usr/share/edk2/ovmf-ia32/OVMF_VARS.fd" + # Fedora edk2-ovmf-ia32, with Secure Boot. (NB: Unlike x86_64, for + # 'ia32', there is no secboot-variant "VARS" file (NVRAM template). + # So the NVRAM template for 'ovmf-ia32/OVMF_CODE.secboot.fd' is the + # same as the one for the non-secboot variant.) + LOADERS="$LOADERS:/usr/share/edk2/ovmf-ia32/OVMF_CODE.secboot.fd:/usr/share/edk2/ovmf-ia32/OVMF_VARS.fd" # Fedora edk2-aarch64 LOADERS="$LOADERS:/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2/aarch64/vars-template-pflash.raw" # Fedora edk2-arm
- Cole
On 9/10/19 8:56 PM, Cole Robinson wrote:
On 7/30/19 12:11 PM, Kashyap Chamarthy wrote:
Currently the RPM spec doesn't add the 'secboot'-variant OVMF binaries (an unintentional omission, checking with Cole on #virt, OFTC) for 'x86_64' and 'ia32'. Add them.
This way, getDomainCapabilities() will report all the OVMF binaries that are present on the system. E.g. on Fedora 29, if you only have the edk2-ovmf-20190308stable-1.fc29.noarch package installed, then running `virsh domcapabilities` will enumerate _both_ the OVMF binaries (instead of just the OVMF_CODE.fd):
$> virsh getdomcapabilities ... <loader supported='yes'> <value>/usr/share/edk2/ovmf/OVMF_CODE.fd</value> <value>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</value> ...
( Learnt this from a discussion with Michal Privoznik in this bug, comment#2:
https://bugzilla.redhat.com/show_bug.cgi?id=1733940 -- RFE: Report firmware (FW) paths in domainCapabilities based on FW descriptor files )
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> --- I only did a cursory check on if I missed to add any other valid paths for other architectures. ---
For the change:
Reviewed-by: Cole Robinson <crobinso@redhat.com>
But I'm not sure how much we care now that firmware.repo is in the mix. I'll leave it up to Michal whether to apply
The only concern I had with this patch is that we will start putting "*.secboot.fd" images into domcaps XML even if secboot might not be available for given combination of arguments (machine type + arch). However, after my series gets merged we will report only those FW image paths that we found FW descriptors for and this will be used only as a fallback: https://www.redhat.com/archives/libvir-list/2019-August/msg00109.html So after all, ACK from me too. And pushed. Michal
participants (3)
-
Cole Robinson -
Kashyap Chamarthy -
Michal Privoznik