Hi Steven,

I think the issue you have noticed has been observed before.  One workaround 
removes the Memory Protection Protocol before booting.

Another option being considered is in this PR

https://github.com/tianocore/edk2/pull/12781

Please try testing your use case and provide feedback on results and the code 
changes.

Thanks,

Mike


From: [email protected] <[email protected]> On Behalf Of Steven Li via 
groups.io
Sent: Monday, July 27, 2026 3:26 AM
To: [email protected]
Subject: [edk2-devel] [EDKII][RFC] A problem about Image Protection Policy, and 
would like to ask for your suggestions.

Hello all,
I am currently encountering a CPU exception related to the system attempting to 
write to a protected memory location.
!!!! X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID - 00000000 !!!!
ExceptionData - 0000000000000003  I:0 R:0 U:0 W:1 P:1 PK:0 SS:0 SGX:0
RIP  - 000000009F1501B8, CS  - 0000000000000038, RFLAGS - 0000000000010213
RAX  - 0000000088C18000, RCX - 00000000000139CD, RDX - 000000008AEB1418
RBX  - 0000000088BFA080, RSP - 000000009F14E4B8, RBP - 000000009F14E5B9
RSI  - 000000008AEB1418, RDI - 0000000088C18000
R8   - 0000000000000006, R9  - 000000008AF4E285, R10 - 000000009F14E628
R11  - 000000000012FD50, R12 - 0000000000000005, R13 - 0000000088BFA1B0
R14  - 0000000088C18000, R15 - 0000000000000001
DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
GS   - 0000000000000030, SS  - 0000000000000030
CR0  - 0000000080010011, CR2 - 0000000088C18000, CR3 - 000000009EC01000
CR4  - 0000000000000628, CR8 - 0000000000000000
DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 00000000930B0000 0000000000000057, LDTR - 0000000000000000
IDTR - 000000008F2A8018 0000000000000FFF,   TR - 0000000000000048
FXSAVE_STATE - 00000000930AF460
PC 0x00009F1501B8 (0x00009F14F000+0x000011B8) [ 0] DxeCore.pdb
Issue Description
Boot the system into the Setup Menu and select Boot to CentOS. The system 
enters the GRUB menu. Press Esc and enter exit; the system returns to the Setup 
Menu. Select Boot to CentOS again, and the system encounters a CPU exception.
Root Cause

When PcdImageProtectionPolicy is enabled in MdeModulePkg\MdeModulePkg.dec, the 
BIOS protects and unprotects loaded/unloaded images by calling 
ProtectUefiImage() and UnprotectUefiImage() in 
MdeModulePkg\Core\Dxe\Misc\MemoryProtection.c.

The mProtectedImageRecordList is created using Image->Info->ImageBase and 
Image->Info->ImageSize.

When exiting from GRUB, the CentOS shim overwrites the contents of Image->Info. 
As a result, during image unload, the BIOS cannot find the corresponding record 
in mProtectedImageRecordList because the ImageBase no longer matches. 
Consequently, UnprotectUefiImage() is not executed successfully.
When we select Boot to CentOS again, the BIOS allocates memory that is expected 
to be unprotected for loading the image. However, since the previous image was 
never successfully unprotected, this results in a CPU exception.
Possible Solutions

  1.  Restore Image->Info before image unload

After exiting GRUB, the BIOS returns to the point where SetJumpFlag was set in 
CoreStartImage() (MdeModulePkg\Core\Dxe\Image\Image.c).

If we restore Image->Info->ImageBase and Image->Info->ImageSize to their 
original values after SetJumpFlag (using the values that were originally used 
to create mProtectedImageRecordList), UnprotectUefiImage() can successfully 
find the corresponding record and remove the protection. the issue will no 
longer exist.

  1.  Avoid using Image->Info for ProtectUefiImage() and UnprotectUefiImage()

The LOADED_IMAGE_PRIVATE_DATA structure contains other copies of the image 
information, for example:

     *   Image->ImageBasePage / Image->NumberOfPages
     *   Image->ImageContext->ImageAddress / Image->ImageContext->ImageSize

Since the CentOS shim only overwrites Image->Info->ImageBase and 
Image->Info->ImageSize, using one of these alternative fields instead of 
Image->Info to create mProtectedImageRecordList also can get the positive 
result.

  1.  Avoid using the protected memory for allocate memory.
We have not verified this method yet. However, from our observations, the issue 
does not reproduce when the system loads the image from a newly allocated 
memory location.

Thanks,
Steven



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#122051): https://edk2.groups.io/g/devel/message/122051
Mute This Topic: https://groups.io/mt/120470083/21656
Group Owner: [email protected]
Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to