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

[CHERRY-PICK] UefiCpuPkg: x86 CpuDxe: Allocate AP Exception Stack Below 4GB #1246

Merged
merged 1 commit into from
Dec 18, 2024

Conversation

os-d
Copy link
Contributor

@os-d os-d commented Dec 18, 2024

Description

When setting up the APs' exception stacks, the x86 CpuDxe allocates any range and then copies over the existing GDT and IDT and adds the appropriate new entries for this AP, then installs them.

This can cause an issue if the allocated buffer is over 4GB because the next time the AP is started, it goes through an INIT-SIPI-SIPI, stepping through real mode -> protected mode -> long mode and when it is in protected mode it needs a 32 code segment descriptor or else it will fault when trying to execute. If the GDT lives above 4GB, it cannot be accessed by the protected mode code and the triple fault is seen.

This patch updates CpuDxe's MP management code to allocate the exception stacks for all APs below 4GB explicitly to avoid this problem, such as it does with the BSP's GDT that first gets populated to the APs.

Cherry-picked from: tianocore/edk2@924780f

  • Impacts functionality?
  • Impacts security?
  • Breaking change?
  • Includes tests?
  • Includes documentation?
  • Backport to release branch?

How This Was Tested

Tested on a platform that had allocated the AP exception stacks above 4GB and so triple faulted. It booted after this patch.

Integration Instructions

N/A.

…ow 4GB

When setting up the APs' exception stacks, the x86 CpuDxe allocates
any range and then copies over the existing GDT and IDT and adds the
appropriate new entries for this AP, then installs them.

This can cause an issue if the allocated buffer is over 4GB because
the next time the AP is started, it goes through an INIT-SIPI-SIPI,
stepping through real mode -> protected mode -> long mode and when it
is in protected mode it needs a 32 code segment descriptor or else it
will fault when trying to execute. If the GDT lives above 4GB, it
cannot be accessed by the protected mode code and the triple fault
is seen.

This patch updates CpuDxe's MP management code to allocate the
exception stacks for all APs below 4GB explicitly to avoid this
problem, such as it does with the BSP's GDT that first gets
populated to the APs.

Signed-off-by: Oliver Smith-Denny <[email protected]>
Copy link

@vincent-j-zimmer vincent-j-zimmer left a comment

Choose a reason for hiding this comment

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

This change looks reasonable.

@codecov-commenter
Copy link

codecov-commenter commented Dec 18, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 1.60%. Comparing base (33473bd) to head (92070fb).

Additional details and impacted files
@@              Coverage Diff               @@
##           dev/202405    #1246      +/-   ##
==============================================
- Coverage        1.60%    1.60%   -0.01%     
==============================================
  Files            1377     1377              
  Lines          359246   359259      +13     
  Branches         5524     5524              
==============================================
  Hits             5760     5760              
- Misses         353379   353392      +13     
  Partials          107      107              
Flag Coverage Δ
UefiCpuPkg 4.75% <ø> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@os-d os-d merged commit a40e166 into microsoft:dev/202405 Dec 18, 2024
31 checks passed
@os-d os-d deleted the ex_cp branch December 18, 2024 16:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants