From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) by mx.groups.io with SMTP id smtpd.web09.956.1643054346367154926 for ; Mon, 24 Jan 2022 11:59:06 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=oRz7gAE7; spf=pass (domain: gmail.com, ip: 209.85.222.45, mailfrom: pedro.falcato@gmail.com) Received: by mail-ua1-f45.google.com with SMTP id n15so31658103uaq.5 for ; Mon, 24 Jan 2022 11:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HZ97TKPTK2lOjChPVfGCA7FixP8tZOPbRwKMGMrzYdA=; b=oRz7gAE7jVO4Hm333BJLdR9PYXvXj226D3E90Nm1DkbOQQ7y7F+3uys55vtGgjCx8s cledOOhv3l197T5/tsgSNJyNuUYGyv5R4Y+qH7LNRWJviL/qN6gysOxhRyQzaCvdKf32 cE/gMTZFntIRZL1q3aXt/2ro9yH+pQpb/3KL03+2WQUEJ0FQdAr56Dnf+yogFy5wa4sa PxWXMQFo6BEeFdO/HT3PmrJIdLf2lSlQmmF68TJaiHJuC5hcG+zKbkcUZhDVdwJGGwEd LHBKPAdf2NdT5DCgogefGH5WbqjxnE0TaBhvZ6ZHBCZmyMuaqVcAEc0Smk9qqE+5TlXk cpKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HZ97TKPTK2lOjChPVfGCA7FixP8tZOPbRwKMGMrzYdA=; b=fg/VySyRStI2BYTng80xBC9wYRXSn4iZ+dHwImogUSZQjavF5lDKNc87QbQmVqemyD DK57Zn8jcmErMHsdb3EhfChkfucTMotvjCdpwyMGov0GdgpuK+cEQzcb2k0amw5Pv4/d 8DZQSCNPeFyjKUSfC6npjW+a7AlrnPODB9jxxe5WngGolpNB10yWIawzoU7wfAqwmfXJ 5BZc6dU82jS95h5CIgS8sWTP9tfyVp7Jq3sASF1+2mE5so7fcuhHQuwORP70myZj09UC jq5SpJQneBB78o9DZxgpiMyH7Bn/OagTSrZ3d9nydiCyC9c7+G/GegAxdhY5FqHNRITO l9kA== X-Gm-Message-State: AOAM531Y5Jl+n4h7I1ek+6WfZDyF3bZ2Oeo/sva8HBLUVA25ea+edoME M0hYGq35hVysL9TP7SxqMbEofkStbVzFvgxWHERv/HiwvOMi9Q== X-Google-Smtp-Source: ABdhPJzTJBQcm/iyHWjBtOIfAlQ6iUkSlpcoarNPPd8HlSKfTMqLEGb06nzYO1dk/dtKJnh8UYb7nzrmFnadhEHxCn0= X-Received: by 2002:a67:c803:: with SMTP id u3mr6506728vsk.15.1643054345202; Mon, 24 Jan 2022 11:59:05 -0800 (PST) MIME-Version: 1.0 References: <20211203160748.866150-1-kraxel@redhat.com> <20220117114627.ji5cyqxkca6bmiaf@sirius.home.kraxel.org> <20220121083035.dsqzu3akshonliza@sirius.home.kraxel.org> In-Reply-To: From: "Pedro Falcato" Date: Mon, 24 Jan 2022 19:58:53 +0000 Message-ID: Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0 To: edk2-devel-groups-io , "Kinney, Michael D" Cc: Kilian Kegel , "kraxel@redhat.com" , "Yao, Jiewen" , Sean Brogan , Bret Barkelew , "Wang, Jian J" , "Jiang, Guomin" , Pawel Polawski , "Lu, XiaoyuX" Content-Type: multipart/alternative; boundary="00000000000097aebe05d65966d0" --00000000000097aebe05d65966d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mike, Just my two cents: I think adding intrinsic libraries is a mixed bag, for the following reasons: 1) The intrinsic libraries are completely internal to the compilers. Breaking down that toolchain/code barrier is not a good idea if we want the project to compile using a good variety of compilers. The API is unstable (as it's internal to the compiler + version) and sometimes undocumented; while in reality the ABI doesn't really change (at least in the LLVM/GCC world, not sure about the other compilers), it's something to consider. 2) Linking the compiler's builtin libraries would fix our issues, except that it doesn't work in cases where object files are tagged with ABI (such as hard FP vs soft FP). On the other hand, the latest libgcc_s.so symbol I can find was introduced in GCC 7.0 (2017) and is completely unrelated to any simple 64-bit integer math we may want to do. So, in our very simple integer-mathy case, it may end up being a solid option. LLVM also has a testsuite for its intrinsics, which is handy :) It's worth noting that (at least) LLVM/GCC expect standard freestanding functions like memcpy, strlen, ... to be available; I think it would be a good idea to supply these and drop "-fno-builtin" so that the compiler can do its job and optimize code further. Also, if we're going to add runtime library code, UBSan and Asan might be worth a look ;) Best regards, Pedro On Mon, Jan 24, 2022 at 5:29 PM Michael D Kinney wrote: > Hi Kilian, > > > > I am in favor of an intrinsic lib to improve the EDK II development > environment. > > > > This has already been done for ARM compilers. The solution should mirror > that approach. > > > > It would be best if we had source code (either in the edk2 repo or throug= h > a submodule) for > > the required intrinsic APIs. If source code is not possible and we have > to use a binary, then > > that must be accessed through a submodule. The edk2 repo does not host > binaries. We use > > repos such as edk2-non-osi for binaries. > > > > We also have to provide a solution that works with supported compilers > (VS, GCC, CLANG, XCODE). > > > > One of the challenges is that compilers are allowed to add/remove/modify > intrinsic APIs > > across compiler releases. We would need to define a solution that will > work if there are > > these types of changes, which would potentially mean a different instance > of the intrinsic > > library for each tool chain tag. I think in practice, the intrinsic APIs > we are seeing from use > > of C code from submodules is a very limited set that do not change across > compiler releases, > > so the maintenance of these intrinsic libs would be manageable. > > > > If we go down the source code path, we can break it up into the following > tasks: > > 1. Identify the specific subset of intrinsic APIs from each compiler > that is required for the edk2 use cases. > 2. Obtain the function prototype and full documentation for each > intrinsic API to support implementation and unit tests. > 3. Implement the APIs for all compilers. > 4. Implement unit tests for all APIs for all compilers using > UnitTestFrameworkPkg unit tests. > 5. Update MdeLibs.dsc.inc with the NULL instances for the intrinsic > libs > 6. Remove intrinsic APIs from EDK II modules that currently maintain > their own implementations of intrinsic APIs. > > > > Best regards, > > > > Mike > > > > *From:* Kilian Kegel > *Sent:* Monday, January 24, 2022 8:25 AM > *To:* devel@edk2.groups.io; Kinney, Michael D ; > kraxel@redhat.com; Yao, Jiewen ; Sean Brogan < > sean.brogan@microsoft.com>; 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 > > > > 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*.obj 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 > internal dependencies or rewrite =E2=80=9C*cpy=E2=80=9D and =E2=80=9C*cmp= =E2=80=9D functions) > > This is already done in IntrinsicLib.lib for some of the above functions, > just complete this task! > > 1. Put all the .OBJ into a e.g. *edk2\Conf > \=E2=80=9CMSFTINTRINx86-32.lib=E2=80=9D* > 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=E2=80=A6 =E2=80=93 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 > intrinsics the compiler needs* > > *to fulfil the C-Standard!* > > > > UEFI shall conform the execution environment described in the C > Specification > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf#page=3D23 > > > and shall not try to create a new restricted =E2=80=9CUEFI execution envi= ronment=E2=80=9D > > that currently prohibits some =E2=80=9Cexpressions=E2=80=9D (shift << >> = , divide / % ) on > some =E2=80=9Cdata types=E2=80=9D (64bit =E2=80=9Clong long=E2=80=9D) > > but maybe in the future will prohibit some more =E2=80=9Cexpressions=E2= =80=9D (logical AND > &&, relational-expression < >) on > > still speculative =E2=80=9Cdata types=E2=80=9D (e.g. a 128bit =E2=80=9Cex= tended long=E2=80=9D) or just > because a new compiler > > (version) with some new optimization(ultra slow)/security(specdown/meltre= ) > capabilities introduces > > some new intrinsic functions. > > Who knows=E2=80=A6 > > > > In contrast to: > > =E2=80=9CI 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.)=E2=80=9D > > 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_gu= iding_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 Barkelew ;= 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 submodule 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, > XiaoyuX > > 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/Universal/= 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: unresolve= d > external > > > > symbol __allmul > > > > INFO - OpensslLibCrypto.lib(rsa_lib.obj) : error LNK2001: unresolve= d > 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 do 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/Intrinsic= Lib > > > > 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/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 > > > > >=20 > > --=20 Pedro Falcato --00000000000097aebe05d65966d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mike,

Just my two cents:

I think adding intrinsic libraries is a mixed bag, fo= r the following reasons:

1) The intrinsic librarie= s are completely internal to the compilers. Breaking down that toolchain/co= de barrier is not a good idea if we want the project to compile using a goo= d variety of compilers. The API is unstable (as it's internal to the co= mpiler + version) and sometimes undocumented; while in reality the ABI does= n't really change (at least in the LLVM/GCC world, not sure about the o= ther compilers), it's something to consider.

2= ) Linking the compiler's builtin libraries would fix our issues, except= that it doesn't work in cases where object files are tagged with ABI (= such as hard FP vs soft FP).

On the other hand= , the latest libgcc_s.so symbol I can find was introduced in GCC 7.0 (2017)= and is completely unrelated to any simple 64-bit integer math we may want = to do. So, in our very simple integer-mathy case, it may end up being a sol= id option.
LLVM also has a testsuite for its intrinsics, whic= h is handy :)

It's worth noting that (at least= ) LLVM/GCC expect standard freestanding <string.h> functions like mem= cpy, strlen, ... to be available; I think it would be a good idea to supply= these and drop "-fno-builtin" so that the compiler can do its jo= b and optimize code further.

Also, if we're go= ing to add runtime library code, UBSan and Asan might be worth a look ;)

Best regards,
Pedro

On Mon, Jan 2= 4, 2022 at 5:29 PM Michael D Kinney <michael.d.kinney@intel.com> wrote:

Hi Kilian,

=C2=A0

I am in favor of an intrinsic lib to improve t= he EDK II development environment.

=C2=A0

This has already been done for ARM compilers.<= span>=C2=A0 The solution should mirror that approach.

=C2=A0

It would be best if we had source code (either= in the edk2 repo or through a submodule) for

the required intrinsic APIs. =C2=A0If source code is not possible and we have to use a bina= ry, then

that must be accessed through a submodule.=C2=A0 The edk2 repo does not host binaries.=C2=A0 We use

repos such as edk2-non-osi for binaries.

=C2=A0

We also have to provide a solution that works = with supported compilers (VS, GCC, CLANG, XCODE).

=C2=A0

One of the challenges is that compilers are al= lowed to add/remove/modify intrinsic APIs

across compiler releases.=C2=A0 We would need to define a solution that will work if there are

these types of changes, which would potentiall= y mean a different instance of the intrinsic

library for each tool chain tag.=C2=A0 I think in practice, the intrinsic APIs we are seeing from use

of C code from submodules is a very limited se= t that do not change across compiler releases,

so the maintenance of these intrinsic libs wou= ld be manageable.

=C2=A0

If we go down the source code path, we can bre= ak it up into the following tasks:

  1. Identify the specific subset of intrinsic APIs from each com= piler that is required for the edk2 use cases.=C2=A0
  2. Obtain the function prototype and = full documentation for each intrinsic API to support implementation and unit tests.
    3. Implement the APIs for all compilers.=
  3. Implement unit tests for all APIs for all compilers using Un= itTestFrameworkPkg unit tests.
  4. Update MdeLibs.dsc.inc= with the NULL instances for the intrinsic libs
    5. Remove intrinsic APIs from EDK II modules that currently maint= ain their own implementations of intrinsic APIs.

    =C2=A0

    Best regards,

    =C2=A0

    Mike

    =C2=A0

    From: Kilian Kegel <kilian_kegel@out= look.com>
    Sent: Monday, January 24, 2022 8:25 AM
    To: devel@= edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>; kraxel@redhat.com; Yao,= Jiewen <jiewe= n.yao@intel.com>; Sean Brogan <sean.brogan@microsoft.com>; Bret Barkel= ew <Bre= t.Barkelew@microsoft.com>
    Cc: devel@= edk2.groups.io; Wang, Jian J <jian.j.wang@intel.com>; Jiang, Guomin <guomin.jiang@intel.c= om>; Pawel Polawski <ppolawsk@redhat.com>; Lu, XiaoyuX <xiaoyux.lu@intel.com>
    Subject: RE: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update op= enssl submodule to v3.0

    =C2=A0

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

    problems could be solved easily for ever:<= /u>

    =C2=A0

    1. Putting all .OBJ files together from LIBCMT.H or INT64.LIB (= for ll*.obj 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

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and adjust for usability in EDK2 (r= emove / solve further internal dependencies or rewrite =E2=80=9C*cpy=E2=80= =9D and =E2=80=9C*cmp=E2=80=9D functions)

    This is already done in = IntrinsicLib.lib for some of the above functions, just complete this task!<= u>

    1. Put all the .OBJ into a e.g. edk2\Conf \=E2=80=9CMSFTINTRINx86-32<compilerversion>.lib=E2=80=9D=
    2. Update the MSFT_DEF.txt too= l chain definition path

    DEBUG_*_IA32_DLINK= _FLAGS=C2=A0=C2=A0=C2=A0=C2=A0 =3D %CONF_PATH%\ MSFTINTRINx86-32<comp= ilerversion>.lib

    RELEASE_*_IA32_DLI= NK_FLAGS=C2=A0=C2=A0 =3D %CONF_PATH%\ MSFTINTRINx86-32<compilerversio= n>.lib

    1. Resolve build conflicts with other existing intrinsic librar= ies from CryptoPkg, RedfishPkg=E2=80=A6 =E2=80=93 remove these libraries=

    =C2=A0

    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.

    =C2=A0

    Please do the same for

    • GCCINTRINx86-32<compilerversion>.lib

    =C2=A0

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

    to fulfil the C-Standard!

    =C2=A0

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

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

    and shall not try to create a new restricted =E2=80= =9CUEFI execution environment=E2=80=9D

    that currently prohibits some =E2=80=9Cexpressions= =E2=80=9D (shift << >> , divide / %=C2=A0) on some =E2=80=9Cdat= a types=E2=80=9D (64bit =E2=80=9Clong long=E2=80=9D)

    but maybe in the future will prohibit some more =E2= =80=9Cexpressions=E2=80=9D (logical AND &&, relational-expression &= lt; >) on

    still speculative =E2=80=9Cdata types=E2=80=9D (e.g.= a 128bit =E2=80=9Cextended long=E2=80=9D) 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=E2=80=A6

    =C2=A0

    In contrast to:

    =E2=80=9CI think w= e shouldn't add any intrinsics unless we are absolutely forced

    to. I do agree how= ever that, for those intrinsics that we cannot at all

    avoid reimplementi= ng, we should at least collect them in a common

    library.=

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

    *if* the edk2 codi= ng style spec / requirements are updated in parallel,

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

    than the BaseLib /= BaseMemoryLib functions.)=E2=80=9D

    https://bugzilla.tianoc= ore.org/show_bug.cgi?id=3D1516#c2

    =C2=A0

    This mindset violates edk2 coding style spec too:

    https://edk2-docs.gitb= ook.io/edk-ii-c-coding-standards-specification/2_guiding_principles<= /u>

    • Maintainability
    • Exte= nsibility
    • Intellectual manageabilit= y
    • Portability<= /li>
    • Reusability
    • Stan= dard techniques

    =C2=A0

    Have fun,

    Kilian

    =C2=A0

    From: Michael D Kinney
    Sent: Friday, January 21, 2022 05:39 PM
    To: kraxel@re= dhat.com; Yao, Jiewen; Sean Brogan; Bret Barkelew; 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 op= enssl submodule to v3.0

    =C2=A0

    Comments below.

    Mike

    > -----Original Message-----
    > From: kraxel@re= dhat.com <kra= xel@redhat.com>
    > Sent: Friday, January 21, 2022 12:31 AM
    > To: Yao, Jiewen <jiewen.yao@intel.com>
    > Cc: devel@ed= k2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>; Wang, Jian= J <jian.j.wa= ng@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):
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 7062 TpmMmioSevDecryptPei
    >=C2=A0=C2=A0=C2=A0=C2=A0 7830 StatusCodeHandlerPei
    >=C2=A0=C2=A0=C2=A0=C2=A0 7902 ReportStatusCodeRouterPei
    >=C2=A0=C2=A0=C2=A0=C2=A0 8470 FaultTolerantWritePei
    >=C2=A0=C2=A0=C2=A0=C2=A0 9734 SmmAccessPei
    >=C2=A0=C2=A0=C2=A0 11206 Tcg2ConfigPei
    >=C2=A0=C2=A0=C2=A0 11842 PeiVariable
    >=C2=A0=C2=A0=C2=A0 14730 Tcg2PlatformPei
    >=C2=A0=C2=A0=C2=A0 17274 TcgPei
    >=C2=A0=C2=A0=C2=A0 18438 S3Resume2Pei
    >=C2=A0=C2=A0=C2=A0 18682 DxeIpl
    >=C2=A0=C2=A0=C2=A0 18938 PcdPeim
    >=C2=A0=C2=A0=C2=A0 38014 CpuMpPei
    >=C2=A0=C2=A0=C2=A0 39554 PlatformPei
    >=C2=A0=C2=A0=C2=A0 45050 PeiCore
    >=C2=A0=C2=A0=C2=A0 49274 Tcg2Pei
    >
    > No size change for Tcg2Pei.
    >
    > The other modules are not there.=C2=A0 Seems they are related to firmw= are
    > updates.=C2=A0 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: 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.=C2=A0 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?=C2=A0 Given this happens on windows = builds
    > it's probably somewhere in the microsoft standard C library?=C2=A0= 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/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.=C2=A0 Makes sense.
    >
    > Is this documented somewhere?=C2=A0 Is there some easy way to use that= as
    > drop-in replacement?=C2=A0 Or do we have to change all crypto users to= call
    > the driver instead of linking the lib?
    >
    > take care,
    >=C2=A0=C2=A0 Gerd



    =C2=A0

=20



--
Pedro Falcato
--00000000000097aebe05d65966d0--