public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ard.biesheuvel@arm.com>
To: "Zurcher, Christopher J" <christopher.j.zurcher@intel.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "Wang, Jian J" <jian.j.wang@intel.com>,
	"Lu, XiaoyuX" <xiaoyux.lu@intel.com>,
	"Jiang, Guomin" <guomin.jiang@intel.com>,
	Sung-Uk Bin <sunguk-bin@hp.com>, Laszlo Ersek <lersek@redhat.com>
Subject: Re: [PATCH 0/1] CryptoPkg/BaseCryptLib: Add EVP implementation for CryptAes.c
Date: Tue, 3 Nov 2020 08:51:29 +0100	[thread overview]
Message-ID: <2f4cafab-9748-a898-2e78-f00907ffc348@arm.com> (raw)
In-Reply-To: <MWHPR1101MB21258BC569E19B41E246BF31B3100@MWHPR1101MB2125.namprd11.prod.outlook.com>

On 11/2/20 11:36 PM, Zurcher, Christopher J wrote:
> The size increase from adding the EVP interface to a module that does not already include it (through the HMAC functions) is ~192KB.

Which HMAC function do we use in UEFI that needs AES? Adding 192 KB for 
AES to each module that only uses HMAC-SHAxxx seems like a really bad 
idea to me. Maybe the IEEE 802.11 drivers have some dependencies on 
CBC-MAC for CCMP, but I don't think any wifi hardware exists today that 
relies on software support for this, so using optimized code here makes 
little sense.

Also, how does the 32% to 47% speed improvement translate to actual boot 
speed improvements? A lot of the crypto is only applied to small 
quantities of data, and only the algorithms that are applied to 
arbitrary size chunks should be optimized in this way, imo.

Note that, while widely regarded as the fastest, the OpenSSL asm 
implementations are not as robust as you might think, and they don't see 
a lot of test coverage running in a bare metal context with elevated 
privileges like we do in EDK2.

(I may have brought up some of these points before - apologies if 
anything I say sounds redundant).



> Intel documentation on the IA version of the feature lists speed improvement of ~32% to ~47% depending on the operation and key size. Other architectures may see different speed improvements. I have only tested this file with OvmfPkg through QEMU.
> 
> I did not add this .c file to any INF file because it will add ~192KB to any module that includes AES functionality and it should be up to the end user if they want to include this file for the size tradeoff vs. the speed gain for their particular architecture. Additionally as the only native OpensslLib implementation available currently is for X64 architecture, any other architecture would have a size increase with no speed improvement.
> 
> Thanks,
> Christopher Zurcher
> 
>> -----Original Message-----
>> From: Yao, Jiewen <jiewen.yao@intel.com>
>> Sent: Friday, October 30, 2020 18:10
>> To: Zurcher, Christopher J <christopher.j.zurcher@intel.com>;
>> devel@edk2.groups.io
>> Cc: Wang, Jian J <jian.j.wang@intel.com>; Lu, XiaoyuX <xiaoyux.lu@intel.com>;
>> Jiang, Guomin <guomin.jiang@intel.com>; Sung-Uk Bin <sunguk-bin@hp.com>; Ard
>> Biesheuvel <ard.biesheuvel@arm.com>
>> Subject: RE: [PATCH 0/1] CryptoPkg/BaseCryptLib: Add EVP implementation for
>> CryptAes.c
>>
>> HI Zucher
>> I am not sure why you only add a .c file, but do not add this c to any INF
>> file. This seems a dummy C file.
>> I recommend you drop this and create a full patch to add C and update INF
>> file.
>>
>> Since you are talking performance and size, do you have any data?
>> For example, how fast you have got? What is the size difference before and
>> after?
>> This can help other people make decision to choose which version.
>>
>>
>> Thank you
>> Yao Jiewen
>>
>>
>>> -----Original Message-----
>>> From: Christopher J Zurcher <christopher.j.zurcher@intel.com>
>>> Sent: Thursday, October 29, 2020 2:43 AM
>>> To: devel@edk2.groups.io
>>> Cc: Yao, Jiewen <jiewen.yao@intel.com>; Wang, Jian J
>>> <jian.j.wang@intel.com>; Lu, XiaoyuX <xiaoyux.lu@intel.com>; Jiang, Guomin
>>> <guomin.jiang@intel.com>; Sung-Uk Bin <sunguk-bin@hp.com>; Ard
>>> Biesheuvel <ard.biesheuvel@arm.com>
>>> Subject: [PATCH 0/1] CryptoPkg/BaseCryptLib: Add EVP implementation for
>>> CryptAes.c
>>>
>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2507
>>>
>>> This patch provides a drop-in replacement for CryptAes.c which utilizes
>>> the EVP interface to OpenSSL. This enables access to the assembly-optimized
>>> algorithms.
>>>
>>> This patch has been unit-tested in both VS and CLANG build environments
>>> using both an X64 assembly-optimized implementation of OpensslLib and
>>> the
>>> standard implementation.
>>>
>>> Usage of this file does not require an assembly-optimized implementation of
>>> OpensslLib to function; it does however require one to provide a speed
>>> improvement.
>>>
>>> The C-only AES implementation included by CryptAes.c is extremely small,
>>> and since this file includes the EVP interface, it will significantly
>>> increase the size of any module that includes it. As a result, I have not
>>> replaced the original CryptAes.c as a default in any of the CryptLib
>>> implementations.
>>>
>>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>>> Cc: Jian J Wang <jian.j.wang@intel.com>
>>> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
>>> Cc: Guomin Jiang <guomin.jiang@intel.com>
>>> Cc: Sung-Uk Bin <sunguk-bin@hp.com>
>>> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
>>>
>>> Christopher J Zurcher (1):
>>>    CryptoPkg/BaseCryptLib: Add EVP implementation for CryptAes.c
>>>
>>>   CryptoPkg/Library/BaseCryptLib/Cipher/CryptAesEvp.c | 262
>>> ++++++++++++++++++++
>>>   1 file changed, 262 insertions(+)
>>>   create mode 100644 CryptoPkg/Library/BaseCryptLib/Cipher/CryptAesEvp.c
>>>
>>> --
>>> 2.28.0.windows.1
> 


  parent reply	other threads:[~2020-11-03  7:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-28 18:42 [PATCH 0/1] CryptoPkg/BaseCryptLib: Add EVP implementation for CryptAes.c Zurcher, Christopher J
2020-10-28 18:42 ` [PATCH 1/1] " Zurcher, Christopher J
2020-10-31  1:10 ` [PATCH 0/1] " Yao, Jiewen
2020-11-02 22:36   ` Zurcher, Christopher J
2020-11-03  1:13     ` Yao, Jiewen
2020-11-03  1:22       ` Bret Barkelew
2020-11-03 21:54         ` Zurcher, Christopher J
2020-11-03 23:03           ` Yao, Jiewen
2020-11-03  7:51     ` Ard Biesheuvel [this message]
2020-11-03 19:15       ` Zurcher, Christopher J

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2f4cafab-9748-a898-2e78-f00907ffc348@arm.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox