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


Zurcher, Christopher J
 

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

Join devel@edk2.groups.io to automatically receive all group messages.