crypto: Accelerated GCM for IPSec on ARM/arm64
Subsystems (3)
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.
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
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
@@ -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
PATCH v2 2/4 crypto: arm64/gcm - add RFC4106 support
In reply to Ard BiesheuvelAdd 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
@@ -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 4struct 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
PATCH v2 3/4 crypto: tcrypt - include larger key sizes in RFC4106 benchmark
In reply to Ard BiesheuvelRFC4106 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
@@ -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
@@ -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
PATCH v2 4/4 crypto: aead - fix inaccurate documentation
In reply to Ard BiesheuvelThe 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
@@ -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
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 errorNote: 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 documentationarch/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
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
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)
Acked-by Herbert Xu <[email protected]>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)
Herbert Xu
maintainerQuoted 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
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.
Herbert Xu
maintainerQuoted 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 errorNote: 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