Hi Gerd I have asked in my previous email in Feb 11, 20 - https://edk2.groups.io/g/devel/message/100040 > Hi Gerd > If you don't mind, please submit your latest openssl-3.0 patch to the staging > for broader evaluation and improvement. Unfortunately, I do not see any response or action.
The staging tree is for POC purpose, there is no requirement to pass CI. Please don't worry about that at this moment. With that clarification, please allow me to ask again, would you please to submit your latest work to staging, if you see something is missing? All in all, I do hope we can work on the same tree to keep improving. Thank you Yao, Jiewen > -----Original Message----- > From: kra...@redhat.com <kra...@redhat.com> > Sent: Friday, March 10, 2023 11:50 PM > To: devel@edk2.groups.io; Yao, Jiewen <jiewen....@intel.com> > Subject: Re: [edk2-devel] [RFC] [staging/CryptoLibrary] Openssl1.1 > replacement proposal > > On Fri, Mar 10, 2023 at 12:28:54PM +0000, Yao, Jiewen wrote: > > Hello > > We have created initial POC version CryptoPkg upgrade. > > > > OpenSSL 3.0 POC: https://github.com/tianocore/edk2- > staging/blob/OpenSSL11_EOL/CryptoPkg/Readme-OpenSSL3.0.md > > The size is reduced a lots. But it still exceeds some platforms. > > I've already mentioned the branch in the cover letter of the openssl > hash series (https://edk2.groups.io/g/devel/message/100123), but > apparently it went unnoticed, there are lots of commits from my old > branch in there ... > > Anyway, my latest branch (just rebased to master) is here: > > https://github.com/kraxel/edk2/commits/openssl3 > > Doesn't (yet) pass CI, most failures are on IA32 due to missing > compiler intrinsics. > > I've put the configuration system upside-down, replaced the > process_files.pl script with python. All generated files are > placed in a new 'openssl-gen' subdirectory, no matter whenever > they are header files, C files or asm files. > > Some code changes are needed for openssl 3.0, those are mostly > unchanged when comparing to my ~1y old branch. Exceptions are > some EC-related changes. > > Acceleration support has been expanded to also cover AARCH64 > with GCC5. > > The old openssl-1.1 apparently tries to avoid adding support > for avx for asm acceleration, by taking care that nasm is not > in the path. That trick will surely will not work with > openssl-3.0 as openssl has learned to generate avx instructions > for other assemblers meanwhile. > > Is there some specific reason for that? > Compatibility with toolchains without avx support? > Or is firmware not allowed to use avx instructions? > > In case of the latter we probably have to add a 'no-avx' config option > to upstream openssl, similiar to the 'no-sse2' option which already > exists. > > take care, > Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#101003): https://edk2.groups.io/g/devel/message/101003 Mute This Topic: https://groups.io/mt/96741156/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
