Skip to content

EBBR Notes 2024.12.04

Jump to bottom Edit New page
Vincent Stehlé edited this page Dec 4, 2024 · 1 revision

Attendees

  • Ilias Apalodimas (Linaro)
  • Ard Biesheuvel (Google)
  • Ricardo Salveti (Foundries.io / Qualcomm)
  • Jon Humphreys (Texas Instruments)
  • Etienne Carrière (STMicroelectronics)
  • Vincent Stehlé (Arm)

Heinrich Schuchardt (Canonical) cannot attend today.

Agenda

  • Pull request #135: Prepare for v2.3.0
  • HTTP Boot (Ilias)
  • Changing SetVirtualAddressMap() + ConvertPointer() to optional and not recommended (Ilias)

Notes

  • Changing SetVirtualAddressMap() + ConvertPointer() to optional lead to discussions. Ard kindly gave an extensive technical explanation and a historical recap. Ilias explained where the proposal came from. Heinrich could not attend but he gave some feedback against the proposal on the ML, probably with Windows in mind. We should sync up with him and progress on this topic when everybody agrees.
  • HTTP Boot was only briefly discussed; Ilias should dig further into the UEFI specification's "version" of HTTP Boot.
  • Pull request #135 was accepted (with minor changes), which means that EBBR v2.3.0 should be released soon.

Raw notes

  • Changing SetVirtualAddressMap() + ConvertPointer() to optional and not recommended (Ilias)
    • Ard recommended to stop using SetVirtualAddressMap() already a while ago. Necessitates tracking code, relocation, updating offsets, etc. A source of bugs in general, with a risk of crashes. Functions pointers at the UEFI interface (tables) must be updated. Ideally, would like read-only memory for those. After call to ExitBootServices(), must remap pages RWX before calling SetVirtualAddressMap(), which is the inverse of what one would like to do. Some systems with small address spaces (32b) have to call SetVirtualAddressMap(), but if you can: do not.
    • Ilias raised topic after U-Boot modifications to use generic LMB memory allocation in UEFI subsystem. On x86, ended up executing pages with RW- pages, blew up.
    • On linux AArch64 with more than 48b, SetVirtualAddressMap() is disabled.
      • Except for some Altra systems, which need it.
    • Not calling SetVirtualAddressMap() keeps 1:1 mapping, no ASLR.
      • No ASLR with SetVirtualAddressMap() either anyway.
    • Linux application accessing UEFI variables goes through filesystem worker, then does UEFI calls one at a time. Not much opportunity of abuse.
    • SetVariable(), ResetSystem(), no real other usecase.
      • UpdateCapsule() at runtime; no real user today. Broken on x86 mostly, hence not used on Windows. Even for dependable boot, called during extra reboot (at Boot-time).
    • Heinrich's feedback on the ML: if not SetVirtualAddressMap() "no longer able to boot generic UEFI based operating systems".
      • Likely because of Windows (BSD to be checked).
    • RT_PROPERTIES_TABLE does allow not supporting SetVirtualAddressMap() and ConvertPointer() at runtime.
      • RT_PROPERTIES_TABLE was added to UEFI after SetVirtualAddressMap().
        • And allowing SetVirtualAddressMap() to return UNSUPPORTED when not implemented.
    • Implications of not requiring SetVirtualAddressMap() at runtime in EBBR.
      • Actually, other runtime services such as e.g. GetTime() are already required by Windows, too. (to be verified).
        • Why not aligning all runtime services?
        • ConvertPointer() is not called from the OS anyway, internal to the firmware.
  • HTTP Boot (Ilias)
    • -> Ilias to check the UEFI "version" of HTTP Boot
  • Pull request #135: Prepare for v2.3.0
    • "Too late" for Arm SRS v3.0 anyway.
    • Ricardo would like to align cadence with Arm SystemReady.
      • In principle, SRS releases in Apr & Oct; to intercept, should be out a couple of months before.
    • Etienne; nit': some spaces need alignment.
    • -> accepted for release

Links

Add a custom footer
Add a custom sidebar
Clone this wiki locally