From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Tue, 14 May 2019 03:58:39 -0700 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C88223082B40; Tue, 14 May 2019 10:58:38 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-233.rdu2.redhat.com [10.10.120.233]) by smtp.corp.redhat.com (Postfix) with ESMTP id AB7D060BE5; Tue, 14 May 2019 10:58:37 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v2 5/6] CryptoPkg: Upgrade OpenSSL to 1.1.1b To: "Wang, Jian J" , "devel@edk2.groups.io" , "Lu, XiaoyuX" Cc: "Ye, Ting" References: <1557379429-7527-1-git-send-email-xiaoyux.lu@intel.com> <1557379429-7527-5-git-send-email-xiaoyux.lu@intel.com> <38ff9c2f-1d16-4719-18f6-07e84e4d8bf8@redhat.com> <56bae128-9d26-3b5a-0c79-b27b39ee29df@redhat.com> From: "Laszlo Ersek" Message-ID: Date: Tue, 14 May 2019 12:58:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Tue, 14 May 2019 10:58:38 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 ; Lu, XiaoyuX >> >> Cc: Ye, Ting >> 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