RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1762765 - RFE: hardware accelerated AES-XTS mode
Summary: RFE: hardware accelerated AES-XTS mode
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libgcrypt
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: rc
: 8.3
Assignee: Tomas Mraz
QA Contact: Ivan Nikolchev
Depends On:
Blocks: 1680226 1701948 1719252 1776265 1828681 1839916
TreeView+ depends on / blocked
Reported: 2019-10-17 12:31 UTC by Daniel Berrangé
Modified: 2023-10-06 18:40 UTC (History)
11 users (show)

Fixed In Version: libgcrypt-1.8.5-1.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Last Closed: 2020-11-04 01:44:25 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 182571 0 None None None 2019-11-25 13:32:16 UTC
Red Hat Bugzilla 1549573 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Issue Tracker CRYPTO-1201 0 None None None 2021-11-03 05:19:55 UTC
Red Hat Knowledge Base (Solution) 4815611 0 None None None 2020-05-22 15:56:03 UTC
Red Hat Product Errata RHSA-2020:4482 0 None None None 2020-11-04 01:45:02 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.