On Mon, Apr 10, 2023 at 03:59:35PM -0700, Chang S. Bae wrote:
> [PATCH v6 11/12] crypto: x86/aes-kl - Support AES algorithm using Key Locker instructions
Thanks for dropping the unnecessary modes of operation (CBC, ECB, CTR). It
simplified the patchset quite a bit!
Now that only AES-XTS is included, can you please also merge this patch with the
following patch? As-is, this patch is misleading since it doesn't actually add
"support" for anything at all. It actually just adds an unfinished AES-XTS
implementation, which patch 12 then finishes. I assume that the current
patchset organization is left over from when you were trying to support multiple
modes of operation. IMO, it would be much easier to review if patches 11-12
were merged into one patch that adds the new AES-XTS implementation.
> For disk encryption, storage bandwidth may be the bottleneck
> before encryption bandwidth, but the potential performance difference is
> why AES-KL is advertised as a distinct cipher in /proc/crypto rather than
> the kernel transparently replacing AES-NI usage with AES-KL.
This does not correctly describe what is going on. Actually, this patchset
registers the AES-KL XTS algorithm with the usual name "xts(aes)". So, it can
potentially be used by any AES-XTS user. It seems that you're actually relying
on the algorithm priorities to prioritize AES-NI, as you've assigned priority
200 to AES-KL, whereas AES-NI has priority 401. Is that what you intend, and if
so can you please update your explanation to properly explain this?
The alternative would be to use a unique algorithm name, such as
"keylocker-xts(aes)". I'm not sure that would be better, given that the
algorithms are compatible. However, that actually would seem to match the
explanation you gave more closely, so perhaps that's what you actually intended?
> diff --git a/arch/x86/crypto/aeskl-intel_asm.S b/arch/x86/crypto/aeskl-intel_asm.S
[...]
> +#ifdef __x86_64__
> +#define AREG %rax
> +#define HANDLEP %rdi
> +#define OUTP %rsi
> +#define KLEN %r9d
> +#define INP %rdx
> +#define T1 %r10
> +#define LEN %rcx
> +#define IVP %r8
> +#else
> +#define AREG %eax
> +#define HANDLEP %edi
> +#define OUTP AREG
> +#define KLEN %ebx
> +#define INP %edx
> +#define T1 %ecx
> +#define LEN %esi
> +#define IVP %ebp
> +#endif
I strongly recommend skipping the 32-bit support, as it's unlikely to be worth
the effort.
And actually, aeskl-intel_glue.c only registers the algorithm for 64-bit
anyway... So the 32-bit code paths are untested dead code.
> +static inline int aeskl_enc(const void *ctx, u8 *out, const u8 *in)
> +{
> + if (unlikely(keylength(ctx) == AES_KEYSIZE_192))
> + return -EINVAL;
> + else if (!valid_keylocker())
> + return -ENODEV;
> + else if (_aeskl_enc(ctx, out, in))
> + return -EINVAL;
> + else
> + return 0;
> +}
> +
> +static inline int aeskl_dec(const void *ctx, u8 *out, const u8 *in)
> +{
> + if (unlikely(keylength(ctx) == AES_KEYSIZE_192))
> + return -EINVAL;
> + else if (!valid_keylocker())
> + return -ENODEV;
> + else if (_aeskl_dec(ctx, out, in))
> + return -EINVAL;
> + else
> + return 0;
> +}
I don't think the above two functions should exist. keylength() and
valid_keylocker() should be checked before calling xts_crypt_common(), and the
assembly functions should just return the correct error code (-EINVAL,
apparently) instead of an unspecified nonzero value. That would leave nothing
for a wrapper function to do.
Note: if you take this suggestion, the assembly functions would need to use
SYM_TYPED_FUNC_START instead of SYM_FUNC_START.
- Eric
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
