EBBR Notes 2023.09.11 - ARM-software/ebbr GitHub Wiki

Attendees

  • Heinrich Schuchardt (Canonical)
  • Ilias Apalodimas (Linaro)
  • Rob Herring (Arm)
  • Ard Biesheuvel (Google)
  • Etienne Carrière (ST)
  • Sughosh Ganu (Arm)
  • Vincent Stehlé (Arm)

Agenda

  • Pull requests:
    • Continue reviewing pull request #106: Recommend usage of partition type GUIDs to find firmware (Heinrich)
    • Start reviewing pull request #107: Support Armv8-R AArch64
    • Pull request #108: Add smbios tables details (no real requirement change here but should we require SMBIOS?)
    • Pull request #109: Add an extension for UEFI references (this is purely cosmetic but impacts the whole document)
  • 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 (info from Jose)
    • "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."
  • Should we specify which Devicetree nodes are allowed? (suggested by Sughosh)
  • Issues scrub?

Notes

  • Should we specify which Devicetree nodes are allowed?
    • Discussion on unspecified Devicetree nodes, etc.
    • No clear consensus on adding more Devicetree requirements in EBBR.
  • Pull request #107: Support Armv8-R AArch64
    • Discussion on Armv8-R AArch64 and AArch32 Hyp mode.
    • Instead of adding details in EBBR, which could conflict with UEFI, try to push modifications to the UEFI specification.
  • Info of upcoming BBR ECR #634 forbidding some SMCs after ExitBootServices
    • Impression that there might be a layering issue (ExitBootServices vs. smc). Specify an exit-boot-services-like smc instead?
  • Other brief discussions on security protocols and set variables at runtime.

Raw notes

  • U-Boot configuration in Devicetree
    • Nodes not specified anywhere; do they do any harm? Should we remove those nodes, not defined in (Linux) schema? Not relevant to an OS.
    • Could be out of sync with the schema.
    • Define a node, to ignore by the OS?
    • Define an array (in the bootloader / EFI loader) and drop those nodes not in that array before handing over to the OS.
    • Maintains compatibility.
    • There are bootstage properties, targetting U-Boot and Linux. C.f. SPL/TPL/etc.
    • Is there a spec. defining the schema?
    • No U-Boot schema files, rules in dt-schema.
    • Is there a pdf spec? It does not touch on that aspect at all.
    • Becoming more complex; TF-A using DT. Could go away with HOB in the future.
    • Op-tee widevine bindings.
    • Why Linux schema? Hosted in Linux tree for convenience; where the most developers are. BSDs take the DT as is.
    • Practical solution: ignore list.
    • Intel, RISC-V defining test suite. Some boot with Devicetree, too.
    • Not clear if EBBR is the right place to standardize.
    • Do not disallow nodes, rather require the mandatory ones ("outside of that you can do whatever you want").
  • v8-R64
    • Update UEFI spec to allow v8-R64; should be the preferred solution.
    • Need to standardize S-EL2 PMSA in UEFI in that case not clear.
    • EFI apps could re-program the MMU.
    • Need for S-EL1 clearer.
    • When dropping EL, problem of going back to higher EL.
    • C.f. AArch32.
    • AArch32 Hyp mode prevented by UEFI; try to remove enough from UEFI to allow Hyp instead of doing that in EBBR.
    • Bottom line: fix UEFI. Avoid conflicting specifications.
  • Security protocols
    • Not UEFI, PI.
  • SMC
    • SMC <-> exit boot services
    • Layering mismatch?
    • StMM is notified
    • Tie it to an smc (instead EBS)
  • Set Variable at Runtime
    • Add wording that OS may/should override (some of) the runtime services
    • Patches for v6.7?
    • Windows also goes around the UEFI spec. for that on Arm
    • Not sure if there is value mentioning impl. details in EBBR

Links

Add a custom footer
⚠️ **GitHub.com Fallback** ⚠️