F42 Change Proposal: Improve edk2 security (self-contained)

Improve edk2 security

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Turn on a few security-related build time options to improve edk2 security.

:link: Owner

:link: Detailed Description

:link: Turn on strict NX checking

PcdDxeNxMemoryProtectionPolicy = 0xC000000000007FD5 PcdSetNxForStack = TRUE PcdImageProtectionPolicy = 0x03

This will partly enforce the NX requirements for secure boot binaries which are in place since 2022, see https://techcommunity.microsoft.com/blog/hardwaredevcenter/updated-uefi-signing-requirements/1062916

:link: Unmap zero page

PcdNullPointerDetectionPropertyMask = 0x03

This will catch NULL pointer dereferences.

:link: edk2 documentation

Detailed description of these PCDs (aka edk2 config options) is here: edk2/MdeModulePkg/MdeModulePkg.dec at master · tianocore/edk2 · GitHub

:link: some background information

The big linux NX mess (W^X in UEFI firmware and the linux boot chain. | 🇺🇦 kraxel’s news) was finally sorted roughly one year ago, so linux kernels and boot loaders released in 2024 should work without any problems with the new firmware builds. Given we had security updates due to a bug in shim versions older than 15.8 all linux distros which are supplied with (security) updates still should have package updates released for shim + grub in 2024. So fully updated linux installs should continue to work fine even with the NX bar raised. Same applies to fully updated windows installs.

The changes will be applied to the edk2 builds which have secure boot support enabled. Using secure boot on a system which is not fully updated is not very useful from a security point of view.

Trying to run outdated boot loaders which are not NX clean might lead to page faults like this:

!!! X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - 00000000 !!!

:link: backward compatibility

The edk2 builds without secure boot support will NOT be changed and will continue to use the less strict configuration which is used in fedora 41 and older for better compatibility with old guests. So if there is a need to run outdated guests this is possible by picking these firmware builds. The libvirt xml for this is:

hvm

:link: Feedback

:link: Benefit to Fedora

Improves security of UEFI virtual machines.

:link: Scope

  • Proposal owners:

    • Update edk2 build configuration accordingly.
  • Other developers:

  • Release engineering: #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

For the most part this should be an unnoticed change.

Running outdated guests might require a VM config update, see Changes/Edk2Security - Fedora Project Wiki

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? Y/N

:link: How To Test

Test builds are available from kraxel/edk2.testbuilds Copr

:link: User Experience

:link: Dependencies

:link: Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No

:link: Documentation

N/A (not a System Wide Change)

:link: Release Notes

Last edited by @amoloney 2025-01-15T23:45:27Z

Last edited by @amoloney 2025-01-15T23:45:27Z

2 Likes

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

I assume since we don’t (yet) sign aarch64 secure boot artifacts, this will not affect aarch64 at all?

This is about rhe firmware for the virtualization host, so guest secure virt support does not matter here :wink:

But we do not have secure boot support for VMs on aarch64 either, so yes, no change for the regular aarch64 firmware images. There already is a build with more strict NX settings in the edk2-experimental sub-rpm, that one will be updated.

This change proposal has now been submitted to FESCo with ticket #3357 for voting.

To find out more, please visit our Changes Policy documentation.