Re: [edk2-devel] [PATCH v2 5/6] CryptoPkg: Upgrade OpenSSL to 1.1.1b

["Laszlo Ersek" <lersek@redhat.com>]

Hi Jian,

On 05/14/19 09:03, Wang, Jian J wrote:
>> -----Original Message-----
>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>> Sent: Tuesday, May 14, 2019 12:15 AM
>> To: devel@edk2.groups.io; Wang, Jian J <jian.j.wang@intel.com>; Lu, XiaoyuX
>> <xiaoyux.lu@intel.com>
>> Cc: Ye, Ting <ting.ye@intel.com>
>> Subject: Re: [edk2-devel] [PATCH v2 5/6] CryptoPkg: Upgrade OpenSSL to 1.1.1b

>> Honestly the best I could suggest is, "use RDRAND if available, fall
>> back to TimerLib otherwise". :( But I would understand if you wanted to
>> postpone RDRAND until later.

> Actually we wanted to use hardware seed/rand generator at first. I
> thought it might not be acceptable due to the fact it's processor
> dependent. So we hesitated. My understanding to above comment
> is that you agree to use rdrand/rdseed if available and fall back to
> TimerLib otherwise, right?

I've now tried to read up a little bit on RDRAND. It seems that crypto
folks do not universally trust RDRAND. Some people reject RDRAND
completely, while others are willing to use RDRAND as *one* source for
entropy, but they always mix it with other entropy sources. But even
that practice is not acceptable to some people, saying that RDRAND can
be used to compromise those other entropy sources, dependent on the
mixing details. It seems that FreeBSD at the least uses the Yarrow
algorithm for mixing, which comes with its own complexities.

As much as I dislike it, at the moment I cannot recommend anything
better than just TimerLib. I'm not satisfied with TimerLib, but I don't
know enough to suggest an improvement. RDRAND looked like a good entropy
source, but then reading up on people's opinions on it, gave me pause.

In the longer term, I believe a serious reorganization of BaseCryptLib /
OpensslLib / etc might help. Namely, move the seeding / entropy
collection out of these low-level libraries, and force all dependent
modules (drivers and such) to provide their own entropy.

Then, privileged drivers (e.g. SMM drivers) could use a low-level
platform device for collecting randomness, without depending on 3rd
party UEFI drivers. Less privileged drivers (such as for HTTPS boot)
could perhaps consume EFI_RNG_PROTOCOL, or maybe some protocol /
abstraction exposed by TPM drivers.

I guess it's OK if we stick with TimerLib for this OpenSSL version upgrade.

Can we please document the use of platform timers as entropy sources
(including the TSC) in the following wiki article?

https://github.com/tianocore/tianocore.github.io/wiki/CryptoPkg

I'm not asking for many details, just a short summary of the fact and
why we do this.

Thanks
Laszlo