On Mon, 24 May 2021 at 23:53, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > On Fri, May 21, 2021 at 12:20:53PM +0200, Ard Biesheuvel wrote: > > 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@xxxxxxxxxx> > > --- > > 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.