Re: [edk2-devel] [PATCH v4 0/7] CryptoPkg: Upgrade OpenSSL to 1.1.1b

["Wang, Jian J" <jian.j.wang@intel.com>]

Laszlo,

Thanks for the test.

Regards,
Jian


> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Friday, May 17, 2019 2:53 AM
> To: Lu, XiaoyuX <xiaoyux.lu@intel.com>; devel@edk2.groups.io
> Cc: Wang, Jian J <jian.j.wang@intel.com>; Ye, Ting <ting.ye@intel.com>
> Subject: Re: [edk2-devel] [PATCH v4 0/7] CryptoPkg: Upgrade OpenSSL to 1.1.1b
> 
> On 05/16/19 09:54, Xiaoyu Lu wrote:
> > This series is also available at:
> >
> https://github.com/xiaoyuxlu/edk2/tree/bz_1089_upgrade_to_openssl_1_1_1b
> _v4
> >
> > Changes:
> >
> > (1) CryptoPkgOpensslLib: Modify process_files.pl for  upgrading OpenSSL
> >
> > (2) CryptoPkg/OpensslLib: Exclude unnecessary files in process_files.pl
> >     crypto/store/* are excluded.
> >     crypto/rand/randfile.c is excluded.
> >
> > (3) CryptoPkg/IntrinsicLib: Fix possible unresolved external symbol issue
> >
> > (4) CryptoPkg/OpensslLib: Prepare for upgrading OpenSSL
> >     Disable warnings for buiding OpenSSL_1_1_1b
> >
> > (5) CryptoPkg/OpensslLib: Fix cross-build problem for AARCH64
> >
> > (6) CryptoPkg: Upgrade OpenSSL to 1.1.1b
> >     The biggest change is use TSC as entropy source
> >     If TSC isn't avaiable, fallback to TimerLib(PerformanceCounter).
> >
> > (7) CryptoPkg/BaseCryptLib: Make HMAC_CTX size backward compatible
> >
> >
> > Verification done for this series:
> > * Https boot in OvmfPkg.
> > * BaseCrypt Library test. (Ovmf, EmulatorPkg)
> >
> > Important notice:
> > Nt32Pkg doesn't support TimerLib
> >>
> TimerLib|MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplat
> e.inf
> > So it will failed in Nt32Pkg.
> 
> I did some minimal functional testing, as follows:
> 
> - built OvmfPkgIa32X64.dsc with -D SMM_REQUIRE -D SECURE_BOOT_ENABLE
> 
> - with SB pre-enabled in an existing VM, the firmware continued to
>   reject an unsigned UEFI app
> - in the same config, the firmware continued to accept a correctly
>   signed UEFI boot loader (the Fedora OS was booted OK)
> 
> - with SB disabled afresh (deleting PK through SecureBootConfigDxe),
>   both of the above binaries were accepted
> - in the same SB-disabled state, OvmfPkg/EnrollDefaultKeys was possible
>   to invoke from the UEFI shell, and it successfully re-enabled SB (with
>   the effects described in the prior section).
> 
> So this part looks good.
> 
> Thanks
> Laszlo
> 
>