[0/3] crypto: x86/aesni - Improve XTS data type

The field within the struct aesni_xts_ctx is currently defined as a
byte array, sized to match the struct crypto_aes_ctx. However, it
actually represents the struct data type.

To accurately redefine the data type, some adjustments have to be made
to the address alignment code. It involved refactoring the common
alignment code initially, followed by updating the structure's
definition. Finally, the XTS alignment is now performed early in the
process, rather than at every access point.

This change was suggested during Eric's review of another series
intended to enable an alternative AES implementation [1][2]. I viewed
it as an enhancement to the mainline, independent of the series.

I have divided these changes into incremental pieces, making them
considerably more reviewable and maintainable.

The series is based on the cryptodev's master branch:

    git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master

Thanks,
Chang

[1] https://lore.kernel.org/all/ZFWQ4sZEVu%2FLHq+Q@gmail.com/
[2] https://lore.kernel.org/all/20230526065414.GB875@sol.localdomain/

Chang S. Bae (3):
  crypto: x86/aesni - Refactor the common address alignment code
  crypto: x86/aesni - Correct the data type in struct aesni_xts_ctx
  crypto: x86/aesni - Perform address alignment early for XTS mode

 arch/x86/crypto/aesni-intel_glue.c | 52 ++++++++++++++----------------
 1 file changed, 25 insertions(+), 27 deletions(-)


base-commit: 1c43c0f1f84aa59dfc98ce66f0a67b2922aa7f9d

On Mon, Sep 25, 2023 at 08:17:50AM -0700, Chang S. Bae wrote:
> The address alignment code has been duplicated for each mode. Instead
> of duplicating the same code, refactor the alignment code and simplify
> the alignment helpers.
> 
> Suggested-by: Eric Biggers <ebiggers@kernel.org>
> Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
> Cc: linux-crypto@vger.kernel.org
> Cc: x86@kernel.org
> Cc: linux-kernel@vger.kernel.org
> Link: https://lore.kernel.org/all/20230526065414.GB875@sol.localdomain/
> ---
>  arch/x86/crypto/aesni-intel_glue.c | 26 ++++++++++----------------
>  1 file changed, 10 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c
> index 39d6a62ac627..241d38ae1ed9 100644
> --- a/arch/x86/crypto/aesni-intel_glue.c
> +++ b/arch/x86/crypto/aesni-intel_glue.c
> @@ -80,6 +80,13 @@ struct gcm_context_data {
>  	u8 hash_keys[GCM_BLOCK_LEN * 16];
>  };
>  
> +static inline void *aes_align_addr(void *addr)
> +{
> +	if (crypto_tfm_ctx_alignment() >= AESNI_ALIGN)
> +		return addr;
> +	return PTR_ALIGN(addr, AESNI_ALIGN);
> +}
> +
>  asmlinkage int aesni_set_key(struct crypto_aes_ctx *ctx, const u8 *in_key,
>  			     unsigned int key_len);
>  asmlinkage void aesni_enc(const void *ctx, u8 *out, const u8 *in);
> @@ -201,32 +208,19 @@ static __ro_after_init DEFINE_STATIC_KEY_FALSE(gcm_use_avx2);
>  static inline struct
>  aesni_rfc4106_gcm_ctx *aesni_rfc4106_gcm_ctx_get(struct crypto_aead *tfm)
>  {
> -	unsigned long align = AESNI_ALIGN;
> -
> -	if (align <= crypto_tfm_ctx_alignment())
> -		align = 1;
> -	return PTR_ALIGN(crypto_aead_ctx(tfm), align);
> +	return (struct aesni_rfc4106_gcm_ctx *)aes_align_addr(crypto_aead_ctx(tfm));
>  }
>  
>  static inline struct
>  generic_gcmaes_ctx *generic_gcmaes_ctx_get(struct crypto_aead *tfm)
>  {
> -	unsigned long align = AESNI_ALIGN;
> -
> -	if (align <= crypto_tfm_ctx_alignment())
> -		align = 1;
> -	return PTR_ALIGN(crypto_aead_ctx(tfm), align);
> +	return (struct generic_gcmaes_ctx *)aes_align_addr(crypto_aead_ctx(tfm));
>  }
>  #endif
>  
>  static inline struct crypto_aes_ctx *aes_ctx(void *raw_ctx)
>  {
> -	unsigned long addr = (unsigned long)raw_ctx;
> -	unsigned long align = AESNI_ALIGN;
> -
> -	if (align <= crypto_tfm_ctx_alignment())
> -		align = 1;
> -	return (struct crypto_aes_ctx *)ALIGN(addr, align);
> +	return (struct crypto_aes_ctx *)aes_align_addr(raw_ctx);
>  }

The casts can be dropped, since aes_align_addr() returns 'void *'.

- Eric