From: Marc-André Lureau <marcandre.lureau@redhat.com>
The library registers a security management handler, to measure images
that are not measure in PEI phase.
This seems to work for example with the qemu PXE rom:
Loading driver at 0x0003E6C2000 EntryPoint=0x0003E6C9076 8086100e.efi
And the following binary_bios_measurements log entry seems to be
added:
PCR: 2 type: EV_EFI_BOOT_SERVICES_DRIVER size: 0x4e digest: 70a22475e9f18806d2ed9193b48d80d26779d9a4
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
OvmfPkg/OvmfPkgX64.dsc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 7753852144fb..9db1712e3623 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -662,6 +662,9 @@ [Components]
<LibraryClasses>
!if $(SECURE_BOOT_ENABLE) == TRUE
NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
+!endif
+!if $(TPM2_ENABLE) == TRUE
+ NULL|SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf
!endif
}
--
2.16.2.346.g9779355e34
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
(Jiewen, below I have a question for you as well; please help with that.) On 03/07/18 16:57, marcandre.lureau@redhat.com wrote: > From: Marc-André Lureau <marcandre.lureau@redhat.com> > > The library registers a security management handler, to measure images > that are not measure in PEI phase. > > This seems to work for example with the qemu PXE rom: > > Loading driver at 0x0003E6C2000 EntryPoint=0x0003E6C9076 8086100e.efi > > And the following binary_bios_measurements log entry seems to be > added: > > PCR: 2 type: EV_EFI_BOOT_SERVICES_DRIVER size: 0x4e digest: 70a22475e9f18806d2ed9193b48d80d26779d9a4 > > Cc: Laszlo Ersek <lersek@redhat.com> > Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> > --- > OvmfPkg/OvmfPkgX64.dsc | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc > index 7753852144fb..9db1712e3623 100644 > --- a/OvmfPkg/OvmfPkgX64.dsc > +++ b/OvmfPkg/OvmfPkgX64.dsc > @@ -662,6 +662,9 @@ [Components] > <LibraryClasses> > !if $(SECURE_BOOT_ENABLE) == TRUE > NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf > +!endif > +!if $(TPM2_ENABLE) == TRUE > + NULL|SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf > !endif > } > > (1) Marc-André, please change the subject line to: OvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe (2) I have a question for Jiewen: DxeTpm2MeasureBootLib consumes the TCG2 protocol, but it does not depend on it with a DEPEX. Instead, DxeTpm2MeasureBootHandler() tries to locate the protocol on every invocation. This means that SecurityStubDxe may produce the Security and Security2 Architectural Protocols before measurements into the TPM2 device are possible. Therefore, UEFI_DRIVER modules (which depend on all of the Arch protocols) may be started before they can be measured into the TPM. Now, this is likely no problem for UEFI_DRIVER modules that are built into the firmware volume(s), because those are measured by Tcg2Pei anyway. However, it would be a problem for UEFI_DRIVER modules / apps that come from external media (disk, network, PCI oprom, etc). However, such are loaded only in the BDS phase, and BDS is only entered after all of the DXE drivers are dispatched from the firmware volumes. In other words, the ordering between Tcg2Dxe and external UEFI_DRIVER / UEFI_APPLICATION modules is ensured that Tcg2Dxe will be dispatched in the DXE phase, while the latter will only be loaded in BDS. Is this intentional? Is my understanding correct? (3) If that's the case, then Marc-André, please add the following to the commit message: -------- Hooking DxeTpm2MeasureBootLib into SecurityStubDxe ensures that the Security and Security2 Arch protocols will entail, by the time of entering the BDS phase, the measuring of UEFI binaries into the TPM. Thus, external UEFI_DRIVER and UEFI_APPLICATION modules (which are loaded in the BDS phase, from disk, network, PCI oprom, etc) will be measured. Drivers dispatched in the DXE phase before Tcg2Dxe will not be measured individually; however such drivers come from the firmware volume(s), and those are measured in the PEI phase by Tcg2Pei. -------- Thanks! Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
On 03/08/18 20:54, Laszlo Ersek wrote: > In other words, the ordering between Tcg2Dxe and external UEFI_DRIVER / > UEFI_APPLICATION modules is ensured that Tcg2Dxe will be dispatched in > the DXE phase, while the latter will only be loaded in BDS. Sigh, I meant: The ordering between Tcg2Dxe and external UEFI_DRIVER / UEFI_APPLICATION modules is ensured *by the fact* that Tcg2Dxe will be dispatched in the DXE phase, while the latter will only be loaded in BDS. Thanks, Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Very good question. Comment below: > -----Original Message----- > From: Laszlo Ersek [mailto:lersek@redhat.com] > Sent: Friday, March 9, 2018 3:54 AM > To: marcandre.lureau@redhat.com; edk2-devel@lists.01.org; Yao, Jiewen > <jiewen.yao@intel.com> > Cc: pjones@redhat.com; stefanb@linux.vnet.ibm.com; > qemu-devel@nongnu.org; javierm@redhat.com > Subject: Re: [PATCH v2 8/8] ovmf: add DxeTpm2MeasureBootLib > > (Jiewen, below I have a question for you as well; please help with that.) > > On 03/07/18 16:57, marcandre.lureau@redhat.com wrote: > > From: Marc-André Lureau <marcandre.lureau@redhat.com> > > > > The library registers a security management handler, to measure images > > that are not measure in PEI phase. > > > > This seems to work for example with the qemu PXE rom: > > > > Loading driver at 0x0003E6C2000 EntryPoint=0x0003E6C9076 8086100e.efi > > > > And the following binary_bios_measurements log entry seems to be > > added: > > > > PCR: 2 type: EV_EFI_BOOT_SERVICES_DRIVER size: 0x4e digest: > 70a22475e9f18806d2ed9193b48d80d26779d9a4 > > > > Cc: Laszlo Ersek <lersek@redhat.com> > > Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> > > --- > > OvmfPkg/OvmfPkgX64.dsc | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc > > index 7753852144fb..9db1712e3623 100644 > > --- a/OvmfPkg/OvmfPkgX64.dsc > > +++ b/OvmfPkg/OvmfPkgX64.dsc > > @@ -662,6 +662,9 @@ [Components] > > <LibraryClasses> > > !if $(SECURE_BOOT_ENABLE) == TRUE > > > NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf > > +!endif > > +!if $(TPM2_ENABLE) == TRUE > > + > NULL|SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.i > nf > > !endif > > } > > > > > > (1) Marc-André, please change the subject line to: > > OvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe > > > (2) I have a question for Jiewen: > > DxeTpm2MeasureBootLib consumes the TCG2 protocol, but it does not depend > on it with a DEPEX. Instead, DxeTpm2MeasureBootHandler() tries to locate > the protocol on every invocation. [Jiewen] Yes. > This means that SecurityStubDxe may produce the Security and Security2 > Architectural Protocols before measurements into the TPM2 device are > possible. [Jiewen] Yes. > Therefore, UEFI_DRIVER modules (which depend on all of the > Arch protocols) may be started before they can be measured into the TPM. > > Now, this is likely no problem for UEFI_DRIVER modules that are built > into the firmware volume(s), because those are measured by Tcg2Pei > anyway. [Jiewen] That is TRUE. However, it would be a problem for UEFI_DRIVER modules / apps > that come from external media (disk, network, PCI oprom, etc). [Jiewen] By design, the 3rd part module should not be invoked before EndOfDxe. All Arch Protocol Ready is not strong enough. :-) Please refer to https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.c If a non-FV image is loaded before EndOfDxe, it will be queued into mDeferred3rdPartyImage. We also added EfiBootManagerDispatchDeferredImages() API in https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Library/UefiBootManagerLib.h and implemented in https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c A platform must call EfiBootManagerDispatchDeferredImages(), if the platform supports PCI OROM. You can find the sample code in https://github.com/tianocore/edk2-platforms/blob/devel-MinPlatform/Platform/Intel/MinPlatformPkg/Bds/Library/DxePlatformBootManagerLib/BdsPlatform.c > However, such are loaded only in the BDS phase, and BDS is only entered > after all of the DXE drivers are dispatched from the firmware volumes. > In other words, the ordering between Tcg2Dxe and external UEFI_DRIVER / > UEFI_APPLICATION modules is ensured that Tcg2Dxe will be dispatched in > the DXE phase, while the latter will only be loaded in BDS. > > Is this intentional? Is my understanding correct? [Jiewen] Right. The only assumption is: Tcg2Dxe is included in the firmware volume and it is dispatched before EndOfDxe. > > (3) If that's the case, then Marc-André, please add the following to the > commit message: > > -------- > Hooking DxeTpm2MeasureBootLib into SecurityStubDxe ensures that the > Security and Security2 Arch protocols will entail, by the time of > entering the BDS phase, the measuring of UEFI binaries into the TPM. > Thus, external UEFI_DRIVER and UEFI_APPLICATION modules (which are > loaded in the BDS phase, from disk, network, PCI oprom, etc) will be > measured. > > Drivers dispatched in the DXE phase before Tcg2Dxe will not be measured > individually; however such drivers come from the firmware volume(s), and > those are measured in the PEI phase by Tcg2Pei. > -------- > > Thanks! > Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Besides the comment below, I should have used the example in OvmfPkg. Please refer to https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c The EfiBootManagerDispatchDeferredImages() API call is added just after gEfiDxeSmmReadyToLockProtocolGuid. So I don’t see any problem in OVMF pkg. Thank you Yao Jiewen > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Yao, > Jiewen > Sent: Friday, March 9, 2018 8:39 AM > To: Laszlo Ersek <lersek@redhat.com>; marcandre.lureau@redhat.com; > edk2-devel@lists.01.org > Cc: javierm@redhat.com; pjones@redhat.com; qemu-devel@nongnu.org > Subject: Re: [edk2] [PATCH v2 8/8] ovmf: add DxeTpm2MeasureBootLib > > Very good question. > Comment below: > > > -----Original Message----- > > From: Laszlo Ersek [mailto:lersek@redhat.com] > > Sent: Friday, March 9, 2018 3:54 AM > > To: marcandre.lureau@redhat.com; edk2-devel@lists.01.org; Yao, Jiewen > > <jiewen.yao@intel.com> > > Cc: pjones@redhat.com; stefanb@linux.vnet.ibm.com; > > qemu-devel@nongnu.org; javierm@redhat.com > > Subject: Re: [PATCH v2 8/8] ovmf: add DxeTpm2MeasureBootLib > > > > (Jiewen, below I have a question for you as well; please help with that.) > > > > On 03/07/18 16:57, marcandre.lureau@redhat.com wrote: > > > From: Marc-André Lureau <marcandre.lureau@redhat.com> > > > > > > The library registers a security management handler, to measure images > > > that are not measure in PEI phase. > > > > > > This seems to work for example with the qemu PXE rom: > > > > > > Loading driver at 0x0003E6C2000 EntryPoint=0x0003E6C9076 8086100e.efi > > > > > > And the following binary_bios_measurements log entry seems to be > > > added: > > > > > > PCR: 2 type: EV_EFI_BOOT_SERVICES_DRIVER size: 0x4e digest: > > 70a22475e9f18806d2ed9193b48d80d26779d9a4 > > > > > > Cc: Laszlo Ersek <lersek@redhat.com> > > > Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> > > > --- > > > OvmfPkg/OvmfPkgX64.dsc | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc > > > index 7753852144fb..9db1712e3623 100644 > > > --- a/OvmfPkg/OvmfPkgX64.dsc > > > +++ b/OvmfPkg/OvmfPkgX64.dsc > > > @@ -662,6 +662,9 @@ [Components] > > > <LibraryClasses> > > > !if $(SECURE_BOOT_ENABLE) == TRUE > > > > > > NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf > > > +!endif > > > +!if $(TPM2_ENABLE) == TRUE > > > + > > > NULL|SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.i > > nf > > > !endif > > > } > > > > > > > > > > (1) Marc-André, please change the subject line to: > > > > OvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe > > > > > > (2) I have a question for Jiewen: > > > > DxeTpm2MeasureBootLib consumes the TCG2 protocol, but it does not depend > > on it with a DEPEX. Instead, DxeTpm2MeasureBootHandler() tries to locate > > the protocol on every invocation. > [Jiewen] Yes. > > > This means that SecurityStubDxe may produce the Security and Security2 > > Architectural Protocols before measurements into the TPM2 device are > > possible. > [Jiewen] Yes. > > > Therefore, UEFI_DRIVER modules (which depend on all of the > > Arch protocols) may be started before they can be measured into the TPM. > > > > Now, this is likely no problem for UEFI_DRIVER modules that are built > > into the firmware volume(s), because those are measured by Tcg2Pei > > anyway. > [Jiewen] That is TRUE. > > However, it would be a problem for UEFI_DRIVER modules / apps > > that come from external media (disk, network, PCI oprom, etc). > [Jiewen] By design, the 3rd part module should not be invoked before EndOfDxe. > All Arch Protocol Ready is not strong enough. :-) > Please refer to > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Sec > urityStubDxe/Defer3rdPartyImageLoad.c > > If a non-FV image is loaded before EndOfDxe, it will be queued into > mDeferred3rdPartyImage. > > We also added EfiBootManagerDispatchDeferredImages() API in > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Librar > y/UefiBootManagerLib.h and implemented in > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/UefiB > ootManagerLib/BmMisc.c > A platform must call EfiBootManagerDispatchDeferredImages(), if the platform > supports PCI OROM. > > You can find the sample code in > https://github.com/tianocore/edk2-platforms/blob/devel-MinPlatform/Platform > /Intel/MinPlatformPkg/Bds/Library/DxePlatformBootManagerLib/BdsPlatform.c > > > > > However, such are loaded only in the BDS phase, and BDS is only entered > > after all of the DXE drivers are dispatched from the firmware volumes. > > In other words, the ordering between Tcg2Dxe and external UEFI_DRIVER / > > UEFI_APPLICATION modules is ensured that Tcg2Dxe will be dispatched in > > the DXE phase, while the latter will only be loaded in BDS. > > > > Is this intentional? Is my understanding correct? > > [Jiewen] Right. The only assumption is: Tcg2Dxe is included in the firmware > volume and it is dispatched before EndOfDxe. > > > > > > > (3) If that's the case, then Marc-André, please add the following to the > > commit message: > > > > -------- > > Hooking DxeTpm2MeasureBootLib into SecurityStubDxe ensures that the > > Security and Security2 Arch protocols will entail, by the time of > > entering the BDS phase, the measuring of UEFI binaries into the TPM. > > Thus, external UEFI_DRIVER and UEFI_APPLICATION modules (which are > > loaded in the BDS phase, from disk, network, PCI oprom, etc) will be > > measured. > > > > Drivers dispatched in the DXE phase before Tcg2Dxe will not be measured > > individually; however such drivers come from the firmware volume(s), and > > those are measured in the PEI phase by Tcg2Pei. > > -------- > > > > Thanks! > > Laszlo > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
On 03/09/18 01:39, Yao, Jiewen wrote:
> Very good question.
> Comment below:
>
>> -----Original Message-----
>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>> Sent: Friday, March 9, 2018 3:54 AM
>> To: marcandre.lureau@redhat.com; edk2-devel@lists.01.org; Yao, Jiewen
>> <jiewen.yao@intel.com>
>> Cc: pjones@redhat.com; stefanb@linux.vnet.ibm.com;
>> qemu-devel@nongnu.org; javierm@redhat.com
>> Subject: Re: [PATCH v2 8/8] ovmf: add DxeTpm2MeasureBootLib
>> However, it would be a problem for UEFI_DRIVER modules / apps
>> that come from external media (disk, network, PCI oprom, etc).
> [Jiewen] By design, the 3rd part module should not be invoked before
> EndOfDxe. All Arch Protocol Ready is not strong enough. :-) Please
> refer to
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.c
>
> If a non-FV image is loaded before EndOfDxe, it will be queued into
> mDeferred3rdPartyImage.
OK, thank you -- I suspected image deferral was somehow related to this.
I remember deferred execution from the OVMF log, even though at present
we hook only DxeImageVerificationLib into SecurityStubDxe.
> We also added EfiBootManagerDispatchDeferredImages() API in
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Library/UefiBootManagerLib.h
> and implemented in
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
> A platform must call EfiBootManagerDispatchDeferredImages(), if the
> platform supports PCI OROM.
Yep, OVMF does that already. In
"OvmfPkg/Library/PlatformBootManagerLib", we have the following order of
operations, in PlatformBootManagerBeforeConsole():
(a) connect all PCI root bridges non-recursively (this produces PciIo
instances and discovers the PCI oproms)
(b) kick QEMU so that it generates the ACPI tables that OVMF has to
install (this depends on PciIo instances existing, from step (1a)),
and actually install those tables
(c) signal End-of-Dxe (this depends on step (1b), because S3 support
needs the FACS table coming from step (1b))
(d) write an INFO opcode to the S3 boot script so that the boot script
is never empty
(e) install DxeSmmReadyToLock (this may come only after steps (1c) and
(1d))
(f) we call EfiBootManagerDispatchDeferredImages(). This is from Ray's
commit 9789894e3ba3 ("OvmfPkg/PlatformBds: Dispatch deferred images
after EndOfDxe", 2016-11-10).
(The rest of PlatformBootManagerBeforeConsole() skipped here.)
So, we have all the right operations in place, I just missed that non-FV
images loaded before End-of-Dxe (such as PCI oproms) are deferred until
step (f), and that the deferral will cover the TPM measurements too.
This is great, because it's an even stronger guarantee than what I would
have wished for. I mean the argument I wrote up earlier -- about oproms
not being dispatched before entering BDS, at which point Tcg2Dxe will
have been dispatched already -- was already good enough, but now I know
that PCI oproms are delayed even *within* BDS until after we explicitly
end DXE and dispatch the deferred images.
> You can find the sample code in
> https://github.com/tianocore/edk2-platforms/blob/devel-MinPlatform/Platform/Intel/MinPlatformPkg/Bds/Library/DxePlatformBootManagerLib/BdsPlatform.c
>
>
>
>> However, such are loaded only in the BDS phase, and BDS is only
>> entered after all of the DXE drivers are dispatched from the firmware
>> volumes. In other words, the ordering between Tcg2Dxe and external
>> UEFI_DRIVER / UEFI_APPLICATION modules is ensured that Tcg2Dxe will
>> be dispatched in the DXE phase, while the latter will only be loaded
>> in BDS.
>>
>> Is this intentional? Is my understanding correct?
>
> [Jiewen] Right. The only assumption is: Tcg2Dxe is included in the
> firmware volume and it is dispatched before EndOfDxe.
Perfect. Thank you.
So, Marc-André, I would request the following commit message *addition*
(not replacement!) then:
--------------
The following order of operations ensures that 3rd party UEFI modules,
such as PCI option ROMs and other modules possibly loaded from outside
of firmware volumes, are measured into the TPM:
(1) Tcg2Dxe is included in DXEFV, therefore it produces the TCG2
protocol sometime in the DXE phase (assuming a TPM2 chip is present,
reported via PcdTpmInstanceGuid).
(2) The DXE core finds that no more drivers are left to dispatch from
DXEFV, and we enter the BDS phase.
(3) OVMF's PlatformBootManagerLib connects all PCI root bridges
non-recursively, producing PciIo instances and discovering PCI
oproms.
(4) The dispatching of images that don't originate from FVs is deferred
at this point, by
"MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.c".
(5) OVMF's PlatformBootManagerLib signals EndOfDxe.
(6) OVMF's PlatformBootManagerLib calls
EfiBootManagerDispatchDeferredImages() -- the images deferred in
step (4) are now dispatched.
(7) Image dispatch invokes the Security / Security2 Arch protocols
(produced by SecurityStubDxe). In this patch, we hook
DxeTpm2MeasureBootLib into SecurityStubDxe, therefore image dispatch
will try to locate the TCG2 protocol, and measure the image into the
TPM2 chip with the protocol. Because of step (1), the TCG2 protocol
will always be found and used (assuming a TPM2 chip is present).
--------------
Jiewen, does this look OK?
Thanks!
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
© 2016 - 2025 Red Hat, Inc.