Tianocore/edk2.git/SecurityPkg/RandomNumberGenerator, branch master

SecurityPkg: Propagate Cryptographic Operation Failures

2026-09-08T18:20:17+00:00

Check and propagate failures in HashLibBaseCryptoRouter and RngDxe. Signed-off-by: Oliver Smith-Denny

SecurityPkg/RngDxe: Support RISCV64

2026-07-17T05:23:45+00:00

Add RISCV64 to the list of valid architectures. Signed-off-by: Tuan Phan

SecurityPkg/RngDxe: Replace Intel-specific with arch-neutral comments

2026-07-17T05:23:45+00:00

The RngDxe driver and its non-AArch64 support files still contained comments and descriptions referring to Intel Secure Key technology, RDRAND/RDSEED instructions, and the Intel DRNG implementation guide. These references are no longer accurate because the driver obtains random data through the platform-provided RngLib abstraction rather than relying on Intel-specific CPU features. Update the comments and descriptions to use architecture-neutral language that better reflects the current implementation. Signed-off-by: Tuan Phan

SecurityPkg: Remove redundant section name in inf file

2026-06-03T02:18:39+00:00

[Sources.AARCH64] appears twice in RngDxe.inf, remove the redundant one to make the file more concise. Signed-off-by: Qihang Gao

SecurityPkg: Replace include guards with #pragma once

2026-02-23T21:01:28+00:00

Replace traditional `#ifndef`/`#define`/`#endif` include guards with `#pragma` once. `#pragma once` is a widely supported preprocessor directive that prevents header files from being included multiple times. It is supported by all toolchains used to build edk2: GCC, Clang/LLVM, and MSVC. Compared to macro-based include guards, `#pragma once`: - Eliminates the risk of macro name collisions or copy/paste errors where two headers inadvertently use the same guard macro. - Eliminate inconsistency in the way include guard macros are named (e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.). - Reduces boilerplate (three lines replaced by one). - Avoids polluting the macro namespace with guard symbols. - Can improve build times as the preprocessor can skip re-opening the file entirely, rather than re-reading it to find the matching `#endif` ("multiple-include optimization"). - Note that some compilers may already optimize traditional include guards, by recognzining the idiomatic pattern. This change is made acknowledging that overall portability of the code will technically be reduced, as `#pragma once` is not part of the C/C++ standards. However, this is considered acceptable given: 1. edk2 already defines a subset of supported compilers in BaseTools/Conf/tools_def.template, all of which have supported `#pragma once` for over two decades. 2. There have been concerns raised to the project about inconsistent include guard naming and potential macro collisions. Approximate compiler support dates: - MSVC: Supported since Visual C++ 4.2 (1996) - GCC: Supported since 3.4 (2004) (http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html) - Clang (LLVM based): Since initial release in 2007 Signed-off-by: Michael Kubacki

SecurityPkg: Drop ARM32 Support

2025-09-25T22:04:10+00:00

edk2 is dropping support for the ARM32 architecture. This commit removes ARM32 code in SecurityPkg. Signed-off-by: Oliver Smith-Denny

Revert "SecurityPkg: CodeQL Fixes."

2025-08-12T03:50:30+00:00

This reverts commit ba6a8eb045aededbc1472cce7314ab1911f0ea1c. PR https://github.com/tianocore/edk2/pull/11307 introduced a logic change that caused regressions in FV verification on some platforms. This PR is being reverted to restore the prior logic. The Code QL fixes in https://github.com/tianocore/edk2/pull/11307 can be resubmitted without the logic change along with one commit for each type of Code QL issue being addressed. Signed-off-by: Michael D Kinney

SecurityPkg: CodeQL Fixes.

2025-07-24T01:58:06+00:00

Makes changes to comply with alerts raised by CodeQL. Most of the issues here fall into the following two categories: 1. Potential use of uninitialized pointer. 2. Inconsistent integer width in comparison. Co-authored-by: Taylor Beebe <31827475+TaylorBeebe@users.noreply.github.com> Co-authored-by: kenlautner <85201046+kenlautner@users.noreply.github.com> Co-authored-by: Bret Barkelew Signed-off-by: Doug Flick

SecurityPkg: Add RngPei

2025-02-06T20:29:15+00:00

REF:https://github.com/tianocore/edk2/issues/10529 The `RngPei` PEIM can be used if RNG should be provided over a dynamic binary interface to other PEIMs on a platform. Tested with: - SecurityPkg CI - Verify RNG linked with RngLib is executed as expected - Verify random numbers are generated successfully with a valid RngLib Integration instructions: Use the `RngPei` module if a platform needs to produce `gEfiRngPpiGuid`. The platform should usually link a different `RngLib` instance to `RngPei` than other PEIMs that may use the RNG PPI produced since `RngPei` is responsible for producing the PPI. For example, a `RngLib` instance that uses the rdrand instruction may be linked against `RngPei` and a `RngLib` instance that uses the RNG PPI may be linked against other PEIMs. Signed-off-by: Michael Kubacki

SecurityPkg/RngDxe: fix warning about uninitialized variable

2025-01-29T16:20:57+00:00

ArmTrng.c: In function 'GenerateEntropy': ArmTrng.c:40:15: error: 'Status' may be used uninitialized in this function [-Werror=maybe-uninitialized] EFI_STATUS Status; ^~~~~~ cc1: all warnings being treated as errors Signed-off-by: Mike Maslenkin