Misc fixes for EDK2 #9

ColinIanKing · 2015-04-28T17:41:51Z

Found a couple of minor issues when statically analysing EDK2. I've re-issued the pull request because I forgot to add the "Contributed-under:" tag in the original commit messages.

…ariable. Variable n is not yet initialized when the _DIAGASSERT() check is performed on it, which means any old garbage in n may or may not cause the assert to occur. I believe this is a cut-n-paste error from vsnprintf() where n is used as a paramater, where as vsnprintf_ss() does not. Fix this by not asserting on n. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Colin Ian King <[email protected]>

rrecp has been allocated but is not freed on the error return path if the strdup fails. This is a minor memory leak that is easily fixed by free'ing rrecp on the error return. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Colin Ian King <[email protected]>

HiKey: change usb download limit to 500M per time

jljusten · 2015-07-26T00:41:28Z

These patches should be posted to edk2-devel with git send-email. We can't use pull requests at this time.

Commit bd3fc81 ("ShellPkg/App: Fix memory leak and save resources.", 2016-05-20) added a FreePool() call for Split->SplitStdIn, near end of the RunSplitCommand(), right after the same shell file was closed with CloseFile(). The argument was: > 1) RunSplitCommand() allocates the initial SplitStdOut via > CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix > the memory leak. There is no memory leak actually, and the FreePool() call in question constitutes a double-free: (a) This is how the handle is established: ConvertEfiFileProtocolToShellHandle ( CreateFileInterfaceMem (Unicode), NULL ); CreateFileInterfaceMem() allocates an EFI_FILE_PROTOCOL_MEM object and populates it fully. ConvertEfiFileProtocolToShellHandle() allocates some administrative structures and links the EFI_FILE_PROTOCOL_MEM object into "mFileHandleList". (b) EFI_SHELL_PROTOCOL.CloseFile() is required to close the SHELL_FILE_HANDLE and to release all associated data. Accordingly, near the end of RunSplitCommand(), we have: EfiShellClose() ShellFileHandleRemove() // // undoes the effects of ConvertEfiFileProtocolToShellHandle() // ConvertShellHandleToEfiFileProtocol() // // note that this does not adjust the pointer value; it's a pure // type cast // FileHandleClose() FileInterfaceMemClose() // // tears down EFI_FILE_PROTOCOL_MEM completely, undoing the // effects of CreateFileInterfaceMem () // The FreePool() call added by bd3fc81 conflicts with SHELL_FREE_NON_NULL(This); in FileInterfaceMemClose(), so remove it. This error can be reproduced for example with: > Shell> map | more > 'more' is not recognized as an internal or external command, operable > program, or script file. which triggers: > ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(624): CR has Bad Signature with the following stack dump: > #0 0x000000007f6dc094 in CpuDeadLoop () at > MdePkg/Library/BaseLib/CpuDeadLoop.c:37 > #1 0x000000007f6dd1b4 in DebugAssert (FileName=0x7f6ed9f0 > "MdeModulePkg/Core/Dxe/Mem/Pool.c", LineNumber=624, > Description=0x7f6ed9d8 "CR has Bad Signature") at > OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c:153 > #2 0x000000007f6d075d in CoreFreePoolI (Buffer=0x7e232c98, > PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:624 > tianocore#3 0x000000007f6d060e in CoreInternalFreePool (Buffer=0x7e232c98, > PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:529 > tianocore#4 0x000000007f6d0648 in CoreFreePool (Buffer=0x7e232c98) at > MdeModulePkg/Core/Dxe/Mem/Pool.c:552 > tianocore#5 0x000000007d49fbf8 in FreePool (Buffer=0x7e232c98) at > MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:818 > tianocore#6 0x000000007d4875c3 in RunSplitCommand (CmdLine=0x7d898398, > StdIn=0x0, StdOut=0x0) at ShellPkg/Application/Shell/Shell.c:1813 > tianocore#7 0x000000007d487d59 in ProcessNewSplitCommandLine > (CmdLine=0x7d898398) at ShellPkg/Application/Shell/Shell.c:2121 > tianocore#8 0x000000007d488937 in RunShellCommand (CmdLine=0x7e233018, > CommandStatus=0x0) at ShellPkg/Application/Shell/Shell.c:2670 > tianocore#9 0x000000007d488b0b in RunCommand (CmdLine=0x7e233018) at > ShellPkg/Application/Shell/Shell.c:2732 > tianocore#10 0x000000007d4867c8 in DoShellPrompt () at > ShellPkg/Application/Shell/Shell.c:1349 > tianocore#11 0x000000007d48524d in UefiMain (ImageHandle=0x7e24c898, > SystemTable=0x7f5b6018) at ShellPkg/Application/Shell/Shell.c:631 Cc: Jaben Carsey <[email protected]> Cc: Marvin Häuser <[email protected]> Cc: Qiu Shumin <[email protected]> Cc: Ruiyu Ni <[email protected]> Fixes: bd3fc81 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <[email protected]>

Commit bd3fc81 ("ShellPkg/App: Fix memory leak and save resources.", 2016-05-20) added a FreePool() call for Split->SplitStdIn, near end of the RunSplitCommand(), right after the same shell file was closed with CloseFile(). The argument was: > 1) RunSplitCommand() allocates the initial SplitStdOut via > CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix > the memory leak. There is no memory leak actually, and the FreePool() call in question constitutes a double-free: (a) This is how the handle is established: ConvertEfiFileProtocolToShellHandle ( CreateFileInterfaceMem (Unicode), NULL ); CreateFileInterfaceMem() allocates an EFI_FILE_PROTOCOL_MEM object and populates it fully. ConvertEfiFileProtocolToShellHandle() allocates some administrative structures and links the EFI_FILE_PROTOCOL_MEM object into "mFileHandleList". (b) EFI_SHELL_PROTOCOL.CloseFile() is required to close the SHELL_FILE_HANDLE and to release all associated data. Accordingly, near the end of RunSplitCommand(), we have: EfiShellClose() ShellFileHandleRemove() // // undoes the effects of ConvertEfiFileProtocolToShellHandle() // ConvertShellHandleToEfiFileProtocol() // // note that this does not adjust the pointer value; it's a pure // type cast // FileHandleClose() FileInterfaceMemClose() // // tears down EFI_FILE_PROTOCOL_MEM completely, undoing the // effects of CreateFileInterfaceMem () // The FreePool() call added by bd3fc81 conflicts with SHELL_FREE_NON_NULL(This); in FileInterfaceMemClose(), so remove it. This error can be reproduced for example with: > Shell> map | more > 'more' is not recognized as an internal or external command, operable > program, or script file. which triggers: > ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(624): CR has Bad Signature with the following stack dump: > #0 0x000000007f6dc094 in CpuDeadLoop () at > MdePkg/Library/BaseLib/CpuDeadLoop.c:37 > #1 0x000000007f6dd1b4 in DebugAssert (FileName=0x7f6ed9f0 > "MdeModulePkg/Core/Dxe/Mem/Pool.c", LineNumber=624, > Description=0x7f6ed9d8 "CR has Bad Signature") at > OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c:153 > #2 0x000000007f6d075d in CoreFreePoolI (Buffer=0x7e232c98, > PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:624 > #3 0x000000007f6d060e in CoreInternalFreePool (Buffer=0x7e232c98, > PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:529 > #4 0x000000007f6d0648 in CoreFreePool (Buffer=0x7e232c98) at > MdeModulePkg/Core/Dxe/Mem/Pool.c:552 > #5 0x000000007d49fbf8 in FreePool (Buffer=0x7e232c98) at > MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:818 > #6 0x000000007d4875c3 in RunSplitCommand (CmdLine=0x7d898398, > StdIn=0x0, StdOut=0x0) at ShellPkg/Application/Shell/Shell.c:1813 > #7 0x000000007d487d59 in ProcessNewSplitCommandLine > (CmdLine=0x7d898398) at ShellPkg/Application/Shell/Shell.c:2121 > #8 0x000000007d488937 in RunShellCommand (CmdLine=0x7e233018, > CommandStatus=0x0) at ShellPkg/Application/Shell/Shell.c:2670 > #9 0x000000007d488b0b in RunCommand (CmdLine=0x7e233018) at > ShellPkg/Application/Shell/Shell.c:2732 > #10 0x000000007d4867c8 in DoShellPrompt () at > ShellPkg/Application/Shell/Shell.c:1349 > #11 0x000000007d48524d in UefiMain (ImageHandle=0x7e24c898, > SystemTable=0x7f5b6018) at ShellPkg/Application/Shell/Shell.c:631 Cc: Jaben Carsey <[email protected]> Cc: Marvin Häuser <[email protected]> Cc: Qiu Shumin <[email protected]> Cc: Ruiyu Ni <[email protected]> Fixes: bd3fc81 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <[email protected]> Reviewed-by: Jaben Carsey <[email protected]> Reviewed-by: Marvin Häuser <[email protected]>

Commit bd3fc81 ("ShellPkg/App: Fix memory leak and save resources.", 2016-05-20) added a FreePool() call for Split->SplitStdIn, near end of the RunSplitCommand(), right after the same shell file was closed with CloseFile(). The argument was: > 1) RunSplitCommand() allocates the initial SplitStdOut via > CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix > the memory leak. There is no memory leak actually, and the FreePool() call in question constitutes a double-free: (a) This is how the handle is established: ConvertEfiFileProtocolToShellHandle ( CreateFileInterfaceMem (Unicode), NULL ); CreateFileInterfaceMem() allocates an EFI_FILE_PROTOCOL_MEM object and populates it fully. ConvertEfiFileProtocolToShellHandle() allocates some administrative structures and links the EFI_FILE_PROTOCOL_MEM object into "mFileHandleList". (b) EFI_SHELL_PROTOCOL.CloseFile() is required to close the SHELL_FILE_HANDLE and to release all associated data. Accordingly, near the end of RunSplitCommand(), we have: EfiShellClose() ShellFileHandleRemove() // // undoes the effects of ConvertEfiFileProtocolToShellHandle() // ConvertShellHandleToEfiFileProtocol() // // note that this does not adjust the pointer value; it's a pure // type cast // FileHandleClose() FileInterfaceMemClose() // // tears down EFI_FILE_PROTOCOL_MEM completely, undoing the // effects of CreateFileInterfaceMem () // The FreePool() call added by bd3fc81 conflicts with SHELL_FREE_NON_NULL(This); in FileInterfaceMemClose(), so remove it. This error can be reproduced for example with: > Shell> map | more > 'more' is not recognized as an internal or external command, operable > program, or script file. which triggers: > ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(624): CR has Bad Signature with the following stack dump: > #0 0x000000007f6dc094 in CpuDeadLoop () at > MdePkg/Library/BaseLib/CpuDeadLoop.c:37 > #1 0x000000007f6dd1b4 in DebugAssert (FileName=0x7f6ed9f0 > "MdeModulePkg/Core/Dxe/Mem/Pool.c", LineNumber=624, > Description=0x7f6ed9d8 "CR has Bad Signature") at > OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c:153 > #2 0x000000007f6d075d in CoreFreePoolI (Buffer=0x7e232c98, > PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:624 > #3 0x000000007f6d060e in CoreInternalFreePool (Buffer=0x7e232c98, > PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:529 > #4 0x000000007f6d0648 in CoreFreePool (Buffer=0x7e232c98) at > MdeModulePkg/Core/Dxe/Mem/Pool.c:552 > #5 0x000000007d49fbf8 in FreePool (Buffer=0x7e232c98) at > MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:818 > #6 0x000000007d4875c3 in RunSplitCommand (CmdLine=0x7d898398, > StdIn=0x0, StdOut=0x0) at ShellPkg/Application/Shell/Shell.c:1813 > #7 0x000000007d487d59 in ProcessNewSplitCommandLine > (CmdLine=0x7d898398) at ShellPkg/Application/Shell/Shell.c:2121 > #8 0x000000007d488937 in RunShellCommand (CmdLine=0x7e233018, > CommandStatus=0x0) at ShellPkg/Application/Shell/Shell.c:2670 > #9 0x000000007d488b0b in RunCommand (CmdLine=0x7e233018) at > ShellPkg/Application/Shell/Shell.c:2732 > #10 0x000000007d4867c8 in DoShellPrompt () at > ShellPkg/Application/Shell/Shell.c:1349 > #11 0x000000007d48524d in UefiMain (ImageHandle=0x7e24c898, > SystemTable=0x7f5b6018) at ShellPkg/Application/Shell/Shell.c:631 Cc: Jaben Carsey <[email protected]> Cc: Marvin Häuser <[email protected]> Cc: Qiu Shumin <[email protected]> Cc: Ruiyu Ni <[email protected]> Fixes: bd3fc81 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <[email protected]> Reviewed-by: Jaben Carsey <[email protected]> Reviewed-by: Marvin Häuser <[email protected]> (cherry picked from commit 227fe49)

UefiPayloadPkg/Library/PlatformBootManagerLib: Handle Primary Video

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4542 Bug Overview: PixieFail Bug tianocore#9 CVE-2023-45237 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) Use of a Weak PseudoRandom Number Generator Change Overview: Updates all Instances of NET_RANDOM (NetRandomInitSeed ()) to either > > EFI_STATUS > EFIAPI > PseudoRandomU32 ( > OUT UINT32 *Output > ); > or (depending on the use case) > > EFI_STATUS > PseudoRandom ( > OUT VOID *Output, > IN UINTN OutputLength > ); > This is because the use of Example: The following code snippet PseudoRandomU32 () function is used: > > UINT32 Random; > > Status = PseudoRandomU32 (&Random); > if (EFI_ERROR (Status)) { > DEBUG ((DEBUG_ERROR, "%a failed to generate random number: %r\n", __func__, Status)); > return Status; > } > This also introduces a new PCD to enable/disable the use of the NIST SP-800-90 approved algorithms for PseudoRandom () and instead depend on the default implementation. This may be required for some platforms where the UEFI Spec defined algorithms are not available. > > PcdEnforceSecureRngAlgorithms > If the platform does not have the NIST SP-800-90 approved algorithms then the driver will assert. Cc: Saloni Kasbekar <[email protected]> Cc: Zachary Clark-williams <[email protected]> Signed-off-by: Doug Flick [MSFT] <[email protected]>

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4542 Bug Overview: PixieFail Bug tianocore#9 CVE-2023-45237 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) Use of a Weak PseudoRandom Number Generator Change Overview: Updates all Instances of NET_RANDOM (NetRandomInitSeed ()) to either > > EFI_STATUS > EFIAPI > PseudoRandomU32 ( > OUT UINT32 *Output > ); > or (depending on the use case) > > EFI_STATUS > EFIAPI > PseudoRandom ( > OUT VOID *Output, > IN UINTN OutputLength > ); > This is because the use of Example: The following code snippet PseudoRandomU32 () function is used: > > UINT32 Random; > > Status = PseudoRandomU32 (&Random); > if (EFI_ERROR (Status)) { > DEBUG ((DEBUG_ERROR, "%a failed to generate random number: %r\n", __func__, Status)); > return Status; > } > This also introduces a new PCD to enable/disable the use of the NIST SP-800-90 approved algorithms for PseudoRandom () and instead depend on the default implementation. This may be required for some platforms where the UEFI Spec defined algorithms are not available. > > PcdEnforceSecureRngAlgorithms > If the platform does not have the NIST SP-800-90 approved algorithms then the driver will assert. Cc: Saloni Kasbekar <[email protected]> Cc: Zachary Clark-williams <[email protected]> Signed-off-by: Doug Flick [MSFT] <[email protected]>

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4542 Bug Overview: PixieFail Bug tianocore#9 CVE-2023-45237 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) Use of a Weak PseudoRandom Number Generator Change Overview: Updates all Instances of NET_RANDOM (NetRandomInitSeed ()) to either > > EFI_STATUS > EFIAPI > PseudoRandomU32 ( > OUT UINT32 *Output > ); > or (depending on the use case) > > EFI_STATUS > EFIAPI > PseudoRandom ( > OUT VOID *Output, > IN UINTN OutputLength > ); > This is because the use of Example: The following code snippet PseudoRandomU32 () function is used: > > UINT32 Random; > > Status = PseudoRandomU32 (&Random); > if (EFI_ERROR (Status)) { > DEBUG ((DEBUG_ERROR, "%a failed to generate random number: %r\n", __func__, Status)); > return Status; > } > This also introduces a new PCD to enable/disable the use of the secure implementation of algorithms for PseudoRandom () and instead depend on the default implementation. This may be required for some platforms where the UEFI Spec defined algorithms are not available. > > PcdEnforceSecureRngAlgorithms > If the platform does not have any one of the UEFI defined secure RNG algorithms then the driver will assert. Cc: Saloni Kasbekar <[email protected]> Cc: Zachary Clark-williams <[email protected]> Signed-off-by: Doug Flick [MSFT] <[email protected]>

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4542 Bug Overview: PixieFail Bug tianocore#9 CVE-2023-45237 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) Use of a Weak PseudoRandom Number Generator Change Overview: Updates all Instances of NET_RANDOM (NetRandomInitSeed ()) to either > > EFI_STATUS > EFIAPI > PseudoRandomU32 ( > OUT UINT32 *Output > ); > or (depending on the use case) > > EFI_STATUS > EFIAPI > PseudoRandom ( > OUT VOID *Output, > IN UINTN OutputLength > ); > This is because the use of Example: The following code snippet PseudoRandomU32 () function is used: > > UINT32 Random; > > Status = PseudoRandomU32 (&Random); > if (EFI_ERROR (Status)) { > DEBUG ((DEBUG_ERROR, "%a failed to generate random number: %r\n", __func__, Status)); > return Status; > } > This also introduces a new PCD to enable/disable the use of the secure implementation of algorithms for PseudoRandom () and instead depend on the default implementation. This may be required for some platforms where the UEFI Spec defined algorithms are not available. > > PcdEnforceSecureRngAlgorithms > If the platform does not have any one of the UEFI defined secure RNG algorithms then the driver will assert. Cc: Saloni Kasbekar <[email protected]> Cc: Zachary Clark-williams <[email protected]> Signed-off-by: <Doug>

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4542 Bug Overview: PixieFail Bug tianocore#9 CVE-2023-45237 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) Use of a Weak PseudoRandom Number Generator Change Overview: Updates all Instances of NET_RANDOM (NetRandomInitSeed ()) to either > > EFI_STATUS > EFIAPI > PseudoRandomU32 ( > OUT UINT32 *Output > ); > or (depending on the use case) > > EFI_STATUS > EFIAPI > PseudoRandom ( > OUT VOID *Output, > IN UINTN OutputLength > ); > This is because the use of Example: The following code snippet PseudoRandomU32 () function is used: > > UINT32 Random; > > Status = PseudoRandomU32 (&Random); > if (EFI_ERROR (Status)) { > DEBUG ((DEBUG_ERROR, "%a failed to generate random number: %r\n", __func__, Status)); > return Status; > } > This also introduces a new PCD to enable/disable the use of the secure implementation of algorithms for PseudoRandom () and instead depend on the default implementation. This may be required for some platforms where the UEFI Spec defined algorithms are not available. > > PcdEnforceSecureRngAlgorithms > If the platform does not have any one of the UEFI defined secure RNG algorithms then the driver will assert. Cc: Saloni Kasbekar <[email protected]> Cc: Zachary Clark-williams <[email protected]> Signed-off-by: Doug Flick [MSFT] <[email protected]>

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4542 Bug Overview: PixieFail Bug tianocore#9 CVE-2023-45237 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) Use of a Weak PseudoRandom Number Generator Change Overview: Updates all Instances of NET_RANDOM (NetRandomInitSeed ()) to either > > EFI_STATUS > EFIAPI > PseudoRandomU32 ( > OUT UINT32 *Output > ); > or (depending on the use case) > > EFI_STATUS > EFIAPI > PseudoRandom ( > OUT VOID *Output, > IN UINTN OutputLength > ); > This is because the use of Example: The following code snippet PseudoRandomU32 () function is used: > > UINT32 Random; > > Status = PseudoRandomU32 (&Random); > if (EFI_ERROR (Status)) { > DEBUG ((DEBUG_ERROR, "%a failed to generate random number: %r\n", __func__, Status)); > return Status; > } > This also introduces a new PCD to enable/disable the use of the secure implementation of algorithms for PseudoRandom () and instead depend on the default implementation. This may be required for some platforms where the UEFI Spec defined algorithms are not available. > > PcdEnforceSecureRngAlgorithms > If the platform does not have any one of the UEFI defined secure RNG algorithms then the driver will assert. Cc: Saloni Kasbekar <[email protected]> Cc: Zachary Clark-williams <[email protected]> Signed-off-by: Doug Flick [MSFT] <[email protected]> Reviewed-by: Saloni Kasbekar <[email protected]>

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4542 Bug Overview: PixieFail Bug #9 CVE-2023-45237 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) Use of a Weak PseudoRandom Number Generator Change Overview: Updates all Instances of NET_RANDOM (NetRandomInitSeed ()) to either > > EFI_STATUS > EFIAPI > PseudoRandomU32 ( > OUT UINT32 *Output > ); > or (depending on the use case) > > EFI_STATUS > EFIAPI > PseudoRandom ( > OUT VOID *Output, > IN UINTN OutputLength > ); > This is because the use of Example: The following code snippet PseudoRandomU32 () function is used: > > UINT32 Random; > > Status = PseudoRandomU32 (&Random); > if (EFI_ERROR (Status)) { > DEBUG ((DEBUG_ERROR, "%a failed to generate random number: %r\n", __func__, Status)); > return Status; > } > This also introduces a new PCD to enable/disable the use of the secure implementation of algorithms for PseudoRandom () and instead depend on the default implementation. This may be required for some platforms where the UEFI Spec defined algorithms are not available. > > PcdEnforceSecureRngAlgorithms > If the platform does not have any one of the UEFI defined secure RNG algorithms then the driver will assert. Cc: Saloni Kasbekar <[email protected]> Cc: Zachary Clark-williams <[email protected]> Signed-off-by: Doug Flick [MSFT] <[email protected]> Reviewed-by: Saloni Kasbekar <[email protected]>

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 tianocore#6 and tianocore#11 are the basic synchronization requirements for all cases. Steps tianocore#1 and tianocore#2 are additional requirements if the MmCpuSyncModeTradition mode is selected. Steps tianocore#1, tianocore#2, tianocore#3, tianocore#4, tianocore#5, tianocore#7, tianocore#8, tianocore#9, and tianocore#10 are additional requirements if the system needs to configure the MTRR. Steps tianocore#9 and tianocore#10 are additional requirements if the system needs to support the mSmmDebugAgentSupport. Signed-off-by: Jiaxin Wu <[email protected]>

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 tianocore#6 and tianocore#11 are the basic synchronization requirements for all cases. Steps tianocore#1 is additional requirements if the MmCpuSyncModeTradition mode is selected. Steps tianocore#1, tianocore#2, tianocore#3, tianocore#4, tianocore#5, tianocore#7, tianocore#8, tianocore#9, and tianocore#10 are additional requirements if the system needs to configure the MTRR. Steps tianocore#9 and tianocore#10 are additional requirements if the system needs to support the mSmmDebugAgentSupport. Signed-off-by: Jiaxin Wu <[email protected]>

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 <[email protected]>

Colin Ian King added 2 commits April 28, 2015 18:36

vchong pushed a commit to linaro-swg/edk2 that referenced this pull request Jun 9, 2015

Merge pull request tianocore#9 from gaozhangfei/usb

703f01d

HiKey: change usb download limit to 500M per time

jljusten closed this Jul 26, 2015

miczyg1 referenced this pull request in 3mdeb/edk2 Sep 2, 2020

Merge pull request #9 from 9elements/feature/primaryScreen

4e181db

UefiPayloadPkg/Library/PlatformBootManagerLib: Handle Primary Video

mxu9 mentioned this pull request Apr 2, 2022

Introduce TDVF Config-B (basic) in OvmfPkg #2728

Merged

jyao1 mentioned this pull request Feb 3, 2023

Enable Tdx measurement in OvmfPkgX64 #3993

Merged

dhaval-rivos mentioned this pull request Aug 29, 2024

Enable UPL support for RISC-V #6139

Merged

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Misc fixes for EDK2 #9

Misc fixes for EDK2 #9

ColinIanKing commented Apr 28, 2015

jljusten commented Jul 26, 2015

Misc fixes for EDK2 #9

Misc fixes for EDK2 #9

Conversation

ColinIanKing commented Apr 28, 2015

jljusten commented Jul 26, 2015