Hi,
We will have an EBBR call[1] today, Sep 11, at 15h BST (14h UTC). On the agenda[2] we have a number of pull requests to review:
- #[106]: Recommend usage of partition type GUIDs to find firmware (Heinrich)
- #[107]: Support Armv8-R AArch64 - #[108]: Add smbios tables details - #[109]: Add an extension for UEFI references
Also some discussions topics have been proposed:
- Secure boot with systemd-boot requires EFI_SECURITY_ARCH_PROTOCOL and EFI_SECURITY2_ARCH_PROTOCOL (Heinrich)
- Info: upcoming BBR ECR #634 forbidding some SMCs after ExitBootServices
- "Platform firmware must not implement any SMC calls from the SMCCC Vendor Specific EL3 Monitor range (FIDs 0x8700_0000—0x8700_FFFF and 0xC700_0000—0xC700_FFFF) after ExitBootServices." (info from Jose)
- Should we specify which Devicetree nodes are allowed? (suggested by Sughosh)
Feel free to add to the agenda, directly on the wiki page or by e-mail. We can use this pad[3] for the meeting notes.
Best regards,
Vincent Stehlé System Architect - Arm
[1]: https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 [2]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [3]: https://mensuel.framapad.org/p/ebbr-call-of-sep-11-a368 [106]: https://github.com/ARM-software/ebbr/pull/106 [107]: https://github.com/ARM-software/ebbr/pull/107 [108]: https://github.com/ARM-software/ebbr/pull/108 [109]: https://github.com/ARM-software/ebbr/pull/109
Hello,
On 9/11/23 4:14 AM, Vincent Stehlé wrote:
Hi,
We will have an EBBR call[1] today, Sep 11, at 15h BST (14h UTC). On the agenda[2] we have a number of pull requests to review:
#[106]: Recommend usage of partition type GUIDs to find firmware (Heinrich)
#[107]: Support Armv8-R AArch64
#[108]: Add smbios tables details
#[109]: Add an extension for UEFI references
Also some discussions topics have been proposed:
Secure boot with systemd-boot requires EFI_SECURITY_ARCH_PROTOCOL and EFI_SECURITY2_ARCH_PROTOCOL (Heinrich)
Info: upcoming BBR ECR #634 forbidding some SMCs after ExitBootServices
"Platform firmware must not implement any SMC calls from the SMCCC Vendor Specific EL3 Monitor range (FIDs 0x8700_0000—0x8700_FFFF and 0xC700_0000—0xC700_FFFF) after ExitBootServices." (info from Jose)
I thought EBBR was about making standard OSs compatible. This rule would make Vertical board specific OSes illegal.
The requirement should be something like: Firmware must not require use of any vendor specific SMC calls to function correctly.
If a board specific maintenance app wants to call exist boot services and still use vendor specific SMCs it should be able to.
Likewise if people _want_ to create OS images that only work on one vendors boards they should be able to. That same firmware should still work with an OS that does not use vendor specific SMCs and it should still pass EBBR.
(Can attend today's call but this kind of thinking disturbs me greatly so I wanted to comment.)
Bill
- Should we specify which Devicetree nodes are allowed? (suggested by Sughosh)
Feel free to add to the agenda, directly on the wiki page or by e-mail. We can use this pad[3] for the meeting notes.
Best regards,
Vincent Stehlé System Architect - Arm
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
Hi Bill, All,
- Info: upcoming BBR ECR #634 forbidding some SMCs after
ExitBootServices
- "Platform firmware must not implement any SMC calls from the SMCCC
Vendor
Specific EL3 Monitor range (FIDs 0x8700_0000—0x8700_FFFF and 0xC700_0000—0xC700_FFFF) after ExitBootServices." (info from Jose)
I thought EBBR was about making standard OSs compatible. This rule would make Vertical board specific OSes illegal.
This is specifically about the new SMCCC EL3 monitor range (0x8700_0000—0x8700_FFFF). The FW is still allowed to support vendor specific calls in the SiP, OEM and CPU range after ExitBootServices. Today no OSs have any dependency on the EL3 monitor range. The expectation is that OSs, that intend to run on EBBR compliant platforms, won't create a dependency to FW calls implemented in this new range -- to ensure that's the case, we'll forbid FW to expose those at OS runtime from the start.
Regards, Jose 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
-
Bill Mills -
Jose Marinho -
Vincent Stehlé