Wiki - https://fedoraproject.org/wiki/Changes/Edk2Security Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-improve-edk2-security-self-contained/142517 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: [[User:kraxel| Gerd Hoffmann]] * Email: kraxel@xxxxxxxxxx == 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 === PcdNullPointerDetectionPropert yMask = 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> == Feedback == == Benefit to Fedora == Improves security of UEFI virtual machines. == Scope == * Proposal owners: ** Update edk2 build configuration accordingly. * Other developers: * Release engineering: [https://pagure.io/releng/issues #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) == == How To Test == Test builds are available from https://copr.fedorainfracloud.org/coprs/kraxel/edk2.testbuilds/ == User Experience == == Dependencies == == 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) == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-announce-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
