On Tue, 2016-02-09 at 02:57 +0000, Long, Qin wrote: > <Sorry for late response. I am on CNY (Chinese New Year) Vacation > these two weeks.> > > David, I agree it's really horrid to include those xxxx_lcl.h to meet > EDK2 API requirement. I am thinking it's better to re-design some > APIs to align the new opaque structure style. E.g. replacing the > HmacSha1GetContextSize() with HmacSha1ContextNew()... It should be > feasible.
That sounds ideal; thanks. In the meantime, I've sorted out everything we need on the OpenSSL side. A bunch has been merged today (thanks, Rich and Matt), and we are now down to the following four RT tickets and associated pull requests: RT4175: Fix regression using PKCS7_verify() with Authenticode https://github.com/openssl/openssl/pull/694 (https://github.com/openssl/openssl/pull/695 for 1.0.2) RT4309: Define PRIu64 for UEFI build https://github.com/openssl/openssl/pull/696 RT4310: Fix breakage of various no-xxx configuration options in HEAD https://github.com/openssl/openssl/pull/697 RT3628: Allow filenames to be eliminated from compiled library https://github.com/openssl/openssl/pull/698 It looks like we're in fairly good shape for the OpenSSL 1.1.0 release to work "out of the box". I would like to see what we can do in the way of automated testing, though. It should be possible to at least have Travis-CI make libcrypto.so for the Linux target, with the 'no-everything' options that UEFI uses. It's a blunt instrument, but would have caught quite a few of the things I've just fixed, I think. > In addition, I would like to retire the IntrinsicLib in CryptoPkg. > This library is designed to satisfy the link requirement when > integrating openssl in EDKII environment. Some code segments in > OpenSSL will produce the intrinsic functions. E.g. in the function > load_iv() in Pem_lib.c: > for (i = 0; i < num; i++) > to[i] = 0; > I think it's better to update this to the direct memset(). What's > your opinion? I am not keen. If you don't want the compiler to 'spot' that certain patterns in C code can be replaced with intrinsic functions, then ask it nicely not to do that. Do *not* just attempt to tweak the code so that today's compiler doesn't happen to spot anything it can replace, in the *current* phase of the moon. That way lies madness. Isn't this what -ffreestanding (or is it -fno-builtins) is for? How does this work elsewhere in the EDK2 code base? Surely you can't play whack-a-mole with *every* piece of code that the compiler might decide to swap for an intrinsic memset/memcpy/etc., including all structure assignments? -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
