The ESRT support in U-Boot is immature and not ready for mainline. Temporarily remove the ESRT requirement so that platforms can meaningfully conform to EBBR. When ESRT functionality has matured this requirement will can be brought back in.
Signed-off-by: Grant Likely grant.likely@arm.com ---
Hi all,
As described above, I'm proposing ESRT gets dropped for v2.0.x series of EBBR, with the plan to add it back in ebbr-next. Once there are U-Boot releases that have a solid ESRT implementation that works for fwupd, mender.io and possibly Windows Update then I would like to bring it back in. Here's the pull request for the change in github:
https://github.com/ARM-software/ebbr/pull/86
Thoughts?
g.
source/chapter2-uefi.rst | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 092fd1d..4c4cacb 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -467,9 +467,7 @@ EBBR platforms are required to implement either an in-band or an out-of-band fir If firmware update is performed in-band (firmware on the application processor updates itself), then the firmware shall implement the `UpdateCapsule()` runtime service and accept updates in the "Firmware Management Protocol Data Capsule Structure" format as described in [UEFI]_ § 23.3, -"Delivering Capsules Containing Updates to Firmware Management Protocol. [#FMPNote]_ -Firmware is also required to provide an EFI System Resource Table (ESRT). [UEFI]_ § 23.4 -Every firmware image that can be updated in-band must be described in the ESRT. +"Delivering Capsules Containing Updates to Firmware Management Protocol."
If firmware update is performed out-of-band (e.g., by an independent Baseboard Management Controller (BMC), or firmware is provided by a hypervisor), @@ -477,7 +475,6 @@ then the platform is not required to implement the `UpdateCapsule()` runtime ser
`UpdateCapsule()` is only required before `ExitBootServices()` is called.
- .. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem regarding secure storage. OP-TEE's chosen solution is to rely on an OS supplicant agent to perform @@ -488,11 +485,3 @@ then the platform is not required to implement the `UpdateCapsule()` runtime ser during runtime services.
https://optee.readthedocs.io/en/latest/architecture/secure_storage.html - -.. [#FMPNote] The `UpdateCapsule()` runtime service is expected to be suitable - for use by generic firmware update services like fwupd and Windows Update. - Both fwupd and Windows Update read the ESRT table to determine what firmware - can be updated, and use an EFI helper application to call `UpdateCapsule()` - before `ExitBootServices()` is called. - - https://fwupd.org/ -- 2.20.1
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On 26.07.21 16:12, Grant Likely wrote:
The ESRT support in U-Boot is immature and not ready for mainline. Temporarily remove the ESRT requirement so that platforms can meaningfully conform to EBBR. When ESRT functionality has matured this requirement will can be brought back in.
Signed-off-by: Grant Likely grant.likely@arm.com
Hello Grant,
could you, please, share which issues have to be solved.
Best regards
Heinrich
Hi all,
As described above, I'm proposing ESRT gets dropped for v2.0.x series of EBBR, with the plan to add it back in ebbr-next. Once there are U-Boot releases that have a solid ESRT implementation that works for fwupd, mender.io and possibly Windows Update then I would like to bring it back in. Here's the pull request for the change in github:
https://github.com/ARM-software/ebbr/pull/86
Thoughts?
g.
source/chapter2-uefi.rst | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 092fd1d..4c4cacb 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -467,9 +467,7 @@ EBBR platforms are required to implement either an in-band or an out-of-band fir If firmware update is performed in-band (firmware on the application processor updates itself), then the firmware shall implement the `UpdateCapsule()` runtime service and accept updates in the "Firmware Management Protocol Data Capsule Structure" format as described in [UEFI]_ § 23.3, -"Delivering Capsules Containing Updates to Firmware Management Protocol. [#FMPNote]_ -Firmware is also required to provide an EFI System Resource Table (ESRT). [UEFI]_ § 23.4 -Every firmware image that can be updated in-band must be described in the ESRT. +"Delivering Capsules Containing Updates to Firmware Management Protocol."
If firmware update is performed out-of-band (e.g., by an independent Baseboard Management Controller (BMC), or firmware is provided by a hypervisor), @@ -477,7 +475,6 @@ then the platform is not required to implement the `UpdateCapsule()` runtime ser
`UpdateCapsule()` is only required before `ExitBootServices()` is called.
- .. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem regarding secure storage. OP-TEE's chosen solution is to rely on an OS supplicant agent to perform
@@ -488,11 +485,3 @@ then the platform is not required to implement the `UpdateCapsule()` runtime ser during runtime services.
https://optee.readthedocs.io/en/latest/architecture/secure_storage.html
-.. [#FMPNote] The `UpdateCapsule()` runtime service is expected to be suitable
- for use by generic firmware update services like fwupd and Windows Update.
- Both fwupd and Windows Update read the ESRT table to determine what firmware
- can be updated, and use an EFI helper application to call `UpdateCapsule()`
- before `ExitBootServices()` is called.
- https://fwupd.org/
-- 2.20.1
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 26/07/2021 16:44, Heinrich Schuchardt wrote:
On 26.07.21 16:12, Grant Likely wrote:
The ESRT support in U-Boot is immature and not ready for mainline. Temporarily remove the ESRT requirement so that platforms can meaningfully conform to EBBR. When ESRT functionality has matured this requirement will can be brought back in.
Signed-off-by: Grant Likely grant.likely@arm.com
Hello Grant,
could you, please, share which issues have to be solved.
The high level issue is testing with fwupd has only started recently. For the specific problems, Ilias has been working through them and most of them may be solved at this point. However, that doesn't do anything for the folks that are committed to any of the existing release (2021.07 or earlier).
With regard to the SystemReady-IR program, I've received feedback from vendors that even recent releases will not be able to meet EBBR compliance without backporting ESRT patches from mainline. v2021.04 and v2021.01 are both being used in stabilized BSPs from vendors.
I'm comfortable dropping ESRT /for now/ because the integration work with fwupd and other agents hasn't been done. Even if a platform based on current released U-Boot provided an ESRT, it is unlikely that it will work out of the box with fwupd anyway, so the ESRT requirement isn't yet providing any value.
I suggest that ESRT gets brought back in for the next major release of EBBR (in approx 1 year) once integration is tested and we have suitable test cases.
g.
Hi all,
As described above, I'm proposing ESRT gets dropped for v2.0.x series of EBBR, with the plan to add it back in ebbr-next. Once there are U-Boot releases that have a solid ESRT implementation that works for fwupd, mender.io and possibly Windows Update then I would like to bring it back in. Here's the pull request for the change in github:
https://github.com/ARM-software/ebbr/pull/86
Thoughts?
g.
source/chapter2-uefi.rst | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 092fd1d..4c4cacb 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -467,9 +467,7 @@ EBBR platforms are required to implement either an in-band or an out-of-band fir If firmware update is performed in-band (firmware on the application processor updates itself), then the firmware shall implement the `UpdateCapsule()` runtime service and accept updates in the "Firmware Management Protocol Data Capsule Structure" format as described in [UEFI]_ § 23.3, -"Delivering Capsules Containing Updates to Firmware Management Protocol. [#FMPNote]_ -Firmware is also required to provide an EFI System Resource Table (ESRT). [UEFI]_ § 23.4 -Every firmware image that can be updated in-band must be described in the ESRT. +"Delivering Capsules Containing Updates to Firmware Management Protocol."
If firmware update is performed out-of-band (e.g., by an independent Baseboard Management Controller (BMC), or firmware is provided by a hypervisor), @@ -477,7 +475,6 @@ then the platform is not required to implement the `UpdateCapsule()` runtime ser
`UpdateCapsule()` is only required before `ExitBootServices()` is called.
- .. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar
problem regarding secure storage. OP-TEE's chosen solution is to rely on an OS supplicant agent to perform @@ -488,11 +485,3 @@ then the platform is not required to implement the `UpdateCapsule()` runtime ser during runtime services.
https://optee.readthedocs.io/en/latest/architecture/secure_storage.html
-.. [#FMPNote] The `UpdateCapsule()` runtime service is expected to be suitable
- for use by generic firmware update services like fwupd and Windows
Update.
- Both fwupd and Windows Update read the ESRT table to determine
what firmware
- can be updated, and use an EFI helper application to call
`UpdateCapsule()`
- before `ExitBootServices()` is called.
- https://fwupd.org/
-- 2.20.1
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
boot-architecture@lists.linaro.org
-
Grant Likely -
Heinrich Schuchardt