Received-SPF: pass (google.com: domain of linux-crypto+bounces-1656-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Fri, 26 Jan 2024 17:05:15 +0800
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Ard Biesheuvel <ardb+git@google.com>
Cc: linux-crypto@vger.kernel.org, ebiggers@kernel.org,
	Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH v2 0/8] crypto: Clean up arm64 AES-CCM code
Message-ID: <ZbN1y/oViQpoxyR4@gondor.apana.org.au>
References: <20240118170628.3049797-10-ardb+git@google.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240118170628.3049797-10-ardb+git@google.com>

On Thu, Jan 18, 2024 at 06:06:29PM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
> 
> The AES-CCM driver was written 10+ years ago, based on the very first
> kernel mode NEON API for arm64, which eagerly preserved/restored the
> NEON registers on each call to kernel_neon_begin() resp.
> kernel_neon_end().
> 
> For this reason, the asm helpers were constructed in a way that used
> only 6 NEON registers, as the kernel mode NEON API at the time
> implemented an optimization where kernel_neon_begin() took an int
> denoting the number of NEON registers to preserve/restore. Given that no
> actual hardware existed at the time (except perhaps for APM Xgene1 which
> did not implement the crypto instructions), all of this was based on
> premature assumptions.
> 
> These days, the NEON API is a bit more sophisticated, and does not
> bother to preserve/restore anything unless it is needed (e.g., when
> context switching or returning to user space). It also no longer
> disables preemption. Finally, we've developed some code patterns in the
> mean time to deal with tail blocks more cleanly and efficiently.
> 
> So let's bring the CCM driver up to date with all of this.
> 
> Changes since v1:
> - keep primary en/decryption paths separate
> - fix rebase error in v1
> 
> Ard Biesheuvel (8):
>   crypto: arm64/aes-ccm - Revert "Rewrite skcipher walker loop"
>   crypto: arm64/aes-ccm - Keep NEON enabled during skcipher walk
>   crypto: arm64/aes-ccm - Pass short inputs via stack buffer
>   crypto: arm64/aes-ccm - Replace bytewise tail handling with NEON
>     permute
>   crypto: arm64/aes-ccm - Reuse existing MAC update for AAD input
>   crypto: arm64/aes-ccm - Cache round keys and unroll AES loops
>   crypto: arm64/aes-ccm - Merge encrypt and decrypt tail handling
>   crypto: arm64/aes-ccm - Merge finalization into en/decrypt asm helpers
> 
>  arch/arm64/crypto/Kconfig           |   1 +
>  arch/arm64/crypto/aes-ce-ccm-core.S | 265 +++++++-------------
>  arch/arm64/crypto/aes-ce-ccm-glue.c | 154 ++++++++----
>  arch/arm64/crypto/aes-glue.c        |   1 +
>  4 files changed, 200 insertions(+), 221 deletions(-)
> 
> -- 
> 2.43.0.381.gb435a96ce8-goog

All applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt