On Mon, Nov 29, 2021 at 10:57 PM Bae, Chang Seok
[off-list ref] wrote:

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

quoted

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

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

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.

Yeah, my bad the "depends on DM_CRYPT" can go. Even though the Key
Locker support has no real pressing reason to be built without it,
there is still no actual code dependency.