1. Patchew
  2. EDK2
  3. [edk2-devel] [PATCH 00/11] Use proper entropy sources
  4. View patch

[edk2-devel] [PATCH 08/11] OvmfPkg: specify RngLib instances in dsc files

Wang, Jian J posted 11 patches 5 years ago
[edk2-devel] [PATCH 08/11] OvmfPkg: specify RngLib instances in dsc files
Posted by Wang, Jian J 5 years ago 
Per BZ1871, OpensslLib will depend on RngLib instead of TimerLib.
Update OVMF dsc files to accommodate the coming changes. It's supposed
that only TlsDxe needs random number. The DxeRngLibRngProtocol is added
for it. For all other drivers, BaseRngLibNull is used by default.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1871
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
---
 OvmfPkg/OvmfPkgIa32.dsc    | 5 +++++
 OvmfPkg/OvmfPkgIa32X64.dsc | 5 +++++
 OvmfPkg/OvmfPkgX64.dsc     | 5 +++++
 OvmfPkg/OvmfXen.dsc        | 5 +++++
 4 files changed, 20 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index d350b75630..5a709a95b2 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -217,6 +217,7 @@
 
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+  RngLib|MdePkg/Library/BaseRngLibNull/BaseRngLibNull.inf
 
 [LibraryClasses.common.SEC]
   TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
@@ -786,6 +787,10 @@
     <LibraryClasses>
       NULL|OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf
   }
+  NetworkPkg/TlsDxe/TlsDxe.inf {
+    <LibraryClasses>
+      RngLib|SecurityPkg/RandomNumberGenerator/DxeRngLibRngProtocol/DxeRngLibRngProtocol.inf
+  }
 !endif
   OvmfPkg/VirtioNetDxe/VirtioNet.inf
 
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 1ef82cafe4..16ff25fd2c 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -222,6 +222,7 @@
 
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+  RngLib|MdePkg/Library/BaseRngLibNull/BaseRngLibNull.inf
 
 [LibraryClasses.common.SEC]
   TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
@@ -799,6 +800,10 @@
     <LibraryClasses>
       NULL|OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf
   }
+  NetworkPkg/TlsDxe/TlsDxe.inf {
+    <LibraryClasses>
+      RngLib|SecurityPkg/RandomNumberGenerator/DxeRngLibRngProtocol/DxeRngLibRngProtocol.inf
+  }
 !endif
   OvmfPkg/VirtioNetDxe/VirtioNet.inf
 
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 232815c08e..c9c2af740f 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -222,6 +222,7 @@
 
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+  RngLib|MdePkg/Library/BaseRngLibNull/BaseRngLibNull.inf
 
 [LibraryClasses.common.SEC]
   TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
@@ -797,6 +798,10 @@
     <LibraryClasses>
       NULL|OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf
   }
+  NetworkPkg/TlsDxe/TlsDxe.inf {
+    <LibraryClasses>
+      RngLib|SecurityPkg/RandomNumberGenerator/DxeRngLibRngProtocol/DxeRngLibRngProtocol.inf
+  }
 !endif
   OvmfPkg/VirtioNetDxe/VirtioNet.inf
 
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 8c11efe9b7..557dff7744 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -204,6 +204,7 @@
 
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+  RngLib|MdePkg/Library/BaseRngLibNull/BaseRngLibNull.inf
 
 [LibraryClasses.common.SEC]
   QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
@@ -666,6 +667,10 @@
     <LibraryClasses>
       NULL|OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf
   }
+  NetworkPkg/TlsDxe/TlsDxe.inf {
+    <LibraryClasses>
+      RngLib|SecurityPkg/RandomNumberGenerator/DxeRngLibRngProtocol/DxeRngLibRngProtocol.inf
+  }
 !endif
 
   #
-- 
2.17.1.windows.2


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50614): https://edk2.groups.io/g/devel/message/50614
Mute This Topic: https://groups.io/mt/56714143/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 08/11] OvmfPkg: specify RngLib instances in dsc files
Posted by Laszlo Ersek 5 years ago 
Jian, Ard,

commenting for both OvmfPkg and ArmVirtPkg:

On 11/14/19 03:17, Wang, Jian J wrote:
> Per BZ1871, OpensslLib will depend on RngLib instead of TimerLib.
> Update OVMF dsc files to accommodate the coming changes. It's supposed
> that only TlsDxe needs random number. The DxeRngLibRngProtocol is added
> for it. For all other drivers, BaseRngLibNull is used by default.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1871
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
> ---
>  OvmfPkg/OvmfPkgIa32.dsc    | 5 +++++
>  OvmfPkg/OvmfPkgIa32X64.dsc | 5 +++++
>  OvmfPkg/OvmfPkgX64.dsc     | 5 +++++
>  OvmfPkg/OvmfXen.dsc        | 5 +++++
>  4 files changed, 20 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index d350b75630..5a709a95b2 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -217,6 +217,7 @@
>  
>  [LibraryClasses.common]
>    BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> +  RngLib|MdePkg/Library/BaseRngLibNull/BaseRngLibNull.inf
>  
>  [LibraryClasses.common.SEC]
>    TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
> @@ -786,6 +787,10 @@
>      <LibraryClasses>
>        NULL|OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf
>    }
> +  NetworkPkg/TlsDxe/TlsDxe.inf {
> +    <LibraryClasses>
> +      RngLib|SecurityPkg/RandomNumberGenerator/DxeRngLibRngProtocol/DxeRngLibRngProtocol.inf
> +  }
>  !endif
>    OvmfPkg/VirtioNetDxe/VirtioNet.inf
>  

This is not right for either OvmfPkg or ArmVirtPkg, because:

- the virtual hardware is dynamic and might change from boot to boot,

- EFI_RNG_PROTOCOL, implemented by VirtioRngDxe, only supports
EFI_RNG_ALGORITHM_RAW.

I propose the following approach.

(1) Jian, please do introduce all of the RngLib instances that you are
introducing in this v1 series, namely:

- the null lib instance,
- the RDSEED lib instance,
- the DXE / protocol lib instance that directly requires NIST/ANSI
conformant algorithm support from the RNG protocol.

(2) Jian, please add a *further* lib instance: a time based one. This
instance should basically extract the current functionality from
"rand_pool_noise.c" and "rand_pool_noise_tsc.c". (The code that you are
removing in patch #10.)

It's also fine with me if, rather than factoring out the
rand_pool_noise*.c logic, you add a new "CPU jitter" based RngLib
instance. (Ard might disagree with me about this alternative -- the
point is that we should have a library instance that provides *some*
(even if barely tolerable) randomness, but with no dependency on
*optional* hardware. In other words, this lib instance should depend on
*guaranteed* platform hardware only. TSC, TimerLib, etc.)

(3) For OvmfPkg and ArmVirtPkg, please write patches that:

- provide a default resolution to the Null instance,

- resolve RngLib to the time-based instance, for TlsDxe *only*.

At that point, we will have made ArmVirtPkg and OvmfPkg *independent* of
the rest of this series -- ArmVirtPkg and OvmfPkg will not block this
patch series, they will also not suffer any regressions, and we can go
ahead and implement a separate RngLib instance for TlsDxe ourselves.


Now, let me lay out my proposal for *that* RngLib instance. (I'm willing
to write it a good chunk of it, but I will need help from Ard minimally
in the crypto code.)

- The CONSTRUCTOR function should register an End-of-Dxe notification
function. In that function, (a) a boolean flag (such as "mEndOfDxe")
should be flipped from FALSE to TRUE, and (b) a pointer to
EFI_RNG_PROTOCOL should be saved (if such a protocol exists), such as
"mRngProtocol".

- each RngLib API in this lib instance should hang, if "mEndOfDxe" is
FALSE at the time of the call (--> CpuDeadLoop() etc)

- otherwise, if "mRngProtocol" is not NULL, it should be used to fetch
*raw* entropy. That raw entropy should be mixed sufficiently for NIST /
ANSI conformance. (I hope this statement makes sense.) This is where I'd
absolutely need help from Ard.

- otherwise, on IA32/X64 only, if CPUID indicates that RDSEED is
supported by the processor, call RDSEED.

- otherwise, on IA32/X64 only, if CPUID indicates that RDRAND is
supported by the processor, call RDRAND.

- otherwise, on all arches, scrape some timer-based entropy, "from the
bottom of the barrel" (possibly in an arch-specific way, e.g. we could
use TSC on IA32/X64).

- The platform BDS code for OVMF and ArmVirtQemu* should bind the
virtio-rng device to VirtioRngDxe *before* signaling End-of-Dxe.


The basic idea is that this RngLib instance should give the platform a
*chance* to produce an EFI_RNG_PROTOCOL instance until End-of-Dxe. If
that happens, then continue consuming raw entropy from *that* source,
and mix it manually for NIST / ANSI conformance. Otherwise, gracefully
degrade to the next strongest entropy source that's dynamically detected
on the platform (RDSEED or RDRAND, per CPUID -- on IA32/X64 only --, and
then timer-based -- on all platforms).

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50658): https://edk2.groups.io/g/devel/message/50658
Mute This Topic: https://groups.io/mt/56714143/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 08/11] OvmfPkg: specify RngLib instances in dsc files
Posted by Wang, Jian J 5 years ago 
Laszlo,


> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
> Sent: Thursday, November 14, 2019 7:08 PM
> To: Wang, Jian J <jian.j.wang@intel.com>; Ard Biesheuvel
> <ard.biesheuvel@linaro.org>
> Cc: devel@edk2.groups.io; Justen, Jordan L <jordan.l.justen@intel.com>; Gao,
> Liming <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
> Subject: Re: [edk2-devel] [PATCH 08/11] OvmfPkg: specify RngLib instances in
> dsc files
> 
> Jian, Ard,
> 
> commenting for both OvmfPkg and ArmVirtPkg:
> 
> On 11/14/19 03:17, Wang, Jian J wrote:
> > Per BZ1871, OpensslLib will depend on RngLib instead of TimerLib.
> > Update OVMF dsc files to accommodate the coming changes. It's supposed
> > that only TlsDxe needs random number. The DxeRngLibRngProtocol is added
> > for it. For all other drivers, BaseRngLibNull is used by default.
> >
> > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1871
> > Cc: Jordan Justen <jordan.l.justen@intel.com>
> > Cc: Laszlo Ersek <lersek@redhat.com>
> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Cc: Liming Gao <liming.gao@intel.com>
> > Cc: Ray Ni <ray.ni@intel.com>
> > Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
> > ---
> >  OvmfPkg/OvmfPkgIa32.dsc    | 5 +++++
> >  OvmfPkg/OvmfPkgIa32X64.dsc | 5 +++++
> >  OvmfPkg/OvmfPkgX64.dsc     | 5 +++++
> >  OvmfPkg/OvmfXen.dsc        | 5 +++++
> >  4 files changed, 20 insertions(+)
> >
> > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> > index d350b75630..5a709a95b2 100644
> > --- a/OvmfPkg/OvmfPkgIa32.dsc
> > +++ b/OvmfPkg/OvmfPkgIa32.dsc
> > @@ -217,6 +217,7 @@
> >
> >  [LibraryClasses.common]
> >    BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> > +  RngLib|MdePkg/Library/BaseRngLibNull/BaseRngLibNull.inf
> >
> >  [LibraryClasses.common.SEC]
> >    TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
> > @@ -786,6 +787,10 @@
> >      <LibraryClasses>
> >        NULL|OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf
> >    }
> > +  NetworkPkg/TlsDxe/TlsDxe.inf {
> > +    <LibraryClasses>
> > +
> RngLib|SecurityPkg/RandomNumberGenerator/DxeRngLibRngProtocol/DxeRng
> LibRngProtocol.inf
> > +  }
> >  !endif
> >    OvmfPkg/VirtioNetDxe/VirtioNet.inf
> >
> 
> This is not right for either OvmfPkg or ArmVirtPkg, because:
> 
> - the virtual hardware is dynamic and might change from boot to boot,
> 
> - EFI_RNG_PROTOCOL, implemented by VirtioRngDxe, only supports
> EFI_RNG_ALGORITHM_RAW.
> 
> I propose the following approach.
> 
> (1) Jian, please do introduce all of the RngLib instances that you are
> introducing in this v1 series, namely:
> 
> - the null lib instance,
> - the RDSEED lib instance,
> - the DXE / protocol lib instance that directly requires NIST/ANSI
> conformant algorithm support from the RNG protocol.
> 

I agree.

> (2) Jian, please add a *further* lib instance: a time based one. This
> instance should basically extract the current functionality from
> "rand_pool_noise.c" and "rand_pool_noise_tsc.c". (The code that you are
> removing in patch #10.)
> 
> It's also fine with me if, rather than factoring out the
> rand_pool_noise*.c logic, you add a new "CPU jitter" based RngLib
> instance. (Ard might disagree with me about this alternative -- the
> point is that we should have a library instance that provides *some*
> (even if barely tolerable) randomness, but with no dependency on
> *optional* hardware. In other words, this lib instance should depend on
> *guaranteed* platform hardware only. TSC, TimerLib, etc.)
> 

Either is fine with me. I'll let you and Ard to make decision.

> (3) For OvmfPkg and ArmVirtPkg, please write patches that:
> 
> - provide a default resolution to the Null instance,
> 
> - resolve RngLib to the time-based instance, for TlsDxe *only*.
> 

Ok. I'll update those dsc in v2.

> At that point, we will have made ArmVirtPkg and OvmfPkg *independent* of
> the rest of this series -- ArmVirtPkg and OvmfPkg will not block this
> patch series, they will also not suffer any regressions, and we can go
> ahead and implement a separate RngLib instance for TlsDxe ourselves.
> 
> 
> Now, let me lay out my proposal for *that* RngLib instance. (I'm willing
> to write it a good chunk of it, but I will need help from Ard minimally
> in the crypto code.)
> 
> - The CONSTRUCTOR function should register an End-of-Dxe notification
> function. In that function, (a) a boolean flag (such as "mEndOfDxe")
> should be flipped from FALSE to TRUE, and (b) a pointer to
> EFI_RNG_PROTOCOL should be saved (if such a protocol exists), such as
> "mRngProtocol".
> 
> - each RngLib API in this lib instance should hang, if "mEndOfDxe" is
> FALSE at the time of the call (--> CpuDeadLoop() etc)
> 
> - otherwise, if "mRngProtocol" is not NULL, it should be used to fetch
> *raw* entropy. That raw entropy should be mixed sufficiently for NIST /
> ANSI conformance. (I hope this statement makes sense.) This is where I'd
> absolutely need help from Ard.
> 
> - otherwise, on IA32/X64 only, if CPUID indicates that RDSEED is
> supported by the processor, call RDSEED.
> 
> - otherwise, on IA32/X64 only, if CPUID indicates that RDRAND is
> supported by the processor, call RDRAND.
> 
> - otherwise, on all arches, scrape some timer-based entropy, "from the
> bottom of the barrel" (possibly in an arch-specific way, e.g. we could
> use TSC on IA32/X64).
> 
> - The platform BDS code for OVMF and ArmVirtQemu* should bind the
> virtio-rng device to VirtioRngDxe *before* signaling End-of-Dxe.
> 
> 
> The basic idea is that this RngLib instance should give the platform a
> *chance* to produce an EFI_RNG_PROTOCOL instance until End-of-Dxe. If
> that happens, then continue consuming raw entropy from *that* source,
> and mix it manually for NIST / ANSI conformance. Otherwise, gracefully
> degrade to the next strongest entropy source that's dynamically detected
> on the platform (RDSEED or RDRAND, per CPUID -- on IA32/X64 only --, and
> then timer-based -- on all platforms).
> 

I'm curious that you want to do the "degrade" dynamically at boot time not
build time, right?

Thanks,
Jian

> Thanks
> Laszlo
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50670): https://edk2.groups.io/g/devel/message/50670
Mute This Topic: https://groups.io/mt/56714143/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 08/11] OvmfPkg: specify RngLib instances in dsc files
Posted by Laszlo Ersek 5 years ago 
On 11/14/19 15:40, Wang, Jian J wrote:

> I'm curious that you want to do the "degrade" dynamically at boot time not
> build time, right?

Indeed, that's the whole point. When running on QEMU (considering all of
arm/aarch64/i386/x86_64), the firmware can assume quite little of the
underlying platform hardware; a single firmware binary is expected to
support multiple (virtual) hardware configurations. Therefore several
decisions have to be made dynamically at boot time, in the firmware,
that physical firmware platforms can hard-wire at build time.

(Of course this approach has its limits -- the most visible "platform
split" that we do implement at build time is "QEMU vs. Xen". ArmVirtPkg
implements this switch only at build time, and OvmfPkg will also fully
adopt that approach in the future.)

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50672): https://edk2.groups.io/g/devel/message/50672
Mute This Topic: https://groups.io/mt/56714143/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 08/11] OvmfPkg: specify RngLib instances in dsc files
Posted by Wang, Jian J 5 years ago 
Laszlo,

That makes sense for virtual platforms. Thanks for the explanation.

Regards,
Jian

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
> Sent: Thursday, November 14, 2019 10:51 PM
> To: Wang, Jian J <jian.j.wang@intel.com>; devel@edk2.groups.io; Ard
> Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Gao, Liming
> <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>
> Subject: Re: [edk2-devel] [PATCH 08/11] OvmfPkg: specify RngLib instances in
> dsc files
> 
> On 11/14/19 15:40, Wang, Jian J wrote:
> 
> > I'm curious that you want to do the "degrade" dynamically at boot time not
> > build time, right?
> 
> Indeed, that's the whole point. When running on QEMU (considering all of
> arm/aarch64/i386/x86_64), the firmware can assume quite little of the
> underlying platform hardware; a single firmware binary is expected to
> support multiple (virtual) hardware configurations. Therefore several
> decisions have to be made dynamically at boot time, in the firmware,
> that physical firmware platforms can hard-wire at build time.
> 
> (Of course this approach has its limits -- the most visible "platform
> split" that we do implement at build time is "QEMU vs. Xen". ArmVirtPkg
> implements this switch only at build time, and OvmfPkg will also fully
> adopt that approach in the future.)
> 
> Thanks
> Laszlo
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50674): https://edk2.groups.io/g/devel/message/50674
Mute This Topic: https://groups.io/mt/56714143/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

Patchew 2.1-devel-b67e4c2

© 2016 - 2024 Red Hat, Inc.