[edk2-devel] [PATCH v3 03/16] ArmVirtPkg: make EFI_LOADER_DATA non-executable
Sean
spbrogan at outlook.com
Fri Jan 6 02:19:14 UTC 2023
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
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98047): https://edk2.groups.io/g/devel/message/98047
Mute This Topic: https://groups.io/mt/93922691/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20230105/fa433cd8/attachment-0001.htm>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20230105/fa433cd8/attachment-0001.html>
More information about the edk2-devel-archive
mailing list