From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=YD/XdMlj; spf=pass (domain: linaro.org, ip: 209.85.166.194, mailfrom: ard.biesheuvel@linaro.org) Received: from mail-it1-f194.google.com (mail-it1-f194.google.com [209.85.166.194]) by groups.io with SMTP; Tue, 21 May 2019 06:39:37 -0700 Received: by mail-it1-f194.google.com with SMTP id i10so5030596ite.0 for ; Tue, 21 May 2019 06:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3xsfGsfkO48OHkyI5Cza3tTEBYY5Yp+TDVVJOVk5peo=; b=YD/XdMljXXD9Rw17UmCXun/A7BC/mDInOZALr7OmwvJ/RVRy97pwDCaZPPxJXD/60T CZI5yoLDvzFfhmxcs0kA1D29xO8ykWnOfwPV0hKnC6Q4WhTL5WmLwsA8s0Xvvebg/avN 73Bh+kRacJpJlxjqrzTY9l3SnxliTp3AJI4arcYzn/LelMrcSsiRedGuB74qVAVmTBUd G43VwTap2g30tlgmfuoe0Dwj6RNNFvcqZqrhpSbu327sJZqD+sC6l02/P3zKG9FIXBK8 HnJkrfp9LV82eyia5apQZERcfA2XweBBZPuPS0biNG/6OM5GbdLwejAOomxLReDnC5Ob KwMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3xsfGsfkO48OHkyI5Cza3tTEBYY5Yp+TDVVJOVk5peo=; b=mCYjmgwOfzbPuTDD2dXxkYBT20sDJWWCSKCoo/jFnx6hq626eT6xbUGVTTfmwEkdBm SNbIYK753dxZgYpFqbw7M/2mnzB7cggllNS0GrMuZ/1VXRXTpthPujZ8GWX5TV8JwiZ+ sNsCv0KClKvIY+X7UGPCxCWNUOvqXQVqfMjVvhaLMr9Ye8QkHWH+UKk94K/giQEZ7Ix1 IpDAM+m+/RdJ2N0/hDepkbBL6dcnB6oBXW/vY1qzkBjAHUHwke2J2sGKV/a+JeVmpNEl 8unj5UJfifR4Ea9JapIBC8dyHDxp42yBZ4Kd6AcrFDKv88f/QdLFGM12zkzI1tcl/eq+ elQQ== X-Gm-Message-State: APjAAAXgz3YsmxNzqelw7rJ6cY1ytlP6JTOqLgWrlxa4wN1gyjUXaocP ZvaQyxasYV0WWaeWSSWGVhmL+LvcA8kWG8Nxbjvb2g== X-Google-Smtp-Source: APXvYqzqD3lNi3dp6fuQwfNNPAMPGjyyT1w7pDiaPkfa7z7YJr8kgQClAxOedchLl6pUMJ9VyntyNtMdfQfv/QFxtW8= X-Received: by 2002:a24:ca84:: with SMTP id k126mr3599675itg.104.1558445976992; Tue, 21 May 2019 06:39:36 -0700 (PDT) MIME-Version: 1.0 References: <1557993298-22205-1-git-send-email-xiaoyux.lu@intel.com> <049e489c-b58f-0fc5-1c66-8ad920d93979@redhat.com> <0a6b50d4-3837-a5e6-7f3a-36386c65d42b@redhat.com> <75b13a2a-f570-97e9-a7df-5e24b2a2b22c@redhat.com> <15A0408CA29C0595.820@groups.io> In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 21 May 2019 14:39:25 +0100 Message-ID: Subject: Re: [edk2-devel] [PATCH v4 0/7] CryptoPkg: Upgrade OpenSSL to 1.1.1b To: Laszlo Ersek Cc: "Wang, Jian J" , "devel@edk2.groups.io" , "Lu, XiaoyuX" , "Ye, Ting" , Leif Lindholm , "Gao, Liming" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 21 May 2019 at 13:23, Laszlo Ersek wrote: > > Hi, > > On 05/21/19 11:09, Wang, Jian J wrote: > > Ard, > > > >> -----Original Message----- > >> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of= Ard > >> Biesheuvel > >> Sent: Tuesday, May 21, 2019 5:02 PM > >> To: Wang, Jian J > >> Cc: devel@edk2.groups.io; Laszlo Ersek ; Lu, Xiaoy= uX > >> ; Ye, Ting ; Leif Lindholm > >> ; Gao, Liming > >> Subject: Re: [edk2-devel] [PATCH v4 0/7] CryptoPkg: Upgrade OpenSSL t= o 1.1.1b > >> > >> On Tue, 21 May 2019 at 09:43, Wang, Jian J wr= ote: > >>> > >>> Hi Ard, > >>> > >>> Any comments? > >>> > >>> Regards, > >>> Jian > >>> > >>>> -----Original Message----- > >>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf = Of > >> Wang, > >>>> Jian J > >>>> Sent: Monday, May 20, 2019 9:41 AM > >>>> To: devel@edk2.groups.io; ard.biesheuvel@linaro.org; Laszlo Ersek > >>>> > >>>> Cc: Lu, XiaoyuX ; Ye, Ting ; Leif > >>>> Lindholm ; Gao, Liming > >>>> Subject: Re: [edk2-devel] [PATCH v4 0/7] CryptoPkg: Upgrade OpenSSL= to > >> 1.1.1b > >>>> > >>>> Ard, > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf= Of > >> Ard > >>>>> Biesheuvel > >>>>> Sent: Friday, May 17, 2019 11:06 PM > >>>>> To: Laszlo Ersek > >>>>> Cc: Wang, Jian J ; devel@edk2.groups.io; Lu= , > >> XiaoyuX > >>>>> ; Ye, Ting ; Leif Lindhol= m > >>>>> ; Gao, Liming > >>>>> Subject: Re: [edk2-devel] [PATCH v4 0/7] CryptoPkg: Upgrade OpenSS= L to > >>>> 1.1.1b > >>>>> > >>>>> On Fri, 17 May 2019 at 15:17, Laszlo Ersek wro= te: > >>>>>> > >>>>>> On 05/17/19 15:04, Laszlo Ersek wrote: > >>>>>>> On 05/17/19 07:11, Wang, Jian J wrote: > >>>>>>>> Hi Laszlo, > >>>>>>>> > >>>>>>>> There's already a float library used in OpensslLib.inf. > >>>>>>>> > >>>>>>>> [LibraryClasses.ARM] > >>>>>>>> ArmSoftFloatLib > >>>>>>>> > >>>>>>>> The problem is that the below instance doesn't implement > >> __aeabi_ui2d > >>>>>>>> and __aeabi_d2uiz (I encountered this one as well) > >>>>>>>> > >>>>>>>> ArmPkg\Library\ArmSoftFloatLib\ArmSoftFloatLib.inf > >>>>>>>> > >>>>>>>> I think we can update this library support those two APIs. So w= hat > >> about > >>>>>>>> we still push the patch and file a BZ to fix this issue? > >>>>>>> > >>>>>>> I'm OK with that, but it will break ARM and AARCH64 platforms th= at > >>>>>>> consume OpensslLib (directly or through BaseCryptLib), so this q= uestion > >>>>>>> is up to Leif and Ard to decide. > >>>>>> > >>>>>> Correction: break ARM platforms only, not AARCH64. > >>>>>> > >>>>> > >>>>> We obviously need to fix this before we can upgrade to a new OpenS= SL > >> version. > >>>>> > >>>>> Do we really have a need for the random functions? These seem the = only > >>>>> ones that use floating point, which the UEFI spec does not permit,= so > >>>>> it would be better if we could fix this by removing the dependency= on > >>>>> FP in the first place (and get rid of ArmSoftFloatLib entirely) > >>>>> > >>>> > >>>> BaseCryptLib provides RandSeed/RandBytes interface which wrap opens= sl > >> rand > >>>> functionalities. These interfaces are used by following components = in edk2 > >>>> > >>>> - CryptoPkg\Library\TlsLib\TlsInit.c > >>>> - SecurityPkg\HddPassword\HddPasswordDxe.c > >>>> > >>>> Openssl components, like asn1, bn, evp, ocsp, pem, pkcs7, pkcs12, r= sa, ssl (in > >>>> addition > >>>> to cms, dsa, srp, which are disabled in edk2) will call rand_* inte= rface as well. > >>>> > >> > >> If we have both internal (to Openssl) and external users of the RNG > >> api, then I guess there is no way to work around this. It is > >> unfortunate, since the RNG code in OpenSSL doesn't actually use doubl= e > >> types except for keeping an entropy count, which could just as easily > >> be kept in an integer variable. > > (1) I think I agree... However, it seems that the first function (or one > of the first functions) in OpenSSL to take an "entropy" parameter, of > type "double", was RAND_add(). And the RAND_add() manual states, > > RAND_add() mixes the num bytes at buf into the PRNG state. > Thus, if the data at buf are unpredictable to an adversary, > this increases the uncertainty about the state and makes the > PRNG output less predictable. Suitable input comes from user > interaction (random key presses, mouse movements) and certain > hardware events. The entropy argument is (the lower bound of) > an estimate of how much randomness is contained in buf, > measured in bytes. Details about sources of randomness and how > to estimate their entropy can be found in the literature, e.g. > RFC 1750. > > I've now looked up RFC 1750, and it contains copious amounts of math on > irrational numbers. Hence the use of floating point in OpenSSL, I'd gues= s. > > https://www.ietf.org/rfc/rfc1750.txt > > ... After digging a bit in the OpenSSL git history, I've found the > following commit (from 19 years ago): > > commit 853f757ecea74a271a7c5cdee3f3b5fe0d3ae863 > Author: Bodo M=C3=B6ller > Date: Sat Feb 19 15:22:53 2000 +0000 > > Allow for higher granularity of entropy estimates by using 'double' > instead of 'unsigned' counters. > Seed PRNG in MacOS/GetHTTPS.src/GetHTTPS.cpp. > > Partially submitted by Yoram Meroz . > > It was the commit with > > -void RAND_add(const void *buf,int num,int entropy); > +void RAND_add(const void *buf,int num,double entropy); > > FWIW, the "PRNG" reference at the end of the commit message seems > meaningless. Check for yourself: > > $ git show 853f757ecea7:MacOS/GetHTTPS.src/GetHTTPS.cpp > > The fact that "entropy" is now of type "double" does not seem to be put > to use, anywhere in that file. > > I'll send a query to the openssl-users mailing list, just so we > understand better. > Thanks for doing the paleontological research here. However, the outcome of this query is not going to affect our short term issue with this code. I will try to come back to this issue as soon as I can, but I am a bit swamped at the moment. > > >> So we will need to fix ArmSoftFloatLib before we can merge this > >> OpenSSL update. > > (2) NB, I think we can no longer merge this feature for > edk2-stable201905. The soft feature freeze criterion is that all patches > be reviewed (approved) on-list before the SFF date / announcement, and > that was not fulfilled in this case. > > > >> I'm happy to help doing that, could you please > >> summarize what we are missing today? > >> > > > > Great. I think there're two intrinsic functions missing here > > > > __aeabi_ui2d > > __aeabi_d2uiz > > > > Laszlo, please double check if these two are enough. > > (3) I can only report the failure that trips up the build for me. I did > that here: > > http://mid.mail-archive.com/049e489c-b58f-0fc5-1c66-8ad920d93979@redhat.= com > https://edk2.groups.io/g/devel/message/40823 > > > Thus, for me, the missing symbol was "__aeabi_ui2d". > > It's possible that the 32-bit ARM build will fail at a different (later) > stage as well, but I can't tell until I get past this one. (And I don't > think I can implement a "shim" function for the missing symbol, just to > let the build progress.) > > Thanks, > Laszlo > > > Thanks for doing this. > > > > Regards, > > Jian > > > >>=20 > > >