Skip to contentSkip to conversation

crypto: Accelerated GCM for IPSec on ARM/arm64

PATCH In review Ard Biesheuvel 2 participants 11 messages Dec 14, 2022 – Jan 20, 2023

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

v2 cover crypto: Accelerated GCM for IPSec on ARM/arm64

This is a v2 as patch #1 was sent out in isolation a couple of days ago.

As it turns out, we can get ~10% speedup for RFC4106 on arm64 (Cortex-A53) by giving it the same treatment as ARM, i.e., avoid the generic template and implement RFC4106 encapsulation directly in the driver

Patch #3 adds larger key sizes to the tcrypt benchmark for RFC4106

Patch #4 fixes some prose on AEAD that turned out to be inaccurate.

Changes since v1:
- minor tweaks to the asm code in patch #1, one of which to fix a Clang build error

Note: patch #1 depends on the softirq context patches for kernel mode NEON I sent out last week. More specifically, this implements a sync AEAD that does not implement a !simd fallback, as AEADs are not callable in hard IRQ context anyway.

Cc Eric Biggers <[email protected]>
Cc Herbert Xu <[email protected]>

Ard Biesheuvel (4):
crypto: arm/ghash - implement fused AES/GHASH version of AES-GCM
crypto: arm64/gcm - add RFC4106 support
crypto: tcrypt - include larger key sizes in RFC4106 benchmark
crypto: aead - fix inaccurate documentation

 arch/arm/crypto/Kconfig           |   2 +
 arch/arm/crypto/ghash-ce-core.S   | 382 +++++++++++++++++-
 arch/arm/crypto/ghash-ce-glue.c   | 424 +++++++++++++++++++-
 arch/arm64/crypto/ghash-ce-glue.c | 145 +++++--
 crypto/tcrypt.c                   |   8 +-
 crypto/tcrypt.h                   |   2 +-
 include/crypto/aead.h             |  20 +-
 7 files changed, 913 insertions(+), 70 deletions(-)
Signature · 1 line
2.35.1
#1 lore raw

PATCH v2 1/4 crypto: arm/ghash - implement fused AES/GHASH version of AES-GCM

On 32-bit ARM, AES in GCM mode takes full advantage of the ARMv8 Crypto Extensions when available, resulting in a performance of 6-7 cycles per byte for typical IPsec frames on cores such as Cortex-A53, using the generic GCM template encapsulating the accelerated AES-CTR and GHASH implementations.

At such high rates, any time spent copying data or doing other poorly optimized work in the generic layer hurts disproportionately, and we can get a significant performance improvement by combining the optimized AES-CTR and GHASH implementations into a single one.

On Cortex-A53, this results in a performance improvement of around 75%, or 4 cycles per byte for AES-256-GCM-128 with RFC4106 encapsulation. The fastest mode on this core is bare AES-128-GCM using 8k blocks, which manages 2.7 cycles per byte.

---
 arch/arm/crypto/Kconfig         |   2 +
 arch/arm/crypto/ghash-ce-core.S | 382 +++++++++++++++++-
 arch/arm/crypto/ghash-ce-glue.c | 424 +++++++++++++++++++-
 3 files changed, 791 insertions(+), 17 deletions(-)
arch/arm/crypto/Kconfig +2 -0
index 3858c4d4cb98854d..c693a4fdf3771e63 100644
@@ -16,9 +16,11 @@ config CRYPTO_CURVE25519_NEON
 config CRYPTO_GHASH_ARM_CE
 	tristate "Hash functions: GHASH (PMULL/NEON/ARMv8 Crypto Extensions)"
 	depends on KERNEL_MODE_NEON
+	select CRYPTO_AEAD
 	select CRYPTO_HASH
 	select CRYPTO_CRYPTD
 	select CRYPTO_GF128MUL
+	select CRYPTO_LIB_AES
 	help
 	  GCM GHASH function (NIST SP800-38D)
 
arch/arm/crypto/ghash-ce-core.S +369 -13

453 lines not on this page · raw message

arch/arm/crypto/ghash-ce-glue.c +420 -4

486 lines not on this page · raw message

Signature · 1 line
2.35.1
#2 lore raw

PATCH v2 2/4 crypto: arm64/gcm - add RFC4106 support

In reply to Ard Biesheuvel

Add support for RFC4106 ESP encapsulation to the accelerated GCM implementation. This results in a ~10% speedup for IPsec frames of typical size (~1420 bytes) on Cortex-A53.

---
 arch/arm64/crypto/ghash-ce-glue.c | 145 +++++++++++++++-----
 1 file changed, 107 insertions(+), 38 deletions(-)
arch/arm64/crypto/ghash-ce-glue.c +107 -38
index 15794fe21a0b2eca..4b45fad493b16239 100644
@@ -9,6 +9,7 @@
 #include <asm/simd.h>
 #include <asm/unaligned.h>
 #include <crypto/aes.h>
+#include <crypto/gcm.h>
 #include <crypto/algapi.h>
 #include <crypto/b128ops.h>
 #include <crypto/gf128mul.h>
@@ -28,7 +29,8 @@ MODULE_ALIAS_CRYPTO("ghash");
 
 #define GHASH_BLOCK_SIZE	16
 #define GHASH_DIGEST_SIZE	16
-#define GCM_IV_SIZE		12
+
+#define RFC4106_NONCE_SIZE	4
 
 struct ghash_key {
 	be128			k;
@@ -43,6 +45,7 @@ struct ghash_desc_ctx {
 
 struct gcm_aes_ctx {
 	struct crypto_aes_ctx	aes_key;
+	u8			nonce[RFC4106_NONCE_SIZE];
 	struct ghash_key	ghash_key;
 };
 
@@ -226,8 +229,8 @@ static int num_rounds(struct crypto_aes_ctx *ctx)
 	return 6 + ctx->key_length / 4;
 }
 
-static int gcm_setkey(struct crypto_aead *tfm, const u8 *inkey,
-		      unsigned int keylen)
+static int gcm_aes_setkey(struct crypto_aead *tfm, const u8 *inkey,
+			  unsigned int keylen)
 {
 	struct gcm_aes_ctx *ctx = crypto_aead_ctx(tfm);
 	u8 key[GHASH_BLOCK_SIZE];
@@ -258,17 +261,9 @@ static int gcm_setkey(struct crypto_aead *tfm, const u8 *inkey,
 	return 0;
 }
 
-static int gcm_setauthsize(struct crypto_aead *tfm, unsigned int authsize)
+static int gcm_aes_setauthsize(struct crypto_aead *tfm, unsigned int authsize)
 {
-	switch (authsize) {
-	case 4:
-	case 8:
-	case 12 ... 16:
-		break;
-	default:
-		return -EINVAL;
-	}
-	return 0;
+	return crypto_gcm_check_authsize(authsize);
 }
 
 static void gcm_update_mac(u64 dg[], const u8 *src, int count, u8 buf[],
@@ -302,13 +297,12 @@ static void gcm_update_mac(u64 dg[], const u8 *src, int count, u8 buf[],
 	}
 }
 
-static void gcm_calculate_auth_mac(struct aead_request *req, u64 dg[])
+static void gcm_calculate_auth_mac(struct aead_request *req, u64 dg[], u32 len)
 {
 	struct crypto_aead *aead = crypto_aead_reqtfm(req);
 	struct gcm_aes_ctx *ctx = crypto_aead_ctx(aead);
 	u8 buf[GHASH_BLOCK_SIZE];
 	struct scatter_walk walk;
-	u32 len = req->assoclen;
 	int buf_count = 0;
 
 	scatterwalk_start(&walk, req->src);
@@ -338,27 +332,25 @@ static void gcm_calculate_auth_mac(struct aead_request *req, u64 dg[])
 	}
 }
 
-static int gcm_encrypt(struct aead_request *req)
+static int gcm_encrypt(struct aead_request *req, char *iv, int assoclen)
 {
 	struct crypto_aead *aead = crypto_aead_reqtfm(req);
 	struct gcm_aes_ctx *ctx = crypto_aead_ctx(aead);
 	int nrounds = num_rounds(&ctx->aes_key);
 	struct skcipher_walk walk;
 	u8 buf[AES_BLOCK_SIZE];
-	u8 iv[AES_BLOCK_SIZE];
 	u64 dg[2] = {};
 	be128 lengths;
 	u8 *tag;
 	int err;
 
-	lengths.a = cpu_to_be64(req->assoclen * 8);
+	lengths.a = cpu_to_be64(assoclen * 8);
 	lengths.b = cpu_to_be64(req->cryptlen * 8);
 
-	if (req->assoclen)
-		gcm_calculate_auth_mac(req, dg);
+	if (assoclen)
+		gcm_calculate_auth_mac(req, dg, assoclen);
 
-	memcpy(iv, req->iv, GCM_IV_SIZE);
-	put_unaligned_be32(2, iv + GCM_IV_SIZE);
+	put_unaligned_be32(2, iv + GCM_AES_IV_SIZE);
 
 	err = skcipher_walk_aead_encrypt(&walk, req, false);
 
@@ -403,7 +395,7 @@ static int gcm_encrypt(struct aead_request *req)
 	return 0;
 }
 
-static int gcm_decrypt(struct aead_request *req)
+static int gcm_decrypt(struct aead_request *req, char *iv, int assoclen)
 {
 	struct crypto_aead *aead = crypto_aead_reqtfm(req);
 	struct gcm_aes_ctx *ctx = crypto_aead_ctx(aead);
@@ -412,21 +404,19 @@ static int gcm_decrypt(struct aead_request *req)
 	struct skcipher_walk walk;
 	u8 otag[AES_BLOCK_SIZE];
 	u8 buf[AES_BLOCK_SIZE];
-	u8 iv[AES_BLOCK_SIZE];
 	u64 dg[2] = {};
 	be128 lengths;
 	u8 *tag;
 	int ret;
 	int err;
 
-	lengths.a = cpu_to_be64(req->assoclen * 8);
+	lengths.a = cpu_to_be64(assoclen * 8);
 	lengths.b = cpu_to_be64((req->cryptlen - authsize) * 8);
 
-	if (req->assoclen)
-		gcm_calculate_auth_mac(req, dg);
+	if (assoclen)
+		gcm_calculate_auth_mac(req, dg, assoclen);
 
-	memcpy(iv, req->iv, GCM_IV_SIZE);
-	put_unaligned_be32(2, iv + GCM_IV_SIZE);
+	put_unaligned_be32(2, iv + GCM_AES_IV_SIZE);
 
 	scatterwalk_map_and_copy(otag, req->src,
 				 req->assoclen + req->cryptlen - authsize,
@@ -471,14 +461,76 @@ static int gcm_decrypt(struct aead_request *req)
 	return ret ? -EBADMSG : 0;
 }
 
-static struct aead_alg gcm_aes_alg = {
-	.ivsize			= GCM_IV_SIZE,
+static int gcm_aes_encrypt(struct aead_request *req)
+{
+	u8 iv[AES_BLOCK_SIZE];
+
+	memcpy(iv, req->iv, GCM_AES_IV_SIZE);
+	return gcm_encrypt(req, iv, req->assoclen);
+}
+
+static int gcm_aes_decrypt(struct aead_request *req)
+{
+	u8 iv[AES_BLOCK_SIZE];
+
+	memcpy(iv, req->iv, GCM_AES_IV_SIZE);
+	return gcm_decrypt(req, iv, req->assoclen);
+}
+
+static int rfc4106_setkey(struct crypto_aead *tfm, const u8 *inkey,
+			  unsigned int keylen)
+{
+	struct gcm_aes_ctx *ctx = crypto_aead_ctx(tfm);
+	int err;
+
+	keylen -= RFC4106_NONCE_SIZE;
+	err = gcm_aes_setkey(tfm, inkey, keylen);
+	if (err)
+		return err;
+
+	memcpy(ctx->nonce, inkey + keylen, RFC4106_NONCE_SIZE);
+	return 0;
+}
+
+static int rfc4106_setauthsize(struct crypto_aead *tfm, unsigned int authsize)
+{
+	return crypto_rfc4106_check_authsize(authsize);
+}
+
+static int rfc4106_encrypt(struct aead_request *req)
+{
+	struct crypto_aead *aead = crypto_aead_reqtfm(req);
+	struct gcm_aes_ctx *ctx = crypto_aead_ctx(aead);
+	u8 iv[AES_BLOCK_SIZE];
+
+	memcpy(iv, ctx->nonce, RFC4106_NONCE_SIZE);
+	memcpy(iv + RFC4106_NONCE_SIZE, req->iv, GCM_RFC4106_IV_SIZE);
+
+	return crypto_ipsec_check_assoclen(req->assoclen) ?:
+	       gcm_encrypt(req, iv, req->assoclen - GCM_RFC4106_IV_SIZE);
+}
+
+static int rfc4106_decrypt(struct aead_request *req)
+{
+	struct crypto_aead *aead = crypto_aead_reqtfm(req);
+	struct gcm_aes_ctx *ctx = crypto_aead_ctx(aead);
+	u8 iv[AES_BLOCK_SIZE];
+
+	memcpy(iv, ctx->nonce, RFC4106_NONCE_SIZE);
+	memcpy(iv + RFC4106_NONCE_SIZE, req->iv, GCM_RFC4106_IV_SIZE);
+
+	return crypto_ipsec_check_assoclen(req->assoclen) ?:
+	       gcm_decrypt(req, iv, req->assoclen - GCM_RFC4106_IV_SIZE);
+}
+
+static struct aead_alg gcm_aes_algs[] = {{
+	.ivsize			= GCM_AES_IV_SIZE,
 	.chunksize		= AES_BLOCK_SIZE,
 	.maxauthsize		= AES_BLOCK_SIZE,
-	.setkey			= gcm_setkey,
-	.setauthsize		= gcm_setauthsize,
-	.encrypt		= gcm_encrypt,
-	.decrypt		= gcm_decrypt,
+	.setkey			= gcm_aes_setkey,
+	.setauthsize		= gcm_aes_setauthsize,
+	.encrypt		= gcm_aes_encrypt,
+	.decrypt		= gcm_aes_decrypt,
 
 	.base.cra_name		= "gcm(aes)",
 	.base.cra_driver_name	= "gcm-aes-ce",
@@ -487,7 +539,23 @@ static struct aead_alg gcm_aes_alg = {
 	.base.cra_ctxsize	= sizeof(struct gcm_aes_ctx) +
 				  4 * sizeof(u64[2]),
 	.base.cra_module	= THIS_MODULE,
-};
+}, {
+	.ivsize			= GCM_RFC4106_IV_SIZE,
+	.chunksize		= AES_BLOCK_SIZE,
+	.maxauthsize		= AES_BLOCK_SIZE,
+	.setkey			= rfc4106_setkey,
+	.setauthsize		= rfc4106_setauthsize,
+	.encrypt		= rfc4106_encrypt,
+	.decrypt		= rfc4106_decrypt,
+
+	.base.cra_name		= "rfc4106(gcm(aes))",
+	.base.cra_driver_name	= "rfc4106-gcm-aes-ce",
+	.base.cra_priority	= 300,
+	.base.cra_blocksize	= 1,
+	.base.cra_ctxsize	= sizeof(struct gcm_aes_ctx) +
+				  4 * sizeof(u64[2]),
+	.base.cra_module	= THIS_MODULE,
+}};
 
 static int __init ghash_ce_mod_init(void)
 {
@@ -495,7 +563,8 @@ static int __init ghash_ce_mod_init(void)
 		return -ENODEV;
 
 	if (cpu_have_named_feature(PMULL))
-		return crypto_register_aead(&gcm_aes_alg);
+		return crypto_register_aeads(gcm_aes_algs,
+					     ARRAY_SIZE(gcm_aes_algs));
 
 	return crypto_register_shash(&ghash_alg);
 }
@@ -503,7 +572,7 @@ static int __init ghash_ce_mod_init(void)
 static void __exit ghash_ce_mod_exit(void)
 {
 	if (cpu_have_named_feature(PMULL))
-		crypto_unregister_aead(&gcm_aes_alg);
+		crypto_unregister_aeads(gcm_aes_algs, ARRAY_SIZE(gcm_aes_algs));
 	else
 		crypto_unregister_shash(&ghash_alg);
 }
Signature · 1 line
2.35.1
#3 lore raw

PATCH v2 3/4 crypto: tcrypt - include larger key sizes in RFC4106 benchmark

In reply to Ard Biesheuvel

RFC4106 wraps AES in GCM mode, and can be used with larger key sizes than 128/160 bits, just like AES itself. So add these to the tcrypt recipe so they will be benchmarked as well.

---
 crypto/tcrypt.c | 8 ++++----
 crypto/tcrypt.h | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)
crypto/tcrypt.c +4 -4
index a82679b576bb4381..1e4c7699801a6ffa 100644
@@ -2045,11 +2045,11 @@ static int do_test(const char *alg, u32 type, u32 mask, int m, u32 num_mb)
 
 	case 211:
 		test_aead_speed("rfc4106(gcm(aes))", ENCRYPT, sec,
-				NULL, 0, 16, 16, aead_speed_template_20);
+				NULL, 0, 16, 16, aead_speed_template_20_28_36);
 		test_aead_speed("gcm(aes)", ENCRYPT, sec,
 				NULL, 0, 16, 8, speed_template_16_24_32);
 		test_aead_speed("rfc4106(gcm(aes))", DECRYPT, sec,
-				NULL, 0, 16, 16, aead_speed_template_20);
+				NULL, 0, 16, 16, aead_speed_template_20_28_36);
 		test_aead_speed("gcm(aes)", DECRYPT, sec,
 				NULL, 0, 16, 8, speed_template_16_24_32);
 		break;
@@ -2075,11 +2075,11 @@ static int do_test(const char *alg, u32 type, u32 mask, int m, u32 num_mb)
 
 	case 215:
 		test_mb_aead_speed("rfc4106(gcm(aes))", ENCRYPT, sec, NULL,
-				   0, 16, 16, aead_speed_template_20, num_mb);
+				   0, 16, 16, aead_speed_template_20_28_36, num_mb);
 		test_mb_aead_speed("gcm(aes)", ENCRYPT, sec, NULL, 0, 16, 8,
 				   speed_template_16_24_32, num_mb);
 		test_mb_aead_speed("rfc4106(gcm(aes))", DECRYPT, sec, NULL,
-				   0, 16, 16, aead_speed_template_20, num_mb);
+				   0, 16, 16, aead_speed_template_20_28_36, num_mb);
 		test_mb_aead_speed("gcm(aes)", DECRYPT, sec, NULL, 0, 16, 8,
 				   speed_template_16_24_32, num_mb);
 		break;
crypto/tcrypt.h +1 -1
index 9f654677172afba7..96c843a24607105e 100644
@@ -62,7 +62,7 @@ static u8 speed_template_32[] = {32, 0};
  * AEAD speed tests
  */
 static u8 aead_speed_template_19[] = {19, 0};
-static u8 aead_speed_template_20[] = {20, 0};
+static u8 aead_speed_template_20_28_36[] = {20, 28, 36, 0};
 static u8 aead_speed_template_36[] = {36, 0};
 
 /*
Signature · 1 line
2.35.1
#4 lore raw

PATCH v2 4/4 crypto: aead - fix inaccurate documentation

In reply to Ard Biesheuvel

The AEAD documentation conflates associated data and authentication
tags: the former (along with the ciphertext) is authenticated by the latter. Fix the doc accordingly.

---
 include/crypto/aead.h | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)
include/crypto/aead.h +10 -10
index 14db3bee0519ee85..4a2b7e6e0c1fa7cd 100644
@@ -27,15 +27,12 @@
  *
  * For example: authenc(hmac(sha256), cbc(aes))
  *
- * The example code provided for the symmetric key cipher operation
- * applies here as well. Naturally all *skcipher* symbols must be exchanged
- * the *aead* pendants discussed in the following. In addition, for the AEAD
- * operation, the aead_request_set_ad function must be used to set the
- * pointer to the associated data memory location before performing the
- * encryption or decryption operation. In case of an encryption, the associated
- * data memory is filled during the encryption operation. For decryption, the
- * associated data memory must contain data that is used to verify the integrity
- * of the decrypted data. Another deviation from the asynchronous block cipher
+ * The example code provided for the symmetric key cipher operation applies
+ * here as well. Naturally all *skcipher* symbols must be exchanged the *aead*
+ * pendants discussed in the following. In addition, for the AEAD operation,
+ * the aead_request_set_ad function must be used to set the pointer to the
+ * associated data memory location before performing the encryption or
+ * decryption operation. Another deviation from the asynchronous block cipher
  * operation is that the caller should explicitly check for -EBADMSG of the
  * crypto_aead_decrypt. That error indicates an authentication error, i.e.
  * a breach in the integrity of the message. In essence, that -EBADMSG error
@@ -49,7 +46,10 @@
  *
  * The destination scatterlist has the same layout, except that the plaintext
  * (resp. ciphertext) will grow (resp. shrink) by the authentication tag size
- * during encryption (resp. decryption).
+ * during encryption (resp. decryption). The authentication tag is generated
+ * during the encryption operation and appended to the ciphertext. During
+ * decryption, the authentication tag is consumed along with the ciphertext and
+ * used to verify the integrity of the plaintext and the associated data.
  *
  * In-place encryption/decryption is enabled by using the same scatterlist
  * pointer for both the source and destination.
Signature · 1 line
2.35.1
#5 lore raw
In reply to Ard Biesheuvel
Quoted 12 lines · Ard Biesheuvel

This is a v2 as patch #1 was sent out in isolation a couple of days ago.

As it turns out, we can get ~10% speedup for RFC4106 on arm64 (Cortex-A53) by giving it the same treatment as ARM, i.e., avoid the generic template and implement RFC4106 encapsulation directly in the driver

Patch #3 adds larger key sizes to the tcrypt benchmark for RFC4106

Patch #4 fixes some prose on AEAD that turned out to be inaccurate.

Quoted 9 lines

Changes since v1:
- minor tweaks to the asm code in patch #1, one of which to fix a Clang build error

Note: patch #1 depends on the softirq context patches for kernel mode NEON I sent out last week. More specifically, this implements a sync AEAD that does not implement a !simd fallback, as AEADs are not callable in hard IRQ context anyway.

These prerequisite changes have now been queued up in the ARM tree.

Note that these are runtime prerequisites only so I think this series can be safely merged as well, as I don't think anyone builds cryptodev for 32-bit ARM and tests it on 64-bit hardware (which is the only hardware that implements the AES instructions that patch #1 relies on)

Quoted 21 lines
Cc Eric Biggers <[email protected]>
Cc Herbert Xu <[email protected]>

Ard Biesheuvel (4):
crypto: arm/ghash - implement fused AES/GHASH version of AES-GCM
crypto: arm64/gcm - add RFC4106 support
crypto: tcrypt - include larger key sizes in RFC4106 benchmark
crypto: aead - fix inaccurate documentation

 arch/arm/crypto/Kconfig           |   2 +
 arch/arm/crypto/ghash-ce-core.S   | 382 +++++++++++++++++-
 arch/arm/crypto/ghash-ce-glue.c   | 424 +++++++++++++++++++-
 arch/arm64/crypto/ghash-ce-glue.c | 145 +++++--
 crypto/tcrypt.c                   |   8 +-
 crypto/tcrypt.h                   |   2 +-
 include/crypto/aead.h             |  20 +-
 7 files changed, 913 insertions(+), 70 deletions(-)

--
2.35.1

maintainer Acked-by
#6 lore raw
Quoted 7 lines · Ard Biesheuvel

These prerequisite changes have now been queued up in the ARM tree.

Note that these are runtime prerequisites only so I think this series can be safely merged as well, as I don't think anyone builds cryptodev for 32-bit ARM and tests it on 64-bit hardware (which is the only hardware that implements the AES instructions that patch #1 relies on)

I don't have any objections for merging this through the arm tree.

Thanks,

Signature · 3 lines
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
#7 lore raw
Quoted 5 lines · Herbert Xu
Quoted 3 lines · Ard Biesheuvel

These prerequisite changes have now been queued up in the ARM tree.

Quoted 9 lines
Quoted 4 lines

Note that these are runtime prerequisites only so I think this series can be safely merged as well, as I don't think anyone builds cryptodev for 32-bit ARM and tests it on 64-bit hardware (which is the only hardware that implements the AES instructions that patch #1 relies on)

I don't have any objections for merging this through the arm tree.

Thanks.

Will you be taking the rest of the series? (patches #2 - #4). Or we might defer this to v6.4 entirely it if makes things easier. (The other changes really shouldn't go through the ARM tree)

maintainer
#8 lore raw
Quoted 4 lines · Ard Biesheuvel

Will you be taking the rest of the series? (patches #2 - #4). Or we might defer this to v6.4 entirely it if makes things easier. (The other changes really shouldn't go through the ARM tree)

I had assumed they were dependent. But they do seem to make sense on their own so yes I can certainly take patches 2-4.

Cheers,

Signature · 3 lines
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
#9 lore raw
Quoted 10 lines · Herbert Xu
Quoted 4 lines · Ard Biesheuvel

Will you be taking the rest of the series? (patches #2 - #4). Or we might defer this to v6.4 entirely it if makes things easier. (The other changes really shouldn't go through the ARM tree)

I had assumed they were dependent. But they do seem to make sense on their own so yes I can certainly take patches 2-4.

Excellent, thanks.

Patch #1 has been picked up by Russell, so please pick up the rest.

Signature · 1 line
Ard.
maintainer
#10 lore raw
In reply to Ard Biesheuvel
Quoted 29 lines · Ard Biesheuvel

This is a v2 as patch #1 was sent out in isolation a couple of days ago.

As it turns out, we can get ~10% speedup for RFC4106 on arm64 (Cortex-A53) by giving it the same treatment as ARM, i.e., avoid the generic template and implement RFC4106 encapsulation directly in the driver

Patch #3 adds larger key sizes to the tcrypt benchmark for RFC4106

Patch #4 fixes some prose on AEAD that turned out to be inaccurate.

Changes since v1:
- minor tweaks to the asm code in patch #1, one of which to fix a Clang build error

Note: patch #1 depends on the softirq context patches for kernel mode NEON I sent out last week. More specifically, this implements a sync AEAD that does not implement a !simd fallback, as AEADs are not callable in hard IRQ context anyway.

Cc Eric Biggers <[email protected]>
Cc Herbert Xu <[email protected]>

Ard Biesheuvel (4):
crypto: arm/ghash - implement fused AES/GHASH version of AES-GCM
crypto: arm64/gcm - add RFC4106 support
crypto: tcrypt - include larger key sizes in RFC4106 benchmark
crypto: aead - fix inaccurate documentation

Quoted 11 lines
 arch/arm/crypto/Kconfig           |   2 +
 arch/arm/crypto/ghash-ce-core.S   | 382 +++++++++++++++++-
 arch/arm/crypto/ghash-ce-glue.c   | 424 +++++++++++++++++++-
 arch/arm64/crypto/ghash-ce-glue.c | 145 +++++--
 crypto/tcrypt.c                   |   8 +-
 crypto/tcrypt.h                   |   2 +-
 include/crypto/aead.h             |  20 +-
 7 files changed, 913 insertions(+), 70 deletions(-)
Signature · 1 line
2.35.1

Patches 2-4 applied. Thanks.

Signature · 3 lines
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt