The GetRandomNumber functions in DxeRngLib can return success without
actually generating a random number. This occurs because there are code
paths through `GenerateRandomNumberViaNist800Algorithm` that do not
initialize the `Status` variable.
- Assume mFirstAlgo == MAX_UINTN (no secure algorithms available)
- Assume none of the secure algorithms have `Available` set.
- Assume PcdEnforceSecureRngAlgorithms is TRUE.
In this condition, the `Status` variable is never initialized, `Buffer`
data is never touched. It is fairly likely that Status is 0, so we can
return EFI_SUCCESS without writing anything to Buffer.
Fix is to set `Status = error_code` in this code path.
`EFI_SECURITY_VIOLATION` seems appropriate.
Signed-off-by: Doug Cook <idigdoug@gmail.com>
With mSecureHashAlgorithms being static this should not be
needed any more.
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
DxeRngLib iterates over a list of secure algorithms before trying
to use the default algorithm provided by the Rng protocol. Add
gEfiRngAlgorithmArmRndr to this list. The algorithm represented by
this GUID is a secure DRBG of an unknown type, implemented by the
aarch64 RNDR instruction.
On AARCH64 platform, use the RNDR instruction as the first option
if it is available.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Use PcdEnforceSecureRngAlgorithms to allow using the Rng protocol
with the default algorithm. All previous call to the Rng protocol
are requesting a secure Rng algorithm.
Not specifying the Rng algorithm GUID to use is considered unsecure.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Add a library constructor which:
- locate the RNG prototocol and keep a reference to it in order to avoid
locating it multiple times (for each random number generation)
- check which secure algorithm is available on the platform.
This avoids to try each secure algorithm until finding one
available for each random number generation call.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The EFI_RNG_PROTOCOL can use the RngLib. The RngLib has multiple
implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
To allow the RngDxe to detect when such implementation is used,
add a GetRngGuid() function to the RngLib.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
The DxeRngLib tries to generate a random number using the 3 NIST
SP 800-90 compliant DRBG algorithms, i.e. 256-bits CTR, HASH and HMAC.
If none of the call is successful, the fallback option is the default
RNG algorithm of the EFI_RNG_PROTOCOL. This default algorithm might
be an unsafe implementation.
Try requesting the Raw algorithm before requesting the default one.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
MdePkg.
Visual Studio versions before VS 2015 don't support __func__ and so
will fail to compile. A workaround is to define __func__ as
__FUNCTION__ :
#define __func__ __FUNCTION__
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737
Apply uncrustify changes to .c/.h files in the MdePkg package
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The Raspberry Pi platform with Secure Boot enabled currently fails to build
with error:
Module type [DXE_RUNTIME_DRIVER] is not supported by library instance
[/home/appveyor/projects/rpi4/edk2/MdePkg/Library/DxeRngLib/DxeRngLib.inf]
Add the missing class to fix this issue.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
This adds a RngLib that uses the RngProtocol to provide randomness.
This means that the RngLib is meant to be used with DXE_DRIVERS.
Ref: https://github.com/tianocore/edk2/pull/845
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1871
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Matthew Carlson <matthewfcarlson@gmail.com>
Doug Cook (WINDOWS)
Gerd Hoffmann
Pierre Gondois
Rebecca Cran
Michael Kubacki
Pete Batard
Matthew Carlson