On 5/4/21 3:09 PM, Sami Mujawar wrote:
+EFIAPI[SAMI] ASSERTs will vanish in the release builds. So, I think this needs to be an if condition. If RNDR is not supported RETURN_UNSUPPORTED should be returned.
+ UINT64 Isar0;
+ // Determine RNDR support by examining bits 63:60 of the ISAR0 register returned by
+ // MSR. A non-zero value indicates that the processor supports the RNDR instruction.
+ Isar0 = ArmReadIdIsar0 ();
+ ASSERT ((Isar0 & RNDR_MASK) != 0);
However, it appears thatthe auto generated function ProcessLibraryConstructorList() disregards the error code returned by the constructor (see Build\...\AutoGen.c files). So it looks like the loading operation would continue in release builds despite of an error.
I am not aware if this is the desired behavior or why the status code returned by the constructor is disregarded.
However, this would be a probem in the current case as subsequent calls to generate random numbers will result in an undefined instruction exception.
To prevent this, I think the above check should be done in either
- preferably in ArchGetRandomNumberXX(), which should return an error code EFI_UNSUPPORTED, EFI_NOT_READY or EFI_SUCCESS. However, the impact on IA32/x64 code needs to be evaluated.
I've updated both the x86 and aarch64 code to add checks that the RDRAND and RNDR instructions are supported before trying to use them in GetRandomNumber[16,32,64,128].
However, it causes the X64 CryptoPkg host-based unit tests to fail because UnitTestHostBaseLibAsmCpuid just sets all the OUT parameters to 0, which causes RngDxe to think RDRAND isn't supported.
Should the unit tests be using BaseRngLibTimerLib instead of BaseRngLib? Or should I leave the x86 code as it was, with the ASSERT in the constructor and no further checks at the time of use?