audk/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf

555 lines
23 KiB
INI
Raw Normal View History

CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
## @file
# This module provides OpenSSL Library implementation.
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
#
# Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.<BR>
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
# which accompanies this distribution. The full text of the license may be found at
# http://opensource.org/licenses/bsd-license.php
#
# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
#
##
[Defines]
INF_VERSION = 0x00010005
BASE_NAME = OpensslLibCrypto
MODULE_UNI_FILE = OpensslLibCrypto.uni
FILE_GUID = E29FC209-8B64-4500-BD20-AF4EAE47EA0E
MODULE_TYPE = BASE
VERSION_STRING = 1.0
LIBRARY_CLASS = OpensslLib
DEFINE OPENSSL_PATH = openssl
DEFINE OPENSSL_FLAGS = -DL_ENDIAN -DOPENSSL_SMALL_FOOTPRINT -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DNO_SYSLOG
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
#
# VALID_ARCHITECTURES = IA32 X64 IPF ARM AARCH64
#
[Sources]
$(OPENSSL_PATH)/e_os.h
# Autogenerated files list starts here
$(OPENSSL_PATH)/crypto/aes/aes_cbc.c
$(OPENSSL_PATH)/crypto/aes/aes_cfb.c
$(OPENSSL_PATH)/crypto/aes/aes_core.c
$(OPENSSL_PATH)/crypto/aes/aes_ecb.c
$(OPENSSL_PATH)/crypto/aes/aes_ige.c
$(OPENSSL_PATH)/crypto/aes/aes_misc.c
$(OPENSSL_PATH)/crypto/aes/aes_ofb.c
$(OPENSSL_PATH)/crypto/aes/aes_wrap.c
$(OPENSSL_PATH)/crypto/asn1/a_bitstr.c
$(OPENSSL_PATH)/crypto/asn1/a_d2i_fp.c
$(OPENSSL_PATH)/crypto/asn1/a_digest.c
$(OPENSSL_PATH)/crypto/asn1/a_dup.c
$(OPENSSL_PATH)/crypto/asn1/a_gentm.c
$(OPENSSL_PATH)/crypto/asn1/a_i2d_fp.c
$(OPENSSL_PATH)/crypto/asn1/a_int.c
$(OPENSSL_PATH)/crypto/asn1/a_mbstr.c
$(OPENSSL_PATH)/crypto/asn1/a_object.c
$(OPENSSL_PATH)/crypto/asn1/a_octet.c
$(OPENSSL_PATH)/crypto/asn1/a_print.c
$(OPENSSL_PATH)/crypto/asn1/a_sign.c
$(OPENSSL_PATH)/crypto/asn1/a_strex.c
$(OPENSSL_PATH)/crypto/asn1/a_strnid.c
$(OPENSSL_PATH)/crypto/asn1/a_time.c
$(OPENSSL_PATH)/crypto/asn1/a_type.c
$(OPENSSL_PATH)/crypto/asn1/a_utctm.c
$(OPENSSL_PATH)/crypto/asn1/a_utf8.c
$(OPENSSL_PATH)/crypto/asn1/a_verify.c
$(OPENSSL_PATH)/crypto/asn1/ameth_lib.c
$(OPENSSL_PATH)/crypto/asn1/asn1_err.c
$(OPENSSL_PATH)/crypto/asn1/asn1_gen.c
$(OPENSSL_PATH)/crypto/asn1/asn1_lib.c
$(OPENSSL_PATH)/crypto/asn1/asn1_par.c
$(OPENSSL_PATH)/crypto/asn1/asn_mime.c
$(OPENSSL_PATH)/crypto/asn1/asn_moid.c
$(OPENSSL_PATH)/crypto/asn1/asn_mstbl.c
$(OPENSSL_PATH)/crypto/asn1/asn_pack.c
$(OPENSSL_PATH)/crypto/asn1/bio_asn1.c
$(OPENSSL_PATH)/crypto/asn1/bio_ndef.c
$(OPENSSL_PATH)/crypto/asn1/d2i_pr.c
$(OPENSSL_PATH)/crypto/asn1/d2i_pu.c
$(OPENSSL_PATH)/crypto/asn1/evp_asn1.c
$(OPENSSL_PATH)/crypto/asn1/f_int.c
$(OPENSSL_PATH)/crypto/asn1/f_string.c
$(OPENSSL_PATH)/crypto/asn1/i2d_pr.c
$(OPENSSL_PATH)/crypto/asn1/i2d_pu.c
$(OPENSSL_PATH)/crypto/asn1/n_pkey.c
$(OPENSSL_PATH)/crypto/asn1/nsseq.c
$(OPENSSL_PATH)/crypto/asn1/p5_pbe.c
$(OPENSSL_PATH)/crypto/asn1/p5_pbev2.c
$(OPENSSL_PATH)/crypto/asn1/p5_scrypt.c
$(OPENSSL_PATH)/crypto/asn1/p8_pkey.c
$(OPENSSL_PATH)/crypto/asn1/t_bitst.c
$(OPENSSL_PATH)/crypto/asn1/t_pkey.c
$(OPENSSL_PATH)/crypto/asn1/t_spki.c
$(OPENSSL_PATH)/crypto/asn1/tasn_dec.c
$(OPENSSL_PATH)/crypto/asn1/tasn_enc.c
$(OPENSSL_PATH)/crypto/asn1/tasn_fre.c
$(OPENSSL_PATH)/crypto/asn1/tasn_new.c
$(OPENSSL_PATH)/crypto/asn1/tasn_prn.c
$(OPENSSL_PATH)/crypto/asn1/tasn_scn.c
$(OPENSSL_PATH)/crypto/asn1/tasn_typ.c
$(OPENSSL_PATH)/crypto/asn1/tasn_utl.c
$(OPENSSL_PATH)/crypto/asn1/x_algor.c
$(OPENSSL_PATH)/crypto/asn1/x_bignum.c
$(OPENSSL_PATH)/crypto/asn1/x_info.c
$(OPENSSL_PATH)/crypto/asn1/x_long.c
$(OPENSSL_PATH)/crypto/asn1/x_pkey.c
$(OPENSSL_PATH)/crypto/asn1/x_sig.c
$(OPENSSL_PATH)/crypto/asn1/x_spki.c
$(OPENSSL_PATH)/crypto/asn1/x_val.c
$(OPENSSL_PATH)/crypto/async/arch/async_null.c
$(OPENSSL_PATH)/crypto/async/arch/async_posix.c
$(OPENSSL_PATH)/crypto/async/arch/async_win.c
$(OPENSSL_PATH)/crypto/async/async.c
$(OPENSSL_PATH)/crypto/async/async_err.c
$(OPENSSL_PATH)/crypto/async/async_wait.c
$(OPENSSL_PATH)/crypto/bio/b_addr.c
$(OPENSSL_PATH)/crypto/bio/b_dump.c
$(OPENSSL_PATH)/crypto/bio/b_sock.c
$(OPENSSL_PATH)/crypto/bio/b_sock2.c
$(OPENSSL_PATH)/crypto/bio/bf_buff.c
$(OPENSSL_PATH)/crypto/bio/bf_lbuf.c
$(OPENSSL_PATH)/crypto/bio/bf_nbio.c
$(OPENSSL_PATH)/crypto/bio/bf_null.c
$(OPENSSL_PATH)/crypto/bio/bio_cb.c
$(OPENSSL_PATH)/crypto/bio/bio_err.c
$(OPENSSL_PATH)/crypto/bio/bio_lib.c
$(OPENSSL_PATH)/crypto/bio/bio_meth.c
$(OPENSSL_PATH)/crypto/bio/bss_acpt.c
$(OPENSSL_PATH)/crypto/bio/bss_bio.c
$(OPENSSL_PATH)/crypto/bio/bss_conn.c
$(OPENSSL_PATH)/crypto/bio/bss_dgram.c
$(OPENSSL_PATH)/crypto/bio/bss_fd.c
$(OPENSSL_PATH)/crypto/bio/bss_file.c
$(OPENSSL_PATH)/crypto/bio/bss_log.c
$(OPENSSL_PATH)/crypto/bio/bss_mem.c
$(OPENSSL_PATH)/crypto/bio/bss_null.c
$(OPENSSL_PATH)/crypto/bio/bss_sock.c
$(OPENSSL_PATH)/crypto/bn/bn_add.c
$(OPENSSL_PATH)/crypto/bn/bn_asm.c
$(OPENSSL_PATH)/crypto/bn/bn_blind.c
$(OPENSSL_PATH)/crypto/bn/bn_const.c
$(OPENSSL_PATH)/crypto/bn/bn_ctx.c
$(OPENSSL_PATH)/crypto/bn/bn_depr.c
$(OPENSSL_PATH)/crypto/bn/bn_dh.c
$(OPENSSL_PATH)/crypto/bn/bn_div.c
$(OPENSSL_PATH)/crypto/bn/bn_err.c
$(OPENSSL_PATH)/crypto/bn/bn_exp.c
$(OPENSSL_PATH)/crypto/bn/bn_exp2.c
$(OPENSSL_PATH)/crypto/bn/bn_gcd.c
$(OPENSSL_PATH)/crypto/bn/bn_gf2m.c
$(OPENSSL_PATH)/crypto/bn/bn_intern.c
$(OPENSSL_PATH)/crypto/bn/bn_kron.c
$(OPENSSL_PATH)/crypto/bn/bn_lib.c
$(OPENSSL_PATH)/crypto/bn/bn_mod.c
$(OPENSSL_PATH)/crypto/bn/bn_mont.c
$(OPENSSL_PATH)/crypto/bn/bn_mpi.c
$(OPENSSL_PATH)/crypto/bn/bn_mul.c
$(OPENSSL_PATH)/crypto/bn/bn_nist.c
$(OPENSSL_PATH)/crypto/bn/bn_prime.c
$(OPENSSL_PATH)/crypto/bn/bn_print.c
$(OPENSSL_PATH)/crypto/bn/bn_rand.c
$(OPENSSL_PATH)/crypto/bn/bn_recp.c
$(OPENSSL_PATH)/crypto/bn/bn_shift.c
$(OPENSSL_PATH)/crypto/bn/bn_sqr.c
$(OPENSSL_PATH)/crypto/bn/bn_sqrt.c
$(OPENSSL_PATH)/crypto/bn/bn_srp.c
$(OPENSSL_PATH)/crypto/bn/bn_word.c
$(OPENSSL_PATH)/crypto/bn/bn_x931p.c
$(OPENSSL_PATH)/crypto/buffer/buf_err.c
$(OPENSSL_PATH)/crypto/buffer/buffer.c
$(OPENSSL_PATH)/crypto/cmac/cm_ameth.c
$(OPENSSL_PATH)/crypto/cmac/cm_pmeth.c
$(OPENSSL_PATH)/crypto/cmac/cmac.c
$(OPENSSL_PATH)/crypto/comp/c_zlib.c
$(OPENSSL_PATH)/crypto/comp/comp_err.c
$(OPENSSL_PATH)/crypto/comp/comp_lib.c
$(OPENSSL_PATH)/crypto/conf/conf_api.c
$(OPENSSL_PATH)/crypto/conf/conf_def.c
$(OPENSSL_PATH)/crypto/conf/conf_err.c
$(OPENSSL_PATH)/crypto/conf/conf_lib.c
$(OPENSSL_PATH)/crypto/conf/conf_mall.c
$(OPENSSL_PATH)/crypto/conf/conf_mod.c
$(OPENSSL_PATH)/crypto/conf/conf_sap.c
$(OPENSSL_PATH)/crypto/cpt_err.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/cryptlib.c
$(OPENSSL_PATH)/crypto/cversion.c
$(OPENSSL_PATH)/crypto/des/cbc_cksm.c
$(OPENSSL_PATH)/crypto/des/cbc_enc.c
$(OPENSSL_PATH)/crypto/des/cfb64ede.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/des/cfb64enc.c
$(OPENSSL_PATH)/crypto/des/cfb_enc.c
$(OPENSSL_PATH)/crypto/des/des_enc.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/des/ecb3_enc.c
$(OPENSSL_PATH)/crypto/des/ecb_enc.c
$(OPENSSL_PATH)/crypto/des/fcrypt.c
$(OPENSSL_PATH)/crypto/des/fcrypt_b.c
$(OPENSSL_PATH)/crypto/des/ofb64ede.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/des/ofb64enc.c
$(OPENSSL_PATH)/crypto/des/ofb_enc.c
$(OPENSSL_PATH)/crypto/des/pcbc_enc.c
$(OPENSSL_PATH)/crypto/des/qud_cksm.c
$(OPENSSL_PATH)/crypto/des/rand_key.c
$(OPENSSL_PATH)/crypto/des/rpc_enc.c
$(OPENSSL_PATH)/crypto/des/set_key.c
$(OPENSSL_PATH)/crypto/des/str2key.c
$(OPENSSL_PATH)/crypto/des/xcbc_enc.c
$(OPENSSL_PATH)/crypto/dh/dh_ameth.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/dh/dh_asn1.c
$(OPENSSL_PATH)/crypto/dh/dh_check.c
$(OPENSSL_PATH)/crypto/dh/dh_depr.c
$(OPENSSL_PATH)/crypto/dh/dh_err.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/dh/dh_gen.c
$(OPENSSL_PATH)/crypto/dh/dh_kdf.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/dh/dh_key.c
$(OPENSSL_PATH)/crypto/dh/dh_lib.c
$(OPENSSL_PATH)/crypto/dh/dh_meth.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/dh/dh_pmeth.c
$(OPENSSL_PATH)/crypto/dh/dh_prn.c
$(OPENSSL_PATH)/crypto/dh/dh_rfc5114.c
$(OPENSSL_PATH)/crypto/dso/dso_dl.c
$(OPENSSL_PATH)/crypto/dso/dso_dlfcn.c
$(OPENSSL_PATH)/crypto/dso/dso_err.c
$(OPENSSL_PATH)/crypto/dso/dso_lib.c
$(OPENSSL_PATH)/crypto/dso/dso_openssl.c
$(OPENSSL_PATH)/crypto/dso/dso_vms.c
$(OPENSSL_PATH)/crypto/dso/dso_win32.c
$(OPENSSL_PATH)/crypto/ebcdic.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/err/err.c
$(OPENSSL_PATH)/crypto/err/err_all.c
$(OPENSSL_PATH)/crypto/err/err_prn.c
$(OPENSSL_PATH)/crypto/evp/bio_b64.c
$(OPENSSL_PATH)/crypto/evp/bio_enc.c
$(OPENSSL_PATH)/crypto/evp/bio_md.c
$(OPENSSL_PATH)/crypto/evp/bio_ok.c
$(OPENSSL_PATH)/crypto/evp/c_allc.c
$(OPENSSL_PATH)/crypto/evp/c_alld.c
$(OPENSSL_PATH)/crypto/evp/cmeth_lib.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/evp/digest.c
$(OPENSSL_PATH)/crypto/evp/e_aes.c
$(OPENSSL_PATH)/crypto/evp/e_aes_cbc_hmac_sha1.c
$(OPENSSL_PATH)/crypto/evp/e_aes_cbc_hmac_sha256.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/evp/e_bf.c
$(OPENSSL_PATH)/crypto/evp/e_camellia.c
$(OPENSSL_PATH)/crypto/evp/e_cast.c
$(OPENSSL_PATH)/crypto/evp/e_chacha20_poly1305.c
$(OPENSSL_PATH)/crypto/evp/e_des.c
$(OPENSSL_PATH)/crypto/evp/e_des3.c
$(OPENSSL_PATH)/crypto/evp/e_idea.c
$(OPENSSL_PATH)/crypto/evp/e_null.c
$(OPENSSL_PATH)/crypto/evp/e_old.c
$(OPENSSL_PATH)/crypto/evp/e_rc2.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/evp/e_rc4.c
$(OPENSSL_PATH)/crypto/evp/e_rc4_hmac_md5.c
$(OPENSSL_PATH)/crypto/evp/e_rc5.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/evp/e_seed.c
$(OPENSSL_PATH)/crypto/evp/e_xcbc_d.c
$(OPENSSL_PATH)/crypto/evp/encode.c
$(OPENSSL_PATH)/crypto/evp/evp_cnf.c
$(OPENSSL_PATH)/crypto/evp/evp_enc.c
$(OPENSSL_PATH)/crypto/evp/evp_err.c
$(OPENSSL_PATH)/crypto/evp/evp_key.c
$(OPENSSL_PATH)/crypto/evp/evp_lib.c
$(OPENSSL_PATH)/crypto/evp/evp_pbe.c
$(OPENSSL_PATH)/crypto/evp/evp_pkey.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/evp/m_md2.c
$(OPENSSL_PATH)/crypto/evp/m_md4.c
$(OPENSSL_PATH)/crypto/evp/m_md5.c
$(OPENSSL_PATH)/crypto/evp/m_md5_sha1.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/evp/m_mdc2.c
$(OPENSSL_PATH)/crypto/evp/m_null.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/evp/m_ripemd.c
$(OPENSSL_PATH)/crypto/evp/m_sha1.c
$(OPENSSL_PATH)/crypto/evp/m_sigver.c
$(OPENSSL_PATH)/crypto/evp/m_wp.c
$(OPENSSL_PATH)/crypto/evp/names.c
$(OPENSSL_PATH)/crypto/evp/p5_crpt.c
$(OPENSSL_PATH)/crypto/evp/p5_crpt2.c
$(OPENSSL_PATH)/crypto/evp/p_dec.c
$(OPENSSL_PATH)/crypto/evp/p_enc.c
$(OPENSSL_PATH)/crypto/evp/p_lib.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/evp/p_open.c
$(OPENSSL_PATH)/crypto/evp/p_seal.c
$(OPENSSL_PATH)/crypto/evp/p_sign.c
$(OPENSSL_PATH)/crypto/evp/p_verify.c
$(OPENSSL_PATH)/crypto/evp/pmeth_fn.c
$(OPENSSL_PATH)/crypto/evp/pmeth_gn.c
$(OPENSSL_PATH)/crypto/evp/pmeth_lib.c
$(OPENSSL_PATH)/crypto/evp/scrypt.c
$(OPENSSL_PATH)/crypto/ex_data.c
$(OPENSSL_PATH)/crypto/hmac/hm_ameth.c
$(OPENSSL_PATH)/crypto/hmac/hm_pmeth.c
$(OPENSSL_PATH)/crypto/hmac/hmac.c
$(OPENSSL_PATH)/crypto/init.c
$(OPENSSL_PATH)/crypto/kdf/hkdf.c
$(OPENSSL_PATH)/crypto/kdf/kdf_err.c
$(OPENSSL_PATH)/crypto/kdf/tls1_prf.c
$(OPENSSL_PATH)/crypto/lhash/lh_stats.c
$(OPENSSL_PATH)/crypto/lhash/lhash.c
$(OPENSSL_PATH)/crypto/md4/md4_dgst.c
$(OPENSSL_PATH)/crypto/md4/md4_one.c
$(OPENSSL_PATH)/crypto/md5/md5_dgst.c
$(OPENSSL_PATH)/crypto/md5/md5_one.c
$(OPENSSL_PATH)/crypto/mem.c
$(OPENSSL_PATH)/crypto/mem_clr.c
$(OPENSSL_PATH)/crypto/mem_dbg.c
$(OPENSSL_PATH)/crypto/mem_sec.c
$(OPENSSL_PATH)/crypto/modes/cbc128.c
$(OPENSSL_PATH)/crypto/modes/ccm128.c
$(OPENSSL_PATH)/crypto/modes/cfb128.c
$(OPENSSL_PATH)/crypto/modes/ctr128.c
$(OPENSSL_PATH)/crypto/modes/cts128.c
$(OPENSSL_PATH)/crypto/modes/gcm128.c
$(OPENSSL_PATH)/crypto/modes/ocb128.c
$(OPENSSL_PATH)/crypto/modes/ofb128.c
$(OPENSSL_PATH)/crypto/modes/wrap128.c
$(OPENSSL_PATH)/crypto/modes/xts128.c
$(OPENSSL_PATH)/crypto/o_dir.c
$(OPENSSL_PATH)/crypto/o_fips.c
$(OPENSSL_PATH)/crypto/o_fopen.c
$(OPENSSL_PATH)/crypto/o_init.c
$(OPENSSL_PATH)/crypto/o_str.c
$(OPENSSL_PATH)/crypto/o_time.c
$(OPENSSL_PATH)/crypto/objects/o_names.c
$(OPENSSL_PATH)/crypto/objects/obj_dat.c
$(OPENSSL_PATH)/crypto/objects/obj_err.c
$(OPENSSL_PATH)/crypto/objects/obj_lib.c
$(OPENSSL_PATH)/crypto/objects/obj_xref.c
$(OPENSSL_PATH)/crypto/ocsp/ocsp_asn.c
$(OPENSSL_PATH)/crypto/ocsp/ocsp_cl.c
$(OPENSSL_PATH)/crypto/ocsp/ocsp_err.c
$(OPENSSL_PATH)/crypto/ocsp/ocsp_ext.c
$(OPENSSL_PATH)/crypto/ocsp/ocsp_ht.c
$(OPENSSL_PATH)/crypto/ocsp/ocsp_lib.c
$(OPENSSL_PATH)/crypto/ocsp/ocsp_prn.c
$(OPENSSL_PATH)/crypto/ocsp/ocsp_srv.c
$(OPENSSL_PATH)/crypto/ocsp/ocsp_vfy.c
$(OPENSSL_PATH)/crypto/ocsp/v3_ocsp.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/pem/pem_all.c
$(OPENSSL_PATH)/crypto/pem/pem_err.c
$(OPENSSL_PATH)/crypto/pem/pem_info.c
$(OPENSSL_PATH)/crypto/pem/pem_lib.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/pem/pem_oth.c
$(OPENSSL_PATH)/crypto/pem/pem_pk8.c
$(OPENSSL_PATH)/crypto/pem/pem_pkey.c
$(OPENSSL_PATH)/crypto/pem/pem_sign.c
$(OPENSSL_PATH)/crypto/pem/pem_x509.c
$(OPENSSL_PATH)/crypto/pem/pem_xaux.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/pem/pvkfmt.c
$(OPENSSL_PATH)/crypto/pkcs12/p12_add.c
$(OPENSSL_PATH)/crypto/pkcs12/p12_asn.c
$(OPENSSL_PATH)/crypto/pkcs12/p12_attr.c
$(OPENSSL_PATH)/crypto/pkcs12/p12_crpt.c
$(OPENSSL_PATH)/crypto/pkcs12/p12_crt.c
$(OPENSSL_PATH)/crypto/pkcs12/p12_decr.c
$(OPENSSL_PATH)/crypto/pkcs12/p12_init.c
$(OPENSSL_PATH)/crypto/pkcs12/p12_key.c
$(OPENSSL_PATH)/crypto/pkcs12/p12_kiss.c
$(OPENSSL_PATH)/crypto/pkcs12/p12_mutl.c
$(OPENSSL_PATH)/crypto/pkcs12/p12_npas.c
$(OPENSSL_PATH)/crypto/pkcs12/p12_p8d.c
$(OPENSSL_PATH)/crypto/pkcs12/p12_p8e.c
$(OPENSSL_PATH)/crypto/pkcs12/p12_sbag.c
$(OPENSSL_PATH)/crypto/pkcs12/p12_utl.c
$(OPENSSL_PATH)/crypto/pkcs12/pk12err.c
$(OPENSSL_PATH)/crypto/pkcs7/bio_pk7.c
$(OPENSSL_PATH)/crypto/pkcs7/pk7_asn1.c
$(OPENSSL_PATH)/crypto/pkcs7/pk7_attr.c
$(OPENSSL_PATH)/crypto/pkcs7/pk7_doit.c
$(OPENSSL_PATH)/crypto/pkcs7/pk7_lib.c
$(OPENSSL_PATH)/crypto/pkcs7/pk7_mime.c
$(OPENSSL_PATH)/crypto/pkcs7/pk7_smime.c
$(OPENSSL_PATH)/crypto/pkcs7/pkcs7err.c
$(OPENSSL_PATH)/crypto/rand/md_rand.c
$(OPENSSL_PATH)/crypto/rand/rand_egd.c
$(OPENSSL_PATH)/crypto/rand/rand_err.c
$(OPENSSL_PATH)/crypto/rand/rand_lib.c
$(OPENSSL_PATH)/crypto/rand/rand_unix.c
$(OPENSSL_PATH)/crypto/rand/rand_vms.c
$(OPENSSL_PATH)/crypto/rand/rand_win.c
$(OPENSSL_PATH)/crypto/rand/randfile.c
$(OPENSSL_PATH)/crypto/rc4/rc4_enc.c
$(OPENSSL_PATH)/crypto/rc4/rc4_skey.c
$(OPENSSL_PATH)/crypto/rsa/rsa_ameth.c
$(OPENSSL_PATH)/crypto/rsa/rsa_asn1.c
$(OPENSSL_PATH)/crypto/rsa/rsa_chk.c
$(OPENSSL_PATH)/crypto/rsa/rsa_crpt.c
$(OPENSSL_PATH)/crypto/rsa/rsa_depr.c
$(OPENSSL_PATH)/crypto/rsa/rsa_err.c
$(OPENSSL_PATH)/crypto/rsa/rsa_gen.c
$(OPENSSL_PATH)/crypto/rsa/rsa_lib.c
$(OPENSSL_PATH)/crypto/rsa/rsa_meth.c
$(OPENSSL_PATH)/crypto/rsa/rsa_none.c
$(OPENSSL_PATH)/crypto/rsa/rsa_null.c
$(OPENSSL_PATH)/crypto/rsa/rsa_oaep.c
$(OPENSSL_PATH)/crypto/rsa/rsa_ossl.c
$(OPENSSL_PATH)/crypto/rsa/rsa_pk1.c
$(OPENSSL_PATH)/crypto/rsa/rsa_pmeth.c
$(OPENSSL_PATH)/crypto/rsa/rsa_prn.c
$(OPENSSL_PATH)/crypto/rsa/rsa_pss.c
$(OPENSSL_PATH)/crypto/rsa/rsa_saos.c
$(OPENSSL_PATH)/crypto/rsa/rsa_sign.c
$(OPENSSL_PATH)/crypto/rsa/rsa_ssl.c
$(OPENSSL_PATH)/crypto/rsa/rsa_x931.c
$(OPENSSL_PATH)/crypto/rsa/rsa_x931g.c
$(OPENSSL_PATH)/crypto/sha/sha1_one.c
$(OPENSSL_PATH)/crypto/sha/sha1dgst.c
$(OPENSSL_PATH)/crypto/sha/sha256.c
$(OPENSSL_PATH)/crypto/sha/sha512.c
$(OPENSSL_PATH)/crypto/stack/stack.c
$(OPENSSL_PATH)/crypto/threads_none.c
$(OPENSSL_PATH)/crypto/threads_pthread.c
$(OPENSSL_PATH)/crypto/threads_win.c
$(OPENSSL_PATH)/crypto/txt_db/txt_db.c
$(OPENSSL_PATH)/crypto/uid.c
$(OPENSSL_PATH)/crypto/x509/by_dir.c
$(OPENSSL_PATH)/crypto/x509/by_file.c
$(OPENSSL_PATH)/crypto/x509/t_crl.c
$(OPENSSL_PATH)/crypto/x509/t_req.c
$(OPENSSL_PATH)/crypto/x509/t_x509.c
$(OPENSSL_PATH)/crypto/x509/x509_att.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/x509/x509_cmp.c
$(OPENSSL_PATH)/crypto/x509/x509_d2.c
$(OPENSSL_PATH)/crypto/x509/x509_def.c
$(OPENSSL_PATH)/crypto/x509/x509_err.c
$(OPENSSL_PATH)/crypto/x509/x509_ext.c
$(OPENSSL_PATH)/crypto/x509/x509_lu.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/x509/x509_obj.c
$(OPENSSL_PATH)/crypto/x509/x509_r2x.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/x509/x509_req.c
$(OPENSSL_PATH)/crypto/x509/x509_set.c
$(OPENSSL_PATH)/crypto/x509/x509_trs.c
$(OPENSSL_PATH)/crypto/x509/x509_txt.c
$(OPENSSL_PATH)/crypto/x509/x509_v3.c
$(OPENSSL_PATH)/crypto/x509/x509_vfy.c
$(OPENSSL_PATH)/crypto/x509/x509_vpm.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/x509/x509cset.c
$(OPENSSL_PATH)/crypto/x509/x509name.c
$(OPENSSL_PATH)/crypto/x509/x509rset.c
$(OPENSSL_PATH)/crypto/x509/x509spki.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/x509/x509type.c
$(OPENSSL_PATH)/crypto/x509/x_all.c
$(OPENSSL_PATH)/crypto/x509/x_attrib.c
$(OPENSSL_PATH)/crypto/x509/x_crl.c
$(OPENSSL_PATH)/crypto/x509/x_exten.c
$(OPENSSL_PATH)/crypto/x509/x_name.c
$(OPENSSL_PATH)/crypto/x509/x_pubkey.c
$(OPENSSL_PATH)/crypto/x509/x_req.c
$(OPENSSL_PATH)/crypto/x509/x_x509.c
$(OPENSSL_PATH)/crypto/x509/x_x509a.c
$(OPENSSL_PATH)/crypto/x509v3/pcy_cache.c
$(OPENSSL_PATH)/crypto/x509v3/pcy_data.c
$(OPENSSL_PATH)/crypto/x509v3/pcy_lib.c
$(OPENSSL_PATH)/crypto/x509v3/pcy_map.c
$(OPENSSL_PATH)/crypto/x509v3/pcy_node.c
$(OPENSSL_PATH)/crypto/x509v3/pcy_tree.c
$(OPENSSL_PATH)/crypto/x509v3/v3_addr.c
$(OPENSSL_PATH)/crypto/x509v3/v3_akey.c
$(OPENSSL_PATH)/crypto/x509v3/v3_akeya.c
$(OPENSSL_PATH)/crypto/x509v3/v3_alt.c
$(OPENSSL_PATH)/crypto/x509v3/v3_asid.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/x509v3/v3_bcons.c
$(OPENSSL_PATH)/crypto/x509v3/v3_bitst.c
$(OPENSSL_PATH)/crypto/x509v3/v3_conf.c
$(OPENSSL_PATH)/crypto/x509v3/v3_cpols.c
$(OPENSSL_PATH)/crypto/x509v3/v3_crld.c
$(OPENSSL_PATH)/crypto/x509v3/v3_enum.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/x509v3/v3_extku.c
$(OPENSSL_PATH)/crypto/x509v3/v3_genn.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/x509v3/v3_ia5.c
$(OPENSSL_PATH)/crypto/x509v3/v3_info.c
$(OPENSSL_PATH)/crypto/x509v3/v3_int.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/x509v3/v3_lib.c
$(OPENSSL_PATH)/crypto/x509v3/v3_ncons.c
$(OPENSSL_PATH)/crypto/x509v3/v3_pci.c
$(OPENSSL_PATH)/crypto/x509v3/v3_pcia.c
$(OPENSSL_PATH)/crypto/x509v3/v3_pcons.c
$(OPENSSL_PATH)/crypto/x509v3/v3_pku.c
$(OPENSSL_PATH)/crypto/x509v3/v3_pmaps.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/x509v3/v3_prn.c
$(OPENSSL_PATH)/crypto/x509v3/v3_purp.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
$(OPENSSL_PATH)/crypto/x509v3/v3_skey.c
$(OPENSSL_PATH)/crypto/x509v3/v3_sxnet.c
$(OPENSSL_PATH)/crypto/x509v3/v3_tlsf.c
$(OPENSSL_PATH)/crypto/x509v3/v3_utl.c
$(OPENSSL_PATH)/crypto/x509v3/v3err.c
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
# Autogenerated files list ends here
[Packages]
MdePkg/MdePkg.dec
CryptoPkg/CryptoPkg.dec
[LibraryClasses]
DebugLib
[LibraryClasses.ARM]
ArmSoftFloatLib
[BuildOptions]
#
# Disables the following Visual Studio compiler warnings brought by openssl source,
# so we do not break the build with /WX option:
# C4090: 'function' : different 'const' qualifiers
# C4244: conversion from type1 to type2, possible loss of data
# C4245: conversion from type1 to type2, signed/unsigned mismatch
# C4267: conversion from size_t to type, possible loss of data
# C4306: 'identifier' : conversion from 'type1' to 'type2' of greater size
# C4389: 'operator' : signed/unsigned mismatch (xxxx)
# C4702: unreachable code
# C4706: assignment within conditional expression
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
#
MSFT:*_*_IA32_CC_FLAGS = -U_WIN32 -U_WIN64 -U_MSC_VER $(OPENSSL_FLAGS) /wd4090 /wd4244 /wd4245 /wd4267 /wd4389 /wd4702 /wd4706
MSFT:*_*_X64_CC_FLAGS = -U_WIN32 -U_WIN64 -U_MSC_VER $(OPENSSL_FLAGS) /wd4090 /wd4244 /wd4245 /wd4267 /wd4306 /wd4389 /wd4702 /wd4706
MSFT:*_*_IPF_CC_FLAGS = -U_WIN32 -U_WIN64 -U_MSC_VER $(OPENSSL_FLAGS) /wd4090 /wd4244 /wd4245 /wd4267 /wd4306 /wd4389 /wd4702 /wd4706
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
INTEL:*_*_IA32_CC_FLAGS = -U_WIN32 -U_WIN64 -U_MSC_VER -U__ICC $(OPENSSL_FLAGS) /w
INTEL:*_*_X64_CC_FLAGS = -U_WIN32 -U_WIN64 -U_MSC_VER -U__ICC $(OPENSSL_FLAGS) /w
INTEL:*_*_IPF_CC_FLAGS = -U_WIN32 -U_WIN64 -U_MSC_VER -U__ICC $(OPENSSL_FLAGS) /w
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
#
# Suppress the following build warnings in openssl so we don't break the build with -Werror
# -Werror=maybe-uninitialized: there exist some other paths for which the variable is not initialized.
#
GCC:*_*_IA32_CC_FLAGS = -U_WIN32 -U_WIN64 $(OPENSSL_FLAGS) -Wno-error=maybe-uninitialized
GCC:*_*_X64_CC_FLAGS = -U_WIN32 -U_WIN64 $(OPENSSL_FLAGS) -Wno-error=maybe-uninitialized -DNO_MSABI_VA_FUNCS
GCC:*_*_IPF_CC_FLAGS = -U_WIN32 -U_WIN64 $(OPENSSL_FLAGS) -Wno-error=maybe-uninitialized
GCC:*_*_ARM_CC_FLAGS = $(OPENSSL_FLAGS)
GCC:*_*_AARCH64_CC_FLAGS = $(OPENSSL_FLAGS)
CryptoPkg/OpensslLib: introduce OpensslLibCrypto instance Commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib directly", 2016-12-14) pulls OpenSSL's libssl files into the "OpensslLib.inf" library instance unconditionally. If a platform doesn't include the TLS modules, such as - CryptoPkg/Library/TlsLib/TlsLib.inf - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf - NetworkPkg/TlsDxe/TlsDxe.inf then the platform never actually uses the libssl functionality that gets built into "OpensslLib.inf". Tomas Hoger from Red Hat Product Security tells me that security evaluation is less demanding if we can actually *exclude* the libssl files from such OVMF builds that don't specify -D TLS_ENABLE (rather than just trust modules not to call libssl functions if we don't specify -D TLS_ENABLE). This patch introduces a parallel OpensslLib instance called "OpensslLibCrypto" that is appropriate for platform builds without TLS enablement. It does not build C source files in vain, and it eases security review -- all libssl vulnerabilities can be excluded at once. "OpensslLibCrypto.inf" is created as a copy of "OpensslLib.inf", modifying the BASE_NAME, MODULE_UNI_FILE and FILE_GUID defines. "process_files.sh" is extended to auto-generate the list of OpenSSL files for both library instances accordingly. This list is updated in "OpensslLibCrypto.inf" at once. "OpensslLibCrypto.uni" is introduced as a copy of "OpensslLib.uni", highlighting the difference. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Ting Ye <ting.ye@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Qin Long <qin.long@intel.com>
2017-02-23 19:35:10 +01:00
# suppress the following warnings in openssl so we don't break the build with warnings-as-errors:
# 1295: Deprecated declaration <entity> - give arg types
# 550: <entity> was set but never used
# 1293: assignment in condition
# 111: statement is unreachable (invariably "break;" after "return X;" in case statement)
# 68: integer conversion resulted in a change of sign ("if (Status == -1)")
# 177: <entity> was declared but never referenced
# 223: function <entity> declared implicitly
# 144: a value of type <type> cannot be used to initialize an entity of type <type>
# 513: a value of type <type> cannot be assigned to an entity of type <type>
# 188: enumerated type mixed with another type (i.e. passing an integer as an enum without a cast)
# 1296: Extended constant initialiser used
# 128: loop is not reachable - may be emitted inappropriately if code follows a conditional return
# from the function that evaluates to true at compile time
# 546: transfer of control bypasses initialization - may be emitted inappropriately if the uninitialized
# variable is never referenced after the jump
# 1: ignore "#1-D: last line of file ends without a newline"
# 3017: <entity> may be used before being set (NOTE: This was fixed in OpenSSL 1.1 HEAD with
# commit d9b8b89bec4480de3a10bdaf9425db371c19145b, and can be dropped then.)
RVCT:*_*_ARM_CC_FLAGS = $(OPENSSL_FLAGS) --library_interface=aeabi_clib99 --diag_suppress=1296,1295,550,1293,111,68,177,223,144,513,188,128,546,1,3017 -JCryptoPkg/Include
XCODE:*_*_IA32_CC_FLAGS = -mmmx -msse -U_WIN32 -U_WIN64 $(OPENSSL_FLAGS) -w
XCODE:*_*_X64_CC_FLAGS = -mmmx -msse -U_WIN32 -U_WIN64 $(OPENSSL_FLAGS) -w
#
# AARCH64 uses strict alignment and avoids SIMD registers for code that may execute
# with the MMU off. This involves SEC, PEI_CORE and PEIM modules as well as BASE
# libraries, given that they may be included into such modules.
# This library, even though of the BASE type, is never used in such cases, and
# avoiding the SIMD register file (which is shared with the FPU) prevents the
# compiler from successfully building some of the OpenSSL source files that
# use floating point types, so clear the flags here.
#
GCC:*_*_AARCH64_CC_XIPFLAGS ==