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 “*cpy” and “*cmp” 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
\“MSFTINTRINx86-32<compilerversion>.lib”
2. Update the MSFT_DEF.txt tool chain definition path
DEBUG_*_IA32_DLINK_FLAGS = %CONF_PATH%\
MSFTINTRINx86-32<compilerversion>.lib
RELEASE_*_IA32_DLINK_FLAGS = %CONF_PATH%\
MSFTINTRINx86-32<compilerversion>.lib
1. Resolve build conflicts with other existing intrinsic libraries from
CryptoPkg, RedfishPkg… – 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<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 described in the C Specification
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf#page=23<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn1256.pdf%23page%3D23&data=04%7C01%7C%7C1db233037ffb4811299008d9df47ba42%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637786321422685738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NuCQGfgDshlvQOKAQerAQaALk11LZA7YKY4eqSwotDg%3D&reserved=0>
and shall not try to create a new restricted “UEFI execution environment”
that currently prohibits some “expressions” (shift << >> , divide / % ) on some
“data types” (64bit “long long”)
but maybe in the future will prohibit some more “expressions” (logical AND &&,
relational-expression < >) on
still speculative “data types” (e.g. a 128bit “extended long”) or just because
a new compiler
(version) with some new optimization(ultra slow)/security(specdown/meltre)
capabilities introduces
some new intrinsic functions.
Who knows…
In contrast to:
“I 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.)”
https://bugzilla.tianocore.org/show_bug.cgi?id=1516#c2<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D1516%23c2&data=04%7C01%7C%7C1db233037ffb4811299008d9df47ba42%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637786321422685738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TV9hIhMuhINFVj8PSOQzMnGiknw3HO5zKm7ub5%2BcDow%3D&reserved=0>
This mindset violates edk2 coding style spec too:
https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-specification/2_guiding_principles<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2-docs.gitbook.io%2Fedk-ii-c-coding-standards-specification%2F2_guiding_principles&data=04%7C01%7C%7C1db233037ffb4811299008d9df47ba42%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637786321422685738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QVHxAAGiXywPxVI4wKzBtvbyfW16qvigghS1uwkIIcg%3D&reserved=0>
* Maintainability
* Extensibility
* Intellectual manageability
* Portability
* Reusability
* Standard techniques
Have fun,
Kilian
From: Michael D Kinney<mailto:michael.d.kin...@intel.com>
Sent: Friday, January 21, 2022 05:39 PM
To: kra...@redhat.com<mailto:kra...@redhat.com>; Yao,
Jiewen<mailto:jiewen....@intel.com>; Sean
Brogan<mailto:sean.bro...@microsoft.com>; Bret
Barkelew<mailto:bret.barke...@microsoft.com>; Kinney, Michael
D<mailto:michael.d.kin...@intel.com>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Wang, Jian
J<mailto:jian.j.w...@intel.com>; Jiang, Guomin<mailto:guomin.ji...@intel.com>;
Pawel Polawski<mailto:ppola...@redhat.com>; Lu,
XiaoyuX<mailto:xiaoyux...@intel.com>
Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl
submodule to v3.0
Comments below.
Mike
> -----Original Message-----
> From: kra...@redhat.com <kra...@redhat.com>
> Sent: Friday, January 21, 2022 12:31 AM
> To: Yao, Jiewen <jiewen....@intel.com>
> Cc: devel@edk2.groups.io; Kinney, Michael D <michael.d.kin...@intel.com>;
> Wang, Jian J <jian.j.w...@intel.com>; Jiang, Guomin
> <guomin.ji...@intel.com>; Pawel Polawski <ppola...@redhat.com>; Lu, XiaoyuX
> <xiaoyux...@intel.com>
> 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/FmpAuthenticationLibRsa2048Sha256.
>
> 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: 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/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=1516
>
> > > (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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86027): https://edk2.groups.io/g/devel/message/86027
Mute This Topic: https://groups.io/mt/87479913/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
