Gerd/Ard,

This is a great topic and shows some of the challenges of tightening up security/enforcing correctness in UEFI.

I wanted to let you know that we have been doing a lot of work in both edk2 firmware and discussing with partners in the Linux community and PC ecosystem.  The Shim and Grub teams have been directly engaged and have code patches that correct a number of problems as well as make their code compliant with even tighter restrictions.   Engineers from redhat, canonical, oracle, and others have all been involved.  Also note Microsoft's UEFI CA now requires submissions to be compliant with a strict set of memory mitigations.  UEFI CA Memory Mitigation Requirements for Signing - Windows drivers | Microsoft Learn and UPDATED: UEFI Signing Requirements - Microsoft Community Hub.  This means any new shim submitted must now meet these requirements.  How long it takes for distros to update to a new shim is still unknown. 

Hopefully sometime in the next few weeks we can prepare a comprehensive set of patches and changes needed in edk2 to implement this strict environment.  One of the relevant changes to this discussion and patch series is we switched the configuration from PCD to hob (mu_basecore/DxeMemoryProtectionSettings.h at release/202208 · microsoft/mu_basecore (github.com)).  This allows our platforms complete control of the config per boot.  Some platforms have compatibility requirements and have implemented code so that when a PF is triggered by incompatible software, it is recorded and then the system rebooted.  On the next boot the platform changes the HOB configuration to be in a more compatible mode (this mode could be measured in a PCR and/or other hints to the user/system of degraded security).  We hope this balance makes compatibility possible but inconvenient and with a less than desirable user experience.  Will this help move the industry, I don't know?

Anyway, rather than a patchwork of changes going into different platforms and components of edk2 I would like to see alignment between x86/arm64 in edk2 and a complete set of changes for edk2.  We have developed a tool and some tests that can capture the memory environment in DXE and export it to then allow a developer to review.  This has identified dozens of problems in edk2 code as well as platform code.  See attached a report file showing a passing report for our q35 qemu based platform.  mu_tiano_platforms/Platforms/QemuQ35Pkg at main · microsoft/mu_tiano_platforms (github.com)  We are still working on getting the equivalent for arm64.   Happy to discuss more if anyone else is interested. 

Thanks

sean

  Hi,

Tried booting grub.efi directly and via shim.efi, on Fedora 37 GA.

In both cases I get a pagefault on linux kernel boot (before any other
message is printed), which I guess happens because the loader places the
linux kernel efi stub in EfiLoaderData memory.

When compiling ovmf with the same pcd value I get the same behavior
on x64, so it's consistently buggy across architectures.

take care,
  Gerd