The 64-bit integer math intrinsics and other intrinsic
problems could be solved easily for ever:
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!
DEBUG_*_IA32_DLINK_FLAGS = %CONF_PATH%\ MSFTINTRINx86-32<compilerversion>.lib
RELEASE_*_IA32_DLINK_FLAGS = %CONF_PATH%\ MSFTINTRINx86-32<compilerversion>.lib
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
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
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
This mindset violates edk2 coding style spec too:
https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-specification/2_guiding_principles
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 <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 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