Changes/Edk2Security

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.

Summary

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

Owner

• Name: Gerd Hoffmann
• Email: kraxel@redhat.com

Current status

• Targeted release: Fedora Linux 42
• Last updated: 2025-01-13
• [<link to devel-announce post will be added by Wrangler> Announced]
• [<will be assigned by the Wrangler> Discussion thread]
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

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

Unmap zero page

   PcdNullPointerDetectionPropertyMask = 0x03

This will catch NULL pointer dereferences.

edk2 documentation

Detailed description of these PCDs (aka edk2 config options) is here: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/MdeModulePkg.dec

some background information

The big linux NX mess (https://www.kraxel.org/blog/2023/12/uefi-nx-linux-boot/) 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 !!!!

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:

 <os firmware='efi'>
   <type arch='x86_64' machine='q35'>hvm</type>
   <firmware>
     <feature enabled='no' name='secure-boot'/>
   </firmware>
 </os>

Benefit to Fedora

Improves security of UEFI virtual machines.

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:

Upgrade/compatibility impact

For the most part this should be an unnoticed change.

Running outdated guests might require a VM config update, see https://fedoraproject.org/wiki/Changes/Edk2Security#backward_compatibility

Early Testing (Optional)

Do you require 'QA Blueprint' support? Y/N

How To Test

Test builds are available from https://copr.fedorainfracloud.org/coprs/kraxel/edk2.testbuilds/

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

Documentation

N/A (not a System Wide Change)