UEFI has an optional build directive to enable “Secure Boot”. Secure Boot’s crypto is backed by the Open Source library libOpenSSL. For a long time, Tianocore’s OpenSSL was based on 0.98x release of OpenSSL. It sucks for UEFI that every time OpenSSL issues a new release (which is often, these months), the UEFI patch sometimes has to get updates to reflect OpenSSL changes. Plus, it was scary to see UEFI using such an ancient 0.98x release of OpenSSL for so long. Recently, UEFI updated to 1.0x releases of OpenSSL, and have been doing a lot of patch churning, due to frequent OpenSSl releases. So, it’s nice to see that there’s a effort by David Woodhouse of Intel’s Open Source Technology Centre, to make an effort to upstream the UEFI patches to OpenSSL, for the first time filing an issue in the RT. (Previously, AFAICT, the only effort to upstream was brief email on the OpenSSL mailing list, no RT filed.) I don’ t think UEFI Forum is one of the members of the OpenSSL Foundation; it might be nice if they were, given their Secure Boot dependence on this library. (OEMs/IBVs can swap out OpenSSL with another crypto lib, unclear which do…)

I hope the OpenSSL Foundation and it’s developers accept this patch, or work with UEFI Forum’s developers to come up with acceptable patch to upstream. I may be biased, but UEFI Secure Boot might be one of OpenSSL’s most important uses. Having UEFI target code in main OpenSSL trunk will save UEFI developers time, but also help with OpenSSL developers to understand the UEFI codepath differences, and may help reduce UEFI-centric code issues later. Imagine if Windows or Linux target support for OpenSSL was a separate patch, yuck.

Even if OpenSSL Foundation doesn’t accept the patch, it is still a significant new OpenSSL patch for UEFI, worth a review.

Not sure which version this is; let’s call it v3 despite the fact that I think it’s actually the first time all this lot has been posted together in a single coherent series.
All the OpenSSL fixes are filed in upstream RT and in my git tree at http://git.infradead.org/users/dwmw2/openssl.git/ and backported to OpenSSL 1.0.2 in the OpenSSL_1_0_2-stable branch of the same repo.

This series cleans up a number of our outstanding OpenSSL patches to match what’s been submitted upstream, including the use of OPENSSL_SYS_UEFI instead of abusing OPENSSL_SYSNAME_UWIN.

It also cleans up places in our code where we access OpenSSL “internal” structures which are going to be made opaque in OpenSSL 1.1 and accessor functions should be used instead.

The build infrastructure is fixed to be more consistent with the way that OpenSSL is usually built all the OPENSSL_NO_xxx definitions are moved into opensslconf.h, and the file list is properly synchronised with the result of ‘make files’ in the suitably-configured OpenSSL source.

A script is provided which allows the opensslconf.h file and the list of files in OpensslLib.inf to be automatically updated. This script is not required during a normal build; it’s only for when we update the OpenSSL which is used by the EDK II repository.

Finally, we remove CryptoPkg/include/openssl and instead use the real OpenSSL include directory. This Just Works on POSIX-compliant platforms, and has symlinks to the original files. In OpenSSL 1.1 it’ll work even on Windows, as those files have been *moved* to the include/openssl/ directory of the OpenSSL source tree. For the time being, Install.sh can die and Install.cmd is updated to copy the files to $(OPENSSL_PATH)/include/openssl to work around Windows’ lack of symlinks.

Both the final commit (using OpenSSL HEAD) and the penultimate (still using a patched 1.0.2d) have been build-tested for IA32 and X86 both using GCC on Linux and VS2008 under Windows. And also using MinGW32/MingGW64 under Linux, although the final link there fails due to calls to __chkstk_ms (see GCC PR#67169).