-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gcm pager #1959
Gcm pager #1959
Conversation
core/arch/arm/plat-vexpress/conf.mk
Outdated
@@ -69,6 +69,7 @@ $(call force,CFG_DT,y) | |||
CFG_SE_API ?= y | |||
CFG_SE_API_SELF_TEST ?= y | |||
CFG_PCSC_PASSTHRU_READER_DRV ?= y | |||
CFG_AES_GCM_TABLE_BASED ?= y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why only for QEMU? Shouldn't that be always enabled in core/crypto.mk
as long as CFG_CRYPTO_WITH_CE
is not y
?
Also it would be good to have performance numbers in the commit log. FWIW, here is the improvement I see on HiKey960 (with CFG_CRYPTO_WITH_CE=n
of course, not a very realistic scenario since CE is much faster but for the sake of comparison it works):
root@HiKey960:/ xtest --aes-perf -m GCM
(CFG_AES_GCM_TABLE_BASED=n)
min=69.27us max=86.458us mean=70.5695us stddev=0.955826us (cv 1.35445%) (13.8383MiB/s)
(CFG_AES_GCM_TABLE_BASED=y)
min=41.666us max=53.646us mean=42.138us stddev=0.621345us (cv 1.47455%) (23.1753MiB/s)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I'll update accordingly (using your numbers)
@@ -1,4 +1,8 @@ | |||
srcs-y += crypto.c | |||
srcs-y += aes-gcm.c | |||
srcs-y += aes-gcm-sw.c | |||
ifeq ($(CFG_AES_GCM_TABLE_BASED),y) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CFG_AES_GCM_TABLE_BASED
is not compatible with CFG_CRYPTO_WITH_CE
. I think this should be checked somewhere. In core/crypto.mk
maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right
Update |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice update. In addition to consolidating the GCM code, this makes the pager significantly faster. For the record: on HiKey960, 64 bits, A73 cores only: "time xtest _60" takes about 7-8 seconds on master and only 1.5s with this PR.
Please see further comments below, a few minor things and one slightly bigger concern about "core: crypto: AES-GCM: add internal key expansion".
-
For "core: AES-GCM: import table based GF-mult", "core: crypto: AES-GCM: separate encryption key", "core: crypto: AES-GCM: internal_aes_gcm_{enc,dec}()"
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
-
For "core: LTC provide some AES primitives", "core: pager: use new aes-gcm implementation":
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
-
For "core: crypto: AES-GCM: rem tomcrypt.h dependency":
s/rem/remove/, with that:
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
core/crypto.mk
Outdated
@@ -41,6 +41,7 @@ CFG_CRYPTO_AES_GCM_FROM_CRYPTOLIB ?= n | |||
|
|||
endif | |||
|
|||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Useless empty line
* Copyright (C) 2006-2015, ARM Limited, All Rights Reserved | ||
* SPDX-License-Identifier: Apache-2.0 | ||
* | ||
* Licensed under the Apache License, Version 2.0 (the "License"); you may |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Certainly redundant with the SPDX line but I suppose it was like this in the original implementation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, would you like me to trim it off?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes please
void __weak internal_aes_gcm_encrypt_block(struct internal_aes_gcm_ctx *ctx, | ||
const void *src, void *dst) | ||
void __weak | ||
internal_aes_gcm_encrypt_block(const struct internal_aes_gcm_key *ek, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: I'd rather have the line break after the opening parenthesis, because it is quite useful to be able to grep for the function name and see the __weak
vs. non-__weak
instances. The parameter list, OTOH, doesn't matter much (and it has to be split anyway).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If internal_aes_gcm_encrypt_block is folded up then "const struct internal_aes_gcm_key *ek" doesn't fit on that line and can't be aligned with the "(". Doing like this keeps checkpatch happy, even with -strict.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
core/crypto/aes-gcm-sw.c
Outdated
uint64_t *enc_key, | ||
unsigned int *rounds) | ||
TEE_Result __weak | ||
internal_aes_gcm_expand_enc_key(const void *key, size_t key_len, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here also, splitting after key,
would be better IMO.
aese v0.16b, v1.16b | ||
umov w0, v0.4s[0] | ||
ret | ||
ENDPROC(pmull_gcm_load_round_keys) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/pmull_gcm_load_round_keys/pmull_gcm_aes_sub/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
return (word >> shift) | (word << (32 - shift)); | ||
} | ||
|
||
TEE_Result internal_aes_gcm_expand_enc_key(const void *key, size_t key_len, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why ARM64 only?
I understand you're copying code from core/lib/libtomcrypt/src/ciphers/
(aes_armv8a_ce.c
and aes_modes_armv8a_ce_a64.S
) into core/arch/arm/crypto/
(aes-gcm-ce.c
and ghash-ce-core_a64.S
) to cut that dependency on LTC so that pager can use accelerated code. Two things:
- You should clearly say where the code comes from in the commit log
- Why not update similarly
ghash-ce-core_a32.S
using code fromaes_modes_armv8a_ce_a32.S
(functionce_aes_sub()
) ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Yes, I'll update the commit message
- We don't have any AES routines for ARM32 yet so there's nothing to be done in this area for ARM32 yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
core/lib/libtomcrypt/src/ciphers/aes_modes_armv8a_ce_a32.S
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I wasn't clear. In ARM64 we have an implementation with AES and GHASH fused, which gives a good speedup. In ARM32 we don't have such an implementation (yet, ever?) so instead we're using the AES API in the cryptolib.
What we could do, is to extract the CE AES implementation from LTC and supply it to LTC similarly to how GHASH is supplied. The advantage is that we can get rid of some redundancy and have easier access to the routines. This however is not in that scope of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I've got it now.
7bb8053
to
35c4cf8
Compare
Comments address, squashed and tags applied. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps arm64:
would be welcome in the commit subject, but anyway:
For "core: crypto: AES-GCM: add internal key expansion":
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
return (word >> shift) | (word << (32 - shift)); | ||
} | ||
|
||
TEE_Result internal_aes_gcm_expand_enc_key(const void *key, size_t key_len, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I've got it now.
Imports table based GF multiplication from mbed TLS. Sets CFG_AES_GCM_TABLE_BASED to default y unless CFG_CRYPTO_WITH_CE is y, then CFG_AES_GCM_TABLE_BASED forced n. With tables performance is on HiKey960 (CFG_CRYPTO_WITH_CE=n): xtest --aes-perf -m GCM (CFG_AES_GCM_TABLE_BASED=n) min=69.27us max=86.458us mean=70.5695us stddev=0.955826us (cv 1.35445%) (13.8383MiB/s) (CFG_AES_GCM_TABLE_BASED=y) min=41.666us max=53.646us mean=42.138us stddev=0.621345us (cv 1.47455%) (23.1753MiB/s) Acked-by: Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Provides crypto_aes_expand_enc_key() and crypto_aes_enc_block(). These functions are needed to avoid exposing the type symmetric_key outside of LTC. Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Removes tomcrypt.h dependency by replacing the "symmetric_key skey" field in struct internal_aes_gcm_ctx with a raw key. Replaces calls to the LTC functions aes_setup() and aes_ecb_encrypt() with calls to crypto_aes_expand_enc_key() and crypto_aes_enc_block() respectively. Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Adds internal encryption key expansion when internal AES-GCM uses AES crypto extensions. This avoids a dependency on the crypto library to use the same endian on the expanded encryption key. Copies code from core/lib/libtomcrypt/src/ciphers/ aes_armv8a_ce.c and aes_modes_armv8a_ce_a64.S and makes some small changes to make it fit in the new place. Acked-by: Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Separates the AES (CTR) encryption key from the rest of the context to allow more efficient key handling. Acked-by: Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Adds internal_aes_gcm_enc() and internal_aes_gcm_dec() for encrypting/decrypting a complete message with an external expanded key. Acked-by: Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Pager switches to use the new internal accelerated AES-GCM implementation instead of the old software only implementation. Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> Tested-by: Jens Wiklander <jens.wiklander@linaro.org> (QEMU, Hikey) Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
35c4cf8
to
2164d0a
Compare
Rebased, tags applied |
No description provided.