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): https://edk2.groups.io/g/devel/message/115565
Mute This Topic: https://groups.io/mt/104198931/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-