libvirt.spec.in: Add the Secure Boot-variant OVMF binaries

[libvirt] [PATCH] libvirt.spec.in: Add the Secure Boot-variant OVMF binaries

Posted by Kashyap Chamarthy 4 years, 8 months ago

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] libvirt.spec.in: Add the Secure Boot-variant OVMF binaries

Posted by Cole Robinson 4 years, 7 months ago

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] libvirt.spec.in: Add the Secure Boot-variant OVMF binaries

Posted by Michal Privoznik 4 years, 7 months ago

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list