Requirements of PI API's for Boot Specification

[vincentjzimmer]

I would recommend not requiring the EFI_SECURITY_ARCH_PROTOCOL and EFI_SECURITY2_ARCH_PROTOCOL in the boot specification section 5.1. The PI interfaces should be opaque to 3rd party extensible pre-OS UEFI Drivers and Applications. UEFI can be implemented upon a non-PI based codebase. Also, a PI codebase could also uninstall PI interfaces from the protocol database in order to provide least-privilege during the extensible UEFI execution pre-OS phase, too.

Instead of this conflict w/ UEFI Forum advocacy of not requiring PI for UEFI since the early 2000's, I would recommend filing a defect against system-d to remove this usage and/or a defect against the UEFI spec to provide comparable API in the UEFI phase to avoid this potential bypass of the platform's secure boot logic via this use of these PI API's during UEFI.

Given this usage pre-dates the RISC-V work and the ARM boot specs did not make this requirement I am surprised it appears as part of the RISC-V specific collateral.

[adurbin-rivos]

@xypron originally made this request. @vincentjzimmer can you engage w/ system-d folks? Or maybe @xypron can?

[xypron]

I don't remember when and why implementing the protocols was changed from a recommendation to a must. The idea was to be compatible with systemd-boot.

My distribution viewpoint is that it is preferable that RISC-V firmware allows users to install alternative OS distributions without maintaining the security data base.

The current solution to this is having a shim binary signed by a common trusted party (Microsoft for ARM and x86). This shim binary checks the next stage boot binary.

The current shim binary loads the next stage boot-loader, e.g. GRUB or systemd-boot which are signed by distro-specific keys. Shim and the distro supplied GRUB (not the upstream one) reimplement LoadImage() and StartImage() to bypass the firmware implementation. This only works because UEFI implementations have a security gap: AllocatePages() provides memory which is writable and executable (RWX).

Systemd-boot does not reimplement LoadImage() and StartImage() but overrides the EFI_SECURITY_ARCH_PROTOCOL and EFI_SECURITY2_ARCH_PROTOCOL. This avoids the additional attack surface of reimplementing a lot of code and requiring RWX. Overriding the protocols by patching function pointers is relying on non-specified behavior. Only if the firmware's LoadImage() reopens the protocol interface it will find out about the changed function pointers.

It would be preferable if the UEFI specification would supply a clean path for dynamically extending the security data base checks.

For the BRS specification I am fine with changing the requirement to a recommendation or side note.

[andreiw]

Okay so let's go with a normative recommendation then.

It sounds like on the UEFI Spec front, we're asking for an interface for a signed boot loader to temporarily enroll additional keys?

[andreiw]

Reopening issue as we still need to figure out the long term journey here...