[edk2-devel] [PATCH v5 0/2] CryptoPkg/OpensslLib: Add native instruction support for X64

[Yao, Jiewen]

I full agree with long term plan. E.g. we need remove ApiHook.c as well.

I more concern about the short term plan, if you want to check in this and get the capability.

I think we need this capability for GCC tool chain as well, so I am OK to check in .S.
This is auto generated. I do not think it is a step back.

We can remove them together with ApiHook later, in the long term.

Thank you
Yao Jiewen


> -----Original Message-----
> From: Zurcher, Christopher J <christopher.j.zurcher at intel.com>
> Sent: Wednesday, November 11, 2020 9:43 AM
> To: Yao, Jiewen <jiewen.yao at intel.com>; Laszlo Ersek <lersek at redhat.com>
> Cc: devel at edk2.groups.io; gaoliming <gaoliming at byosoft.com.cn>; Wang,
> Jian J <jian.j.wang at intel.com>; Lu, XiaoyuX <xiaoyux.lu at intel.com>; Kinney,
> Michael D <michael.d.kinney at intel.com>; Ard Biesheuvel
> <ard.biesheuvel at arm.com>
> Subject: RE: [edk2-devel] [PATCH v5 0/2] CryptoPkg/OpensslLib: Add native
> instruction support for X64
> 
> I don't want to speak for Laszlo but I filed an issue against OpenSSL that the
> NASM build should not assume win64:
> https://github.com/openssl/openssl/issues/12712
> 
> The issue was triaged as a bug by OpenSSL, so I think the long-term plan
> would be to fix OpenSSL to not set win64 flag by default on all NASM builds,
> at which point I think we should be able to use the same NASM files for VS
> and GCC. I'm not sure if the classification as a bug means the fix could be
> made in 1.1.1x builds or if it could only go into 3.x.
> 
> Thanks,
> Christopher Zurcher
> 
> > -----Original Message-----
> > From: Yao, Jiewen <jiewen.yao at intel.com>
> > Sent: Tuesday, November 10, 2020 09:08
> > To: Laszlo Ersek <lersek at redhat.com>; Zurcher, Christopher J
> > <christopher.j.zurcher at intel.com>
> > Cc: devel at edk2.groups.io; gaoliming <gaoliming at byosoft.com.cn>; Wang,
> Jian J
> > <jian.j.wang at intel.com>; Lu, XiaoyuX <xiaoyux.lu at intel.com>; Kinney,
> Michael
> > D <michael.d.kinney at intel.com>; Ard Biesheuvel
> <ard.biesheuvel at arm.com>
> > Subject: RE: [edk2-devel] [PATCH v5 0/2] CryptoPkg/OpensslLib: Add native
> > instruction support for X64
> >
> > Laszlo.
> > If you disagree, what is your proposal?
> >
> >
> > > -----Original Message-----
> > > From: Laszlo Ersek <lersek at redhat.com>
> > > Sent: Tuesday, November 10, 2020 8:31 PM
> > > To: Yao, Jiewen <jiewen.yao at intel.com>; Zurcher, Christopher J
> > > <christopher.j.zurcher at intel.com>
> > > Cc: devel at edk2.groups.io; gaoliming <gaoliming at byosoft.com.cn>;
> Wang,
> > > Jian J <jian.j.wang at intel.com>; Lu, XiaoyuX <xiaoyux.lu at intel.com>;
> Kinney,
> > > Michael D <michael.d.kinney at intel.com>; Ard Biesheuvel
> > > <ard.biesheuvel at arm.com>
> > > Subject: Re: [edk2-devel] [PATCH v5 0/2] CryptoPkg/OpensslLib: Add
> native
> > > instruction support for X64
> > >
> > > On 11/07/20 03:24, Yao, Jiewen wrote:
> > > > The reason we choose NASM is that we can use same assembly in
> windows
> > > build and Linux build. However if this NASM cannot be used in Linux, then
> > > the benefit does not exist any more. You can generate GAS to support
> GCC
> > > build, and check in .S file.
> > >
> > > I disagree with this idea. To me (as an exclusive GCC user), uniformity
> > > of assembly files is *much* more important than getting native
> > > instruction support in OpenSSL with all toolchains at the exact same time.
> > >
> > > If we enable native instruction support for (a) VS and CLANGPDB now,
> and
> > > (b) for GCC later, then that's two steps, with each step being in the
> > > forward direction. Performing just (a) for now creates no technical
> > > debt. A feature gap is not technical debt; you cannot mistake a missing
> > > feature for a working feature.
> > >
> > > If we re-add .S files now, for whatever purpose, that's a step *back*,
> > > however. It creates technical debt. A working feature on an invalid
> > > basis *can* be mistaken for a working feature, and we shouldn't do that
> > > (unless there are strong business needs for some participants, *AND* we
> > > have a *very specific* plan and timeline for backing out the hack). I
> > > really don't have any trust in technical debt being "paid" in edk2
> > > anytime soon, though.
> > >
> > > Thanks
> > > Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#67266): https://edk2.groups.io/g/devel/message/67266
Mute This Topic: https://groups.io/mt/78017396/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-