Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StandaloneMmPkg: Call PeCoffLoaderUnloadImage When Unloading Image #10586

Merged
merged 2 commits into from
Jan 9, 2025

Conversation

os-d
Copy link
Contributor

@os-d os-d commented Jan 3, 2025

Description

Today, StandaloneMmCore calls PeCoffLoaderRelocateImage() when loading images, which calls PeCoffLoaderRelocateImageExtraAction(). On AARCH64, this sets the image memory protections accordingly, RO + E on code sections, RW + NX on data sections.

However, if an image fails to start (i.e. its entry point returns a failure) StandaloneMmCore does not call the corresponding PeCoffLoaderUnloadImage, which calls PeCoffLoaderUnloadImageExtraAction, which on AARCH64 undoes the memory protections on the image, setting the whole memory region back to RW + NX. The core then frees this memory and the next allocation attempts to use it, which results in a data abort if a read only memory region is attempted to be written to. Theoretically, other instances of the PeCoffExtraActionLib could take other actions and so regardless of architecture, the contract with the PeCoffLoader should be maintained.

This patch calls PeCoffLoaderUnloadImage when an image's entry point returns a failure, before freeing the image memory. This meets the contract and follows the DXE core behavior:

//
// Unload image, free Image->ImageContext->ModHandle
//
PeCoffLoaderUnloadImage (&Image->ImageContext);

  • Breaking change?
    • Breaking change - Does this PR cause a break in build or boot behavior?
    • Examples: Does it add a new library class or move a module to a different repo.
  • Impacts security?
    • Security - Does this PR have a direct security impact?
    • Examples: Crypto algorithm change or buffer overflow fix.
  • Includes tests?
    • Tests - Does this PR include any explicit test code?
    • Examples: Unit tests or integration tests.

How This Was Tested

Tested on an AARCH64 platform that was crashing in Standalone MM when a driver was unloaded and confirmed that the system could boot after this patch.

Integration Instructions

N/A.

Copy link
Contributor

@samimujawar samimujawar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @os-d,
Thank you for this patch.
I have requested a minor documentation update, With that fixed, this patch looks good to me.

StandaloneMmPkg/Core/Dispatcher.c Show resolved Hide resolved
Today, StandaloneMmCore calls PeCoffLoaderRelocateImage() when loading
images, which calls PeCoffLoaderRelocateImageExtraAction(). On AARCH64,
this sets the image memory protections accordingly, RO + E on code
sections, RW + NX on data sections.

However, if an image fails to start (i.e. its entry point returns a
failure) StandaloneMmCore does not call the corresponding
PeCoffLoaderUnloadImage, which calls PeCoffLoaderUnloadImageExtraAction,
which on AARCH64 undoes the memory protections on the image, setting the
whole memory region back to RW + NX. The core then frees this memory
and the next allocation attempts to use it, which results in a data
abort if a read only memory region is attempted to be written to.
Theoretically, other instances of the PeCoffExtraActionLib could take
other actions and so regardless of architecture, the contract with the
PeCoffLoader should be maintained.

This patch calls PeCoffLoaderUnloadImage when an image's entry point
returns a failure, before freeing the image memory. This meets the
contract and follows the DXE core behavior.

Signed-off-by: Oliver Smith-Denny <[email protected]>
@os-d os-d force-pushed the stmm_dispatcher_unload branch from 3660b3d to 585d528 Compare January 6, 2025 18:12
@os-d
Copy link
Contributor Author

os-d commented Jan 6, 2025

Hi @os-d, Thank you for this patch. I have requested a minor documentation update, With that fixed, this patch looks good to me.

Thanks for the review @samimujawar I have updated the function header

@samimujawar
Copy link
Contributor

@niruiyu, @td36, @jiaxinwu, can someone confirm if this patch is good for X86/x64, please?

@ardbiesheuvel ardbiesheuvel added the push Auto push patch series in PR if all checks pass label Jan 9, 2025
@mergify mergify bot merged commit 21cbba1 into tianocore:master Jan 9, 2025
126 checks passed
@os-d os-d deleted the stmm_dispatcher_unload branch January 9, 2025 16:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
push Auto push patch series in PR if all checks pass
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants