On Tue, 30 Nov 2021 at 07:57, 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

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.

On arm64, we have

aes-ce.S, which uses AES instructions to implement the AES core transforms

aes-neon.S, which uses plain NEON instructions to implement the AES
core transforms

aes-modes.S, which can be combined with either of the above, and
implements the various chaining modes (ECB, CBC, CTR, XTS, and a
helper for CMAC, CBCMAC and XMAC)

If you have two different primitives for performing AES transforms
(the original round by round one, and the KL one that does 10 or 14
rounds at a time), you should still be able to reuse most of the code
that implements the non-trivial handling of the chaining modes.

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.

Thanks
Chang

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