[openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build

[David Woodhouse]

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.Woodhouse at intel.com                              Intel Corporation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160217/567416aa/attachment.bin>