Bug 1762765

Summary: RFE: hardware accelerated AES-XTS mode
Product: Red Hat Enterprise Linux 8 Reporter: Daniel Berrangé <berrange>
Component: libgcryptAssignee: Tomas Mraz <tmraz>
Status: CLOSED ERRATA QA Contact: Ivan Nikolchev <inikolch>
Severity: high Docs Contact:
Priority: high    
Version: 8.0CC: bugproxy, dgibson, fiezzi, gcharot, hannsj_uhl, inikolch, kchamart, mmethot, moddi, nmavrogi, omoris
Target Milestone: rcKeywords: FutureFeature, Triaged
Target Release: 8.3   
Hardware: All   
OS: Linux   
Fixed In Version: libgcrypt-1.8.5-1.el8 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-04 01:44:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1680226, 1701948, 1719252, 1776265, 1828681, 1839916    

Description Daniel Berrangé 2019-10-17 12:31:52 UTC
Description of problem:

Upstream libgcrpt git master has a change to AES-XTS that implements AES-NI acceleration. The performance improvements reported in the commit message are astonishing and I've confirmed them myself. 

commit a00c5b2988cea256c7823a76ce601febf02c790f (HEAD)
Author: Jussi Kivilinna <jussi.kivilinna>
Date:   Sat Jan 6 18:53:20 2018 +0200

    Add AES-NI acceleration for AES-XTS
    * cipher/cipher-internal.h (gcry_cipher_handle): Change bulk
    XTS function to take cipher context.
    * cipher/cipher-xts.c (_gcry_cipher_xts_crypt): Ditto.
    * cipher/cipher.c (_gcry_cipher_open_internal): Setup AES-NI
    XTS bulk function.
    * cipher/rijndael-aesni.c (xts_gfmul_const, _gcry_aes_aesni_xts_enc)
    (_gcry_aes_aesni_xts_enc, _gcry_aes_aesni_xts_crypt): New.
    * cipher/rijndael.c (_gcry_aes_aesni_xts_crypt)
    (_gcry_aes_xts_crypt): New.
    * src/cipher.h (_gcry_aes_xts_crypt): New.
    Benchmarks on Intel Core i7-4790K, 4.0Ghz (no turbo):
            XTS enc |      1.66 ns/B     575.7 MiB/s      6.63 c/B
            XTS dec |      1.66 ns/B     575.5 MiB/s      6.63 c/B
    After (~6x faster):
            XTS enc |     0.270 ns/B    3528.5 MiB/s      1.08 c/B
            XTS dec |     0.272 ns/B    3511.5 MiB/s      1.09 c/B
    Signed-off-by: Jussi Kivilinna <jussi.kivilinna>

Unfortunately there's been no upstream release with this code present.

This will have a massive benefit for QEMU's LUKS implementation I/O performance since AES-XTS is the default mode though. Thus from QEMU's POV we'd like to explore options for getting this performance increase available in RHEL-8. 

Whether that's a backport to 1.8.3, or waiting & rebasing to 1.9.0 in some 8.x update doesn't matter to QEMU - we'd just like to find a way to achieve this level of performance without having to wait until RHEL-9.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run a AES-XTS performance benchmark on RHEL-8 libgcrypt 1.8.3
2. Run a AES-XTS performance benchmark on libgcrypt git master

Actual results:
Git master gcrypt is x5 or more faster than RHEL-8 gcrypt

Expected results:
RHEL-8 gcrypt is approx same speed as git upstream.

Additional info:

QEMU had been intending to make use of gnutls for ciphers, and gnutls/nettle both gained XTS support to this end. This performance boost from gcrypt git master is too large to ignore. If gnutls/nettle could be enhanced to match this performance result though in a reasonable timeframe, that could still be a viable option for QEMU too.

Comment 1 Tomas Mraz 2019-10-17 13:11:49 UTC
I think it would be feasible to backport this.

Comment 3 Daniel Berrangé 2019-11-25 10:09:42 UTC
The upstream gcrypt commit referenced in the initial bug description is covering x86_64 architecture.

This comment is to note that from QEMU POV, we desire accelerated support backported on all architectures where it is available as QEMU runs on x86_64, aarch64, ppc64le, s390x. 

It looks like gcrypt has got 3 out of 4 covered upstream, only s390x missing.

IIUC, support for PPC was added in

commit 81d555d3473016eb9382fb1df153ba1effbbe32e
Author: Jussi Kivilinna <jussi.kivilinna>
Date:   Wed Aug 21 20:53:16 2019 +0300

    rijndael-ppc: add bulk modes for CBC, CFB, CTR and XTS

And IIUC, support for AArch64 was added in

commit 93503c127a52c1f6a193750e2bf181a744ba3e6b
Author: Jussi Kivilinna <jussi.kivilinna>
Date:   Sat Jan 20 22:05:19 2018 +0200

    Add ARMv8/CE acceleration for AES-XTS

Comment 4 Tomas Mraz 2020-02-02 16:42:14 UTC
The PPC and AES-XTS bulk mode patches are attached to bug 1680226.

Comment 5 Tomas Mraz 2020-02-26 13:48:22 UTC
I was notified that QEMU was supposed to be moving to use gnutls for crypto and AES-XTS in particular as well. We had some RFEs implemented for gnutls on RHEL-8.2. So is that plan to move to gnutls no longer true?

Comment 17 errata-xmlrpc 2020-11-04 01:44:25 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: libgcrypt security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.