Re: [edk2-devel] [PATCH v3 03/16] ArmVirtPkg: make EFI_LOADER_DATA non-executable

["Sean" <spbrogan@outlook.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3598 bytes --]

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 
<https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/uefi-ca-memory-mitigation-requirements> 
and UPDATED: UEFI Signing Requirements - Microsoft Community Hub 
<https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916>.  
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) 
<https://github.com/microsoft/mu_basecore/blob/release/202208/MdeModulePkg/Include/Guid/DxeMemoryProtectionSettings.h>). 
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) 
<https://github.com/microsoft/mu_tiano_platforms/tree/main/Platforms/QemuQ35Pkg>  
We are still working on getting the equivalent for arm64.   Happy to 
discuss more if anyone else is interested.


Thanks

sean



On 1/5/2023 11:58 AM, Gerd Hoffmann wrote:
>    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
>
>
>
> 
>
>

[-- Attachment #1.2: Type: text/html, Size: 4596 bytes --]

[-- Attachment #2: Q35_Paging_Audit_With_Stack_Null.html --]
[-- Type: text/html, Size: 4052714 bytes --]