Hi Laszlo,
After digging dipper,  we found that the EVP_RAND_fetch in "rand_new_seed" and "rand_new_drbg" both got NULL in our case. It's meant the DRBG implementation could 
not be fetched. We also compared it to the case on Linux, and they could both fetched DRBG implementation correctly. Is it possible that the opensslLib 3.0.9 caused any compatibility issues with edk2?  Or has anyone else encountered the same problem with these openssl services?

BR,
Eddie 

Laszlo Ersek <lersek@redhat.com> 於 2024年2月15日 週四 下午7:48寫道:
On 2/15/24 12:09, eddie wang wrote:
> Hi Laszlo,
> Thanks for your reply. How can I enable the DEBUGs at RandomSeed() ? Or
> any suggesting information that I can provide?

Sorry, upon a closer look, I see you had already narrowed it down to
RAND_seed() and RAND_status(), which are direct OpenSSL APIs. So my
suggestion would amount to adding DEBUGs to OpenSSL, such as to
RAND_seed() in
"CryptoPkg/Library/OpensslLib/openssl/crypto/rand/rand_lib.c".

But, I think you may be able to do just that.
"CryptoPkg/Library/Include/CrtLibSupport.h" already includes
<DebugLib.h>, and DebugLib is listed under [LibraryClasses] in each
instance of OpensslLib. So if you modify your
"CryptoPkg/Library/OpensslLib/openssl" submodule directory tree locally,
with the following patch:

| diff --git a/crypto/rand/rand_lib.c b/crypto/rand/rand_lib.c
| index 0fcf4fe3bc1e..e5f105268f52 100644
| --- a/crypto/rand/rand_lib.c
| +++ b/crypto/rand/rand_lib.c
| @@ -257,6 +257,8 @@ void RAND_seed(const void *buf, int num)
|      drbg = RAND_get0_primary(NULL);
|      if (drbg != NULL && num > 0)
|          EVP_RAND_reseed(drbg, 0, NULL, 0, buf, num);
| +
| +    DEBUG ((DEBUG_INFO, "%a: hello\n", __func__));
|  }
|
|  void RAND_add(const void *buf, int num, double randomness)

then you should get usable debug messages -- at least it builds for me.

Inserting DEBUGs like this (over multiple rounds of testing / narrowing)
should lead you to the exact location that is responsible for the
initialization failure.

You mention you have encountered the problem with a UEFI application.
That is relevant for choosing your DebugLib instance. If you already
have a function DebugLib instance for your platform (logging to the
serial port, for example), then just use that.

Otherwise, consider building your UEFI application with a module scope
override in the DSC file, one that resolves DebugLib to

  MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf

or

  MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf

These will send DEBUG messages to the UEFI console or standard error
devices, respectively.

hth
Laszlo

> Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>> 於 2024年2月
> 8日 週四 上午5:03寫道:
>
>     On 2/6/24 08:00, eddie wang wrote:
>     > Hi all,
>     > We had an UEFI application that used the EDK2(2023/12/05), and  we
>     would
>     > like to take advantage of the services in BaseCryptLib .However,
>     the API
>     > in CryptPkg "*RandomSeed()*"(X64, in CryptRandTsc.c) always returned
>     > false because of  the pseudorandom number generator set up failed.
>     I am
>     > not sure this issue is from the *openssl configuration in
>     OpensslLib(we
>     > use the default configuration)* or is from the *openssl 3.0.9*.
>     >
>     > Is there any comments about this issue?
>
>     Can you narrow it down by inserting DEBUGs starting at RandomSeed()
>     [CryptoPkg/Library/BaseCryptLib/Rand/CryptRandTsc.c], and then digging
>     down as necessary?
>
>     Laszlo
>
>
>
>     
>
>

_._,_._,_

Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#115565) | | Mute This Topic | New Topic
Your Subscription | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_