On Mon, 24 May 2021 at 23:53, Eric Biggers [off-list ref] wrote:

On Fri, May 21, 2021 at 12:20:53PM +0200, Ard Biesheuvel wrote:

quoted

With the SIMD code path removed, we can clean up the CCM auth-only path
a bit further, by passing the 'macp' input buffer pointer by value,
rather than by reference, and taking the output value from the
function's return value.

This way, the compiler is no longer forced to allocate macp on the
stack. This is not expected to make any difference in practice, it just
makes for slightly cleaner code.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 arch/arm64/crypto/aes-ce-ccm-core.S | 23 ++++++++++----------
 arch/arm64/crypto/aes-ce-ccm-glue.c | 17 +++++----------
 2 files changed, 17 insertions(+), 23 deletions(-)

diff --git a/arch/arm64/crypto/aes-ce-ccm-core.S b/arch/arm64/crypto/aes-ce-ccm-core.S
index 8adff299fcd3..b03f7f71f893 100644
--- a/arch/arm64/crypto/aes-ce-ccm-core.S
+++ b/arch/arm64/crypto/aes-ce-ccm-core.S

@@ -12,22 +12,21 @@
      .arch   armv8-a+crypto

      /*
-      * void ce_aes_ccm_auth_data(u8 mac[], u8 const in[], u32 abytes,
-      *                           u32 *macp, u8 const rk[], u32 rounds);
+      * u32 ce_aes_ccm_auth_data(u8 mac[], u8 const in[], u32 abytes,
+      *                          u32 macp, u8 const rk[], u32 rounds);

How is this different from 'u8 mac[]' which is already one of the parameters?

mac[] is the combined digest/input buffer, and macp is the index into
it that keeps track on how much new input we have accumulated. I.e.,
instead of having a separate buffer of the same size, and accumulating
bytes until we can perform the XOR + AES transformation, the partial
input is accumulated into mac[] using XOR directly.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel