Putting these on the command line as we do at the moment means that they
are *only* visible when actually building the OpenSSL code itself. When
building other things like BaseCryptLib, they were missing. Which could
lead to discrepancies in structures defined by the header files, between
the OpenSSL code and the EDK II code which calls it.
Move the definitions into opensslconf.h where they would normally live
in a standard build of OpenSSL.
Note: Do *not* set OPENSSL_NO_LHASH or OPENSSL_NO_OCSP since those weren't
effectively disabled before; the directories was still being included in
the build. If we actually disable then, the build breaks. We can hopefully
fix at least OCSP upstream later, but one thing at a time...
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Qin Long <qin.long@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18708 6f19259b-4bc3-4df7-8a09-765794883524
OpenSSL ought to work this out for itself when OPENSSL_SYS_UEFI is set.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Qin Long <qin.long@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18707 6f19259b-4bc3-4df7-8a09-765794883524
We were manually setting -DSIXTY_FOUR_BIT_LONG or -DTHIRTY_TWO_BIT on
the compiler command line when building OpensslLib itself, but not when
building BaseCryptLib.
But when building BaseCryptLib, we weren't setting OPENSSL_SYS_UEFI
*either*. This meant that *that* build was picking up the definition
from <openssl/opensslconf.h>, and was thus *different* to the version
the library was built with, in some cases.
So set OPENSSL_SYS_UEFI consistently in OpensslSupport.h and *also*
define either SIXTY_FOUR_BIT or THIRTY_TWO_BIT there too.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Qin Long <qin.long@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18706 6f19259b-4bc3-4df7-8a09-765794883524
Instead of patching OpenSSL to add EFIAPI to the one varargs function we
actually *noticed* breakage in, let's fix the problem in a more coherent
way by undefining NO_BUILTIN_VA_FUNCS.
That way, the VA_START and similar macros will actually do the right
thing for non-EFIAPI functions, which is to use the GCC builtins.
It's still fairly broken elsewhere in the tree, with the VA_START macro
being used from both EFIAPI and non-EFIAPI functions — and being broken
in the latter case. We probably ought to make EFIAPI a no-op everywhere
and add -mabi=ms to the GCC builds. But that's a project for another day.
For now, just fix the OpenSSL build in a cleaner fashion.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Qin Long <qin.long@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18705 6f19259b-4bc3-4df7-8a09-765794883524
Upstream OpenSSL version 1.0.2c contained a fatal flaw
[CVE-2015-1793] and is no longer available from the openssl.org
download servers. So upgrade to its replacement, version 1.0.2d.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Reviewed-by: Qin Long <qin.long@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17928 6f19259b-4bc3-4df7-8a09-765794883524
David Woodhouse
Ard Biesheuvel