Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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):
Before:
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):
libgcrypt-1.8.3-4.el8
How reproducible:
Aleays
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.
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
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?
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.
https://access.redhat.com/errata/RHSA-2020:4482
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): Before: 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): libgcrypt-1.8.3-4.el8 How reproducible: Aleays 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.