Bug 1762765
| Summary: | RFE: hardware accelerated AES-XTS mode | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Daniel Berrangé <berrange> |
| Component: | libgcrypt | Assignee: | Tomas Mraz <tmraz> |
| Status: | CLOSED ERRATA | QA Contact: | Ivan Nikolchev <inikolch> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.0 | CC: | bugproxy, dgibson, fiezzi, gcharot, hannsj_uhl, inikolch, kchamart, mmethot, moddi, nmavrogi, omoris |
| Target Milestone: | rc | Keywords: | FutureFeature, Triaged |
| Target Release: | 8.3 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1680226, 1701948, 1719252, 1776265, 1828681, 1839916 | ||
I think it would be feasible to backport this. 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
The PPC and AES-XTS bulk mode patches are attached to bug 1680226. 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.