On Nov 29, 2021, at 19:48, Eric Biggers [off-list ref] wrote:

On Wed, Nov 24, 2021 at 12:06:56PM -0800, Chang S. Bae wrote:

quoted

diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile
index ef6c0b9f69c6..f696b037faa5 100644
--- a/arch/x86/crypto/Makefile
+++ b/arch/x86/crypto/Makefile

@@ -50,6 +50,9 @@ obj-$(CONFIG_CRYPTO_AES_NI_INTEL) += aesni-intel.o

aesni-intel-y := aesni-intel_asm.o aesni-intel_glue.o aes-intel_glue.o
aesni-intel-$(CONFIG_64BIT) += aesni-intel_avx-x86_64.o aes_ctrby8_avx-x86_64.o

+obj-$(CONFIG_CRYPTO_AES_KL) += aeskl-intel.o
+aeskl-intel-y := aeskl-intel_asm.o aesni-intel_asm.o aeskl-intel_glue.o aes-intel_glue.o

This makes the object files aesni-intel_asm.o and aes-intel_glue.o each be built
into two separate kernel modules.  My understanding is that duplicating code
like that is generally frowned upon.  These files should either be built into a
separate module, which both aesni-intel.ko and aeskl-intel.ko would depend on,
or aeskl-intel.ko should depend on aesni-intel.ko.

The only reason to include the AES-NI object here is that AES-KL does not
support the 192-bit key.

Maybe the fallback can be the aes-generic driver [1] instead of AES-NI here.

quoted

diff --git a/arch/x86/crypto/aeskl-intel_asm.S b/arch/x86/crypto/aeskl-intel_asm.S
new file mode 100644
index 000000000000..d56ec8dd6644
--- /dev/null
+++ b/arch/x86/crypto/aeskl-intel_asm.S

This file gets very long after all the modes are added (> 1100 lines).  Is there
really no feasible way to share code between this and aesni-intel_asm.S, similar
to how the arm64 AES implementations work?  Surely most of the logic is the
same, and it's just the actual AES instructions that differ?

No, these two instruction sets are separate. So I think no room to share the
ASM code.

quoted

+config CRYPTO_AES_KL
+	tristate "AES cipher algorithms (AES-KL)"
+	depends on (LD_VERSION >= 23600) || (LLD_VERSION >= 120000)
+	depends on DM_CRYPT

'depends on DM_CRYPT' doesn't really make sense here, since there is no actual
dependency on dm-crypt in the code.

I think the intention here is to build a policy that the library is available
only when there is a clear use case.

But maybe putting such restriction is too much here.

Thanks
Chang

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/crypto/aes_generic.c