From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (EUR05-AM6-obe.outbound.protection.outlook.com [40.92.91.51]) by mx.groups.io with SMTP id smtpd.web09.5898.1643041505566620036 for ; Mon, 24 Jan 2022 08:25:06 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@outlook.com header.s=selector1 header.b=JlPlRmWP; spf=pass (domain: outlook.com, ip: 40.92.91.51, mailfrom: kilian_kegel@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OdFP4meJTxB5EzMpmuzL6Xqx5rAxiD4g47WJVR5WLLb7XjihFhVmDJXVO3274Vc2T5MblyEZZt3t483/u6OkU979TYSfgVLe8fIyHlDzelO23/lyHAsTZCu01xcgH/Awcjm6AZspvFLntWRwZoeSho3CcPZRB5LNC3UDXbf4mK8nE6dDBGAleEU36cZopkpphiMJFNvG1sflhVMjJ8t9GEV62MV05mi0sJ9ct7gorLUSBEzfD70rOVuPVFSYEjaQRJ0XQ1IW8Bpo2IxYvPHkdtTGkfCXe4idnDbyd7Vek8Mq5sdtevF/dwt3XVQwandkHNlXmlmie0Y/MYh/ow5MTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zzVcYotyBBw+RndRbcQmxvljs6vfO/SSUpBMObAsf7A=; b=iJ2MTr2FkoPrEhp1MQmYvqFG4GPdkVmifgLZFAmjS4IXFc6L293HbQyBiRsIsAepJtawIjw5tEqZyHFiI8H+rBrYrkbWw2SvUkstRQ/1/llr5pysB5ov0g1AI8A+O+yu08PZJbuEplpZA/RIw+muyi+IjGrEMcWNO0Dmp/Qrrz3iqRpnXBQfGYksBcmUbKXC21Nsc2jG2PuQI+Gi0HA53Raty6BWU4Cox1GeIG5lPYFKSbVxaxZZ1feFtM4IE0yWvEMKkR4jJCJmtCqAxbRV2y/DUVVHbecBgJkwny9CDJJJRJo/MnMxUAkpdc909i8tOFHM4gI8OYXRaxqijqWrFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zzVcYotyBBw+RndRbcQmxvljs6vfO/SSUpBMObAsf7A=; b=JlPlRmWPy8JU639K00XkZQUolrszjQJjX8S9umgvJpjkOkuc5sVEk0Dj/8cV/uogHZ7mm/kQF0+3QZhgjzNTvs7yGKcssv0Ck1kiRiA69CRP0wOh+FSNyi9Bv2h1McW23fAGLMLHTcVYO+4iu7EENc0Rq17FA1gNay1+MeSHuFFQGfoMUHaEHeFXzg51uRcSZ1tmaTnSUH8Cztxce+ZaC6q+YV6JEbHAbv9ay2IqWzIp/l/gbIqzWZvNe9/0A/6zrB9Fl8BW6DBlHjp0qRiBHVAb2RsvbGXeLGqBNOoE+Uh1ZoXZkGKURguKdmX/yyjmhF5U+wvBKGn+jExBunk0Ew== Received: from AM8P190MB0945.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d0::21) by AM9P190MB1492.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3eb::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4909.7; Mon, 24 Jan 2022 16:25:00 +0000 Received: from AM8P190MB0945.EURP190.PROD.OUTLOOK.COM ([fe80::88b4:c09b:8790:e490]) by AM8P190MB0945.EURP190.PROD.OUTLOOK.COM ([fe80::88b4:c09b:8790:e490%6]) with mapi id 15.20.4909.017; Mon, 24 Jan 2022 16:25:00 +0000 From: "Kilian Kegel" To: "devel@edk2.groups.io" , "michael.d.kinney@intel.com" , "kraxel@redhat.com" , "Yao, Jiewen" , Sean Brogan , Bret Barkelew CC: "devel@edk2.groups.io" , "Wang, Jian J" , "Jiang, Guomin" , Pawel Polawski , "Lu, XiaoyuX" Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0 Thread-Topic: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0 Thread-Index: AQHX6F/xW9cQ5112l0a7hvD1lfiFZqwg9hAAgAACnACARmZMgIABiLUAgASJ5YCAAIhSAIADQN9h Date: Mon, 24 Jan 2022 16:24:59 +0000 Message-ID: References: <20211203160748.866150-1-kraxel@redhat.com> <20220117114627.ji5cyqxkca6bmiaf@sirius.home.kraxel.org> <20220121083035.dsqzu3akshonliza@sirius.home.kraxel.org> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [sD3VZjCJ9CZHXm+z+b5ds2KmPoswKM6P13BclOAMKHxKUdeqxW3rkuSqHdj5eRYs] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 72309268-59f2-44a9-5fad-08d9df561159 x-ms-traffictypediagnostic: AM9P190MB1492:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1q+3n6qZ7jFgC4uFdho0kkh3tb5jOxi97GCpfnB/zaSDQ6O0bz4BUUN0t0WalFMKxfcF5RFyfK/zmFVFN3/P78H4G30J2fjuR8GKsYpWMY7M1yz9XBjiwKL4DmlJDHlR8sII6dYCIj+vMCsHAdfK2NZ+Hm6dXXWNDSjS9MwHgfE6s5t2JD1ohxVFyO/E5Ws0OKoOFGkI9bjgFnTeI6mTlc3GCUPDDphPNIINAMSRedp9Mjz1YTb/QrjvCi3Wr4+nGR3YAOruaIIb320tC0fLIWxg1KJ9kSNu4MGfu08CNVATqNIAS5rJcihCnJq1X0+QNb4nVGG7SdthCEVEsCTSRTPaPH8T+Q89cIJ5srFj48LGyuKArEIenMAXZppozwv8uHkBUmHngwm5z7PG703uG2oxULFwR0pgYAcroJxkbleIifyVTRVKRyafvZrYEyxyamsPWb8ONbUqYTVScwFH0px2KzLrDQi0iXMkA4BuGthMoMgBaMloRCHHYoBGop/afmDQ4h8hp9lItZ5thguHjz3MfCUEP8TIeoeG606iokVzsg0tS4oziMQymWTGxc90ducFL8zs5dt0Qwr5DuvLpxC9uJDttDz0CA5ax8fitQKNVJP1qTeLyGlF5XYxUK6vXEs7YFO8mcu38e+gZwd6alT5euiEOReD8nh9x1dOQBM= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?lcVymHzwScw72XQLy6NUS3SaXlXkuJEaxeKAswTL1HgGheGLtHTpIy1j?= =?Windows-1252?Q?TgMlcezIdcui9IEG6aIiKJ5PERM8wGSv4XuIiWEHuW/oTRd14QNrWLc2?= =?Windows-1252?Q?L5wM7LqzyezDcOcJV3MWNcw6i5gEN+41JcEANZdnsVZEkicZlOkHkh+M?= =?Windows-1252?Q?nvDl5ygS9gvjInPT577jc9uy21irV2CJdjQ42wvWcg4rV8xqJrViaCcJ?= =?Windows-1252?Q?nLFSP490zxhqPLQNC0G9SDgUjBYWbSjFWhgV2pGsEW0UYkkvWs3P6UjE?= =?Windows-1252?Q?ax1o8+S6MzNkYzgVtzhJ33UwzwnTYaszyURKRxzQgbwpM4dCC8ao/zfu?= =?Windows-1252?Q?CPV+6WUZyZNsL9h1o+nekO226mTukQPMqi9DeqIyIq4kh2kxFyGtA6dZ?= =?Windows-1252?Q?h2bn5QdM49X3wiTrf1BONQBkaDdC9VfCTZgXuCHQnpOGymCbmhEJ/B/z?= =?Windows-1252?Q?VrukY38/el2AIzyWKY+ntmvNVTtvwzJbb2QdaNtUu8/aFPGDKKwV7xqa?= =?Windows-1252?Q?g3b+JXE8zN3EH81F9xnURHZfGlHhLmB3/xrEi6+jB3efUQaqa/2j5HJI?= =?Windows-1252?Q?isLU7LC4XnqAlDPpNb7WLEEI1mTJ2q9zYYn5fP6IAXlsHeU/cBFoGWqv?= =?Windows-1252?Q?0vfP0cOKx+JOHoNiNuMwck4Ln8tq4YjrPdLdVBUGMwlIT/V+KWhAwNxE?= =?Windows-1252?Q?sjirHTUoeinrU3jy1TcsSNwpnMqh1KJ/sQeS/vtmzeNG+PdiTJiMVaWp?= =?Windows-1252?Q?H4wIRvT04Egr7ohpgZ+qMuUx+/xui/vv8W6Id0Ftq1lv0ro9nF1VtPzT?= =?Windows-1252?Q?r9B+76EIm5VJXkqiG/aScPRymAEeP4sksYOK0N62soSGRtPD0GqmBzcN?= =?Windows-1252?Q?doPkR7hAcgCkf6A9MoaOAWErlpgJEOBMp0tUphNP1s4gS8AXJjuZ1xW1?= =?Windows-1252?Q?tXC21uqmeESnL8nbH2N3cYW5Co1dpaWYDAMXYVDORDZcyNUQMvbUcixr?= =?Windows-1252?Q?kw4Br30WghyinHnIaHG37bwuLIWEf0mL71RNV20ZA3DRGfM6qi0aD6o8?= =?Windows-1252?Q?Gp7+GkfmwwaHuPY0w1WPVZkaF6wwYAa8ix8T6ltvfPuihm7II++s3Vl9?= =?Windows-1252?Q?A+U=3D?= MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0945.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 72309268-59f2-44a9-5fad-08d9df561159 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2022 16:24:59.9793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1492 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AM8P190MB094532852F1E4758523E6F4FEB5D9AM8P190MB0945EURP_" --_000_AM8P190MB094532852F1E4758523E6F4FEB5D9AM8P190MB0945EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The 64-bit integer math intrinsics and other intrinsic problems could be solved easily for ever: 1. Putting all .OBJ files together from LIBCMT.H or INT64.LIB (for ll*.o= bj and ull*.obj only) ltod3.obj ftol2.obj lldiv.obj lldvrm.obj llmul.obj llrem.obj llshl.obj llshr.obj ulldiv.obj ulldvrm.obj ullrem.obj ullshr.obj memcmp.obj memcpycpy.obj and adjust for usability in EDK2 (remove / solve further in= ternal dependencies or rewrite =93*cpy=94 and =93*cmp=94 functions) This is already done in IntrinsicLib.lib for some of the above functions, j= ust complete this task! 1. Put all the .OBJ into a e.g. edk2\Conf \=93MSFTINTRINx86-32.lib=94 2. Update the MSFT_DEF.txt tool chain definition path DEBUG_*_IA32_DLINK_FLAGS =3D %CONF_PATH%\ MSFTINTRINx86-32.lib RELEASE_*_IA32_DLINK_FLAGS =3D %CONF_PATH%\ MSFTINTRINx86-32.lib 1. Resolve build conflicts with other existing intrinsic libraries from = CryptoPkg, RedfishPkg=85 =96 remove these libraries >>From now on all existing 32Bit components have access to their own compiler= intrinsics without touching any .INF file and the problem is instantly gone. Please do the same for * GCCINTRINx86-32.lib Leave the intrinsic restrictions behind and just provide all required intri= nsics the compiler needs to fulfil the C-Standard! UEFI shall conform the execution environment described in the C Specificati= on http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf#page=3D23 and shall not try to create a new restricted =93UEFI execution environment= =94 that currently prohibits some =93expressions=94 (shift << >> , divide / % )= on some =93data types=94 (64bit =93long long=94) but maybe in the future will prohibit some more =93expressions=94 (logical = AND &&, relational-expression < >) on still speculative =93data types=94 (e.g. a 128bit =93extended long=94) or j= ust because a new compiler (version) with some new optimization(ultra slow)/security(specdown/meltre) = capabilities introduces some new intrinsic functions. Who knows=85 In contrast to: =93I think we shouldn't add any intrinsics unless we are absolutely forced to. I do agree however that, for those intrinsics that we cannot at all avoid reimplementing, we should at least collect them in a common library. (In theory, I can also imagine reimplementing all possible intrinsics *if* the edk2 coding style spec / requirements are updated in parallel, permitting all new code to universally rely on the intrinsics, rather than the BaseLib / BaseMemoryLib functions.)=94 https://bugzilla.tianocore.org/show_bug.cgi?id=3D1516#c2 This mindset violates edk2 coding style spec too: https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-specification/2_guid= ing_principles * Maintainability * Extensibility * Intellectual manageability * Portability * Reusability * Standard techniques Have fun, Kilian From: Michael D Kinney Sent: Friday, January 21, 2022 05:39 PM To: kraxel@redhat.com; Yao, Jiewen; Sean Brogan; Bret Barkele= w; Kinney, Michael D Cc: devel@edk2.groups.io; Wang, Jian J; Jiang, Guomin; Pawel= Polawski; Lu, XiaoyuX Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl s= ubmodule to v3.0 Comments below. Mike > -----Original Message----- > From: kraxel@redhat.com > Sent: Friday, January 21, 2022 12:31 AM > To: Yao, Jiewen > Cc: devel@edk2.groups.io; Kinney, Michael D ;= Wang, Jian J ; Jiang, Guomin > ; Pawel Polawski ; Lu, Xiaoy= uX > Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl= submodule to v3.0 > > > > No changes in SEC and PEI. > > [Jiewen] Do you mean the Crypto consumer in PEI has no size difference?= Such as > > https://github.com/tianocore/edk2/tree/master/SecurityPkg/Tcg/Tcg2Pei , > > https://github.com/tianocore/edk2/tree/master/SecurityPkg/FvReportPei , > > https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg/Universa= l/RecoveryModuleLoadPei linking > https://github.com/tianocore/edk2/tree/master/SecurityPkg/Library/FmpAuth= enticationLibRsa2048Sha256. > > PEI has this (OvmfIa32X64Pkg build): > > 7062 TpmMmioSevDecryptPei > 7830 StatusCodeHandlerPei > 7902 ReportStatusCodeRouterPei > 8470 FaultTolerantWritePei > 9734 SmmAccessPei > 11206 Tcg2ConfigPei > 11842 PeiVariable > 14730 Tcg2PlatformPei > 17274 TcgPei > 18438 S3Resume2Pei > 18682 DxeIpl > 18938 PcdPeim > 38014 CpuMpPei > 39554 PlatformPei > 45050 PeiCore > 49274 Tcg2Pei > > No size change for Tcg2Pei. > > The other modules are not there. Seems they are related to firmware > updates. We don't have that on ovmf as we can simply update the > firmware image files on the host machine ... > > Is there some target I could use to test-build those modules? > > > > INFO - OpensslLibCrypto.lib(rsa_lib.obj) : error LNK2001: unresolved = external > > > symbol __allmul > > > INFO - OpensslLibCrypto.lib(rsa_lib.obj) : error LNK2001: unresolved = external > > > symbol __aulldiv > > > INFO - OpensslLibCrypto.lib(bio_print.obj) : error LNK2001: unresolve= d external > > > symbol __aulldvrm > > > INFO - OpensslLibCrypto.lib(bio_print.obj) : error LNK2001: unresolve= d external > > > symbol __ftol2_sse > > > > > > Those symbols look like they reference helper functions to do 64bit m= ath > > > on 32bit architecture. Any hints how to fix that? > > [Jiewen] Please add them to https://github.com/tianocore/edk2/tree/mast= er/CryptoPkg/Library/IntrinsicLib > > Any hints where I could get them? Given this happens on windows builds > it's probably somewhere in the microsoft standard C library? Is that > available as open source somewhere? Sean and Bret may be able to help with these. There is also a BZ on this topic. https://bugzilla.tianocore.org/show_bug.cgi?id=3D1516 > > > > (3) Some NOOPT builds are failing due to the size growing ... > > [Jiewen] Size becomes big challenge... > > Have you tried to use https://github.com/tianocore/edk2/tree/master/Cry= ptoPkg/Driver solution? > > Seems the idea is to have only one openssl copy in the dxe image by > calling a protocol instead of linking a lib. Makes sense. > > Is this documented somewhere? Is there some easy way to use that as > drop-in replacement? Or do we have to change all crypto users to call > the driver instead of linking the lib? > > take care, > Gerd --_000_AM8P190MB094532852F1E4758523E6F4FEB5D9AM8P190MB0945EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

The 64-bit integer math intrinsics and other intrins= ic

problems could be solved easily for ever:=

 

  1. Putting all .OBJ files together from LIBCMT.H or INT64.LIB (for ll*.o= bj and ull*.obj only)

ltod3.obj

ftol2.obj

lldiv.obj

lldvrm.obj

llmul.obj

llrem.obj

llshl.obj

llshr.obj

ulldiv.obj

ulldvrm.obj<= /o:p>

ullrem.obj

ullshr.obj

memcmp.obj

memcpycpy.obj

        &nbs= p;       and adjust for usability in EDK2 (re= move / solve further internal dependencies or rewrite =93*cpy=94 and =93*cm= p=94 functions)

This is already done in I= ntrinsicLib.lib for some of the above functions, just complete this task!

  1. Put all the .OBJ into a e.g. edk2\Conf \=93MSFTINTRINx86-32<compilerversion>.lib=94
  2. Update the MSFT_DEF.txt tool chain definition path

DEBUG_*_IA32_DLINK_FLAGS   &nb= sp; =3D %CONF_PATH%\ MSFTINTRINx86-32<compilerversion>.lib

RELEASE_*_IA32_DLINK_FLAGS   =3D %C= ONF_PATH%\ MSFTINTRINx86-32<compilerversion>.lib

  1. Resolve build conflicts with other existing intrinsic libraries from = CryptoPkg, RedfishPkg=85 =96 remove these libraries

 

From now on all existing 32Bit components have= access to their own compiler intrinsics without

touching any .INF file and the problem is inst= antly gone.

 

Please do the same for

  • GCCINTRINx86-32<compilerversion>.lib

    •  

    Leave the intrinsic restrictions behind and just = provide all required intrinsics the compiler needs

    to fulfil the C-Standard!

     

    UEFI shall conform the execution environment describ= ed in the C Specification

    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n125= 6.pdf#page=3D23

    and shall not try to create a new restricted =93UEFI= execution environment=94

    that currently prohibits some =93expressions=94 (shi= ft << >> , divide / % ) on some =93data types=94 (64bit = =93long long=94)

    but maybe in the future will prohibit some more =93e= xpressions=94 (logical AND &&, relational-expression < >) on<= o:p>

    still speculative =93data types=94 (e.g. a 128bit = =93extended long=94) or just because a new compiler

    (version) with some new optimization(ultra slow)/sec= urity(specdown/meltre) capabilities introduces

    some new intrinsic functions.

    Who knows=85

     

    In contrast to:

    =93I think we shouldn't add any intrinsics un= less we are absolutely forced

    to. I do agree however that, for those intrin= sics that we cannot at all

    avoid reimplementing, we should at least coll= ect them in a common

    library.

    (In theory, I can also imagine reimplementing= all possible intrinsics

    *if* the edk2 coding style spec / requirement= s are updated in parallel,

    permitting all new code to universally rely o= n the intrinsics, rather

    than the BaseLib / BaseMemoryLib functions.)= =94

    https://bugzilla.tianocore.org/show_bug.cg= i?id=3D1516#c2

     

    This mindset violates edk2 coding style spec too:

    https://edk2-docs.gitbook.io/edk-ii-c-co= ding-standards-specification/2_guiding_principles

    • Maintainability
    • Extensibility
      • <= li class=3D"MsoListParagraph" style=3D"margin-left:0in;mso-list:l1 level1 l= fo2">Intellectual manageability
    • Portability=
    • Reusability
    • Standard techniques=

     

    Have fun,

    Kilian

     

    From: Michael D Kinney
    Sent: Friday, January 21, 2022 05:39 PM
    To: kraxel@redhat.com; Yao, Jiewen; Sean Brogan; Bret Barkelew; Kinney, Mi= chael D
    Cc: devel@edk2.groups.io= ; Wang, Jian J; Jiang, Guomin; Pawel Polawski; Lu, XiaoyuX=
    Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update op= enssl submodule to v3.0

     

    Comments below.

    Mike

    > -----Original Message-----
    > From: kraxel@redhat.com <kraxel@redhat.com>
    > Sent: Friday, January 21, 2022 12:31 AM
    > To: Yao, Jiewen <jiewen.yao@intel.com>
    > Cc: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel= .com>; Wang, Jian J <jian.j.wang@intel.com>; Jiang, Guomin
    > <guomin.jiang@intel.com>; Pawel Polawski <ppolawsk@redhat.com= >; Lu, XiaoyuX <xiaoyux.lu@intel.com>
    > Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update open= ssl submodule to v3.0
    >
    > > > No changes in SEC and PEI.
    > > [Jiewen] Do you mean the Crypto consumer in PEI has no size diffe= rence? Such as
    > > https://github.com/tianocore/edk2/tree/master/SecurityPkg/Tcg/Tcg2Pei ,=
    > > https://github.com/tianocore/edk2/tree/master/SecurityPkg/FvReportPei ,=
    > > https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg/Universal/Re= coveryModuleLoadPei linking
    > https://github.com/tianocore/edk2/tree/master/SecurityPkg/Library/FmpAuthen= ticationLibRsa2048Sha256.
    >
    > PEI has this (OvmfIa32X64Pkg build):
    >
    >     7062 TpmMmioSevDecryptPei
    >     7830 StatusCodeHandlerPei
    >     7902 ReportStatusCodeRouterPei
    >     8470 FaultTolerantWritePei
    >     9734 SmmAccessPei
    >    11206 Tcg2ConfigPei
    >    11842 PeiVariable
    >    14730 Tcg2PlatformPei
    >    17274 TcgPei
    >    18438 S3Resume2Pei
    >    18682 DxeIpl
    >    18938 PcdPeim
    >    38014 CpuMpPei
    >    39554 PlatformPei
    >    45050 PeiCore
    >    49274 Tcg2Pei
    >
    > No size change for Tcg2Pei.
    >
    > The other modules are not there.  Seems they are related to firmw= are
    > updates.  We don't have that on ovmf as we can simply update the<= br> > firmware image files on the host machine ...
    >
    > Is there some target I could use to test-build those modules?
    >
    > > > INFO - OpensslLibCrypto.lib(rsa_lib.obj) : error LNK2001: un= resolved external
    > > > symbol __allmul
    > > > INFO - OpensslLibCrypto.lib(rsa_lib.obj) : error LNK2001: un= resolved external
    > > > symbol __aulldiv
    > > > INFO - OpensslLibCrypto.lib(bio_print.obj) : error LNK2001: = unresolved external
    > > > symbol __aulldvrm
    > > > INFO - OpensslLibCrypto.lib(bio_print.obj) : error LNK2001: = unresolved external
    > > > symbol __ftol2_sse
    > > >
    > > > Those symbols look like they reference helper functions to d= o 64bit math
    > > > on 32bit architecture.  Any hints how to fix that?
    > > [Jiewen] Please add them to https://github.com/tianocore/edk2/tree/master/CryptoPkg/Library/IntrinsicLi= b
    >
    > Any hints where I could get them?  Given this happens on windows = builds
    > it's probably somewhere in the microsoft standard C library?  Is = that
    > available as open source somewhere?

    Sean and Bret may be able to help with these.

    There is also a BZ on this topic.

    https://b= ugzilla.tianocore.org/show_bug.cgi?id=3D1516

    >
    > > > (3) Some NOOPT builds are failing due to the size growing ..= .
    > > [Jiewen] Size becomes big challenge...
    > > Have you tried to use https://github.com/tianocore/edk2/tree/master/CryptoPkg/Driver solution= ?
    >
    > Seems the idea is to have only one openssl copy in the dxe image by > calling a protocol instead of linking a lib.  Makes sense.
    >
    > Is this documented somewhere?  Is there some easy way to use that= as
    > drop-in replacement?  Or do we have to change all crypto users to= call
    > the driver instead of linking the lib?
    >
    > take care,
    >   Gerd





     

--_000_AM8P190MB094532852F1E4758523E6F4FEB5D9AM8P190MB0945EURP_--