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

["Zurcher, Christopher J" <christopher.j.zurcher@intel.com>]

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@intel.com>
> Sent: Tuesday, November 10, 2020 09:08
> To: Laszlo Ersek <lersek@redhat.com>; Zurcher, Christopher J
> <christopher.j.zurcher@intel.com>
> Cc: devel@edk2.groups.io; gaoliming <gaoliming@byosoft.com.cn>; Wang, Jian J
> <jian.j.wang@intel.com>; Lu, XiaoyuX <xiaoyux.lu@intel.com>; Kinney, Michael
> D <michael.d.kinney@intel.com>; Ard Biesheuvel <ard.biesheuvel@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@redhat.com>
> > Sent: Tuesday, November 10, 2020 8:31 PM
> > To: Yao, Jiewen <jiewen.yao@intel.com>; Zurcher, Christopher J
> > <christopher.j.zurcher@intel.com>
> > Cc: devel@edk2.groups.io; gaoliming <gaoliming@byosoft.com.cn>; Wang,
> > Jian J <jian.j.wang@intel.com>; Lu, XiaoyuX <xiaoyux.lu@intel.com>; Kinney,
> > Michael D <michael.d.kinney@intel.com>; Ard Biesheuvel
> > <ard.biesheuvel@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