Skip to content

Add warning if no bootable media found #7

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.

Sign up for GitHub

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

Jump to bottom
Closed
crawfxrd wants to merge 2 commits into from
Closed

Add warning if no bootable media found #7

crawfxrd wants to merge 2 commits into from

Conversation

@crawfxrd
Copy link
Member

@crawfxrd crawfxrd commented Jan 29, 2020 •
edited
Loading

@crawfxrd crawfxrd requested a review from jackpot51 January 29, 2020 15:02
@crawfxrd crawfxrd force-pushed the no-bootable-media branch 2 times, most recently from 4def8f7 to 74df1c1 Compare January 29, 2020 15:06
@crawfxrd crawfxrd mentioned this pull request Jan 29, 2020
Closed
@jackpot51
Copy link
Member

jackpot51 commented Jan 29, 2020

Tim, we need the warning on One Time Boot as well

@crawfxrd crawfxrd requested a review from jackpot51 January 29, 2020 17:57
@jackpot51
Copy link
Member

jackpot51 commented Jan 29, 2020

Looks good!

@crawfxrd crawfxrd changed the title Add warning to front if no bootable media found Add warning if no bootable media found Jan 30, 2020
@jackpot51
Copy link
Member

jackpot51 commented Apr 17, 2020

Will be fixed by #9

@jackpot51 jackpot51 closed this Apr 17, 2020
@jackpot51 jackpot51 deleted the no-bootable-media branch April 17, 2020 15:43
jackpot51 pushed a commit that referenced this pull request Mar 5, 2024
@Flickdm @mergify
NetworkPkg: UefiPxeBcDxe: SECURITY PATCH CVE-2023-45235 Patch
fac2977 
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4540

Bug Details:
PixieFail Bug #7
CVE-2023-45235
CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
CWE-119 Improper Restriction of Operations within the Bounds of
 a Memory Buffer

Buffer overflow when handling Server ID option from a DHCPv6 proxy
Advertise message

Change Overview:

Performs two checks

1. Checks that the length of the duid is accurate
> + //
> + // Check that the minimum and maximum requirements are met
> + //
> + if ((OpLen < PXEBC_MIN_SIZE_OF_DUID) ||
(OpLen > PXEBC_MAX_SIZE_OF_DUID)) {
> +  Status = EFI_INVALID_PARAMETER;
> +  goto ON_ERROR;
> + }

2. Ensures that the amount of data written to the buffer is tracked and
never exceeds that
> + //
> + // Check that the option length is valid.
> + //
> + if ((DiscoverLen + OpLen + PXEBC_COMBINED_SIZE_OF_OPT_CODE_AND_LEN)
 > DiscoverLenNeeded) {
> +     Status = EFI_OUT_OF_RESOURCES;
> +     goto ON_ERROR;
> + }

Additional code clean up and fix for memory leak in case Option was NULL

Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>

Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com>
crawfxrd pushed a commit that referenced this pull request Nov 19, 2024
@mergify
UefiCpuPkg/PiSmmCpuDxeSmm: Clarification for BSP & APs Sync Flow
2351165 
This patch does not impact functionality. It aims to clarify the
synchronization flow between the BSP and APs to enhance code
readability and understanding:

Steps #6 and #11 are the basic synchronization requirements for all
cases.

Steps #1 is additional requirements if the MmCpuSyncModeTradition
mode is selected.

Steps #1, #2, #3, #4, #5, #7, #8, #9, and #10 are additional
requirements if the system needs to configure the MTRR.

Steps #9 and #10 are additional requirements if the system needs to
support the mSmmDebugAgentSupport.

Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
crawfxrd pushed a commit that referenced this pull request Jun 23, 2025
@xuweiintel @mergify
UefiCpuPkg/PiSmmCpuDxeSmm: Add sync barrier before BSP invokes SmmCor…
bbee92c 
…eEntry

This patch introduces a synchronization point between the BSP and APs to
ensure all APs have entered their SMM wait-loop (while (TRUE) in APHandler
()) before the BSP calls into the SMI handler logic via gSmmCpuPrivate
->SmmCoreEntry().

Previously, the BSP would invoke ReleaseAllAPs() and immediately proceed
to SmmCoreEntry() without confirming whether APs had reached the stable
waiting state. If SmmStartupThisAp() was called inside the SMI handler
shortly after ReleaseAllAPs(), it might lead to a race condition:
APs are issued two consecutive wait signals (SmmCpuSyncWaitForBsp()).
BSP sends two consecutive releases (ReleaseAllAPs() + SmmStartupThisAp())
If an AP has not yet responded to the first release, the second release may
overwrite the semaphore state, and the AP might miss the notification,
causing it to hang or behave unpredictably.

To address this:
A SmmCpuSyncWaitForAPs() is added in BSP after
mmCpuPlatformHookBeforeMmiHandler() and before entering SmmCoreEntry().
A matching SmmCpuSyncReleaseBsp() is added in AP immediately after its own
SmmCpuPlatformHookBeforeMmiHandler()

This ensures that BSP does not enter SMI handler logic or dispatch any
AP-related requests before all APs are confirmed to be idle and ready.
Debug sync point markers (e.g., /// #6, #7) are updated accordingly.
This change eliminates a subtle but critical race condition in
multi-processor/multi-socket systems during SMM entry and improves overall
synchronization safety.

Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
crawfxrd pushed a commit that referenced this pull request Jul 8, 2025
@xuweiintel @mergify
UefiCpuPkg/PiSmmCpuDxeSmm: Add sync barrier before BSP invokes SmmCor…
d493647 
…eEntry

This patch introduces a synchronization point between the BSP and APs to
ensure all APs have entered their SMM wait-loop (while (TRUE) in APHandler
()) before the BSP calls into the SMI handler logic via gSmmCpuPrivate
->SmmCoreEntry().

Previously, the BSP would invoke ReleaseAllAPs() and immediately proceed
to SmmCoreEntry() without confirming whether APs had reached the stable
waiting state. If SmmStartupThisAp() was called inside the SMI handler
shortly after ReleaseAllAPs(), it might lead to a race condition:
APs are issued two consecutive wait signals (SmmCpuSyncWaitForBsp()).
BSP sends two consecutive releases (ReleaseAllAPs() + SmmStartupThisAp())
If an AP has not yet responded to the first release, the second release may
overwrite the semaphore state, and the AP might miss the notification,
causing it to hang or behave unpredictably.

To address this:
A SmmCpuSyncWaitForAPs() is added in BSP after
mmCpuPlatformHookBeforeMmiHandler() and before entering SmmCoreEntry().
A matching SmmCpuSyncReleaseBsp() is added in AP immediately after its own
SmmCpuPlatformHookBeforeMmiHandler()

This ensures that BSP does not enter SMI handler logic or dispatch any
AP-related requests before all APs are confirmed to be idle and ready.
Debug sync point markers (e.g., /// #6, #7) are updated accordingly.
This change eliminates a subtle but critical race condition in
multi-processor/multi-socket systems during SMM entry and improves overall
synchronization safety.

Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@jackpot51 jackpot51 jackpot51 approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Handle case of having no bootable disk installed

2 participants

@crawfxrd @jackpot51