From: Eric Biggers <ebiggers@kernel.org> To: "Chang S. Bae" <chang.seok.bae@intel.com> Cc: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, dm-devel@redhat.com, elliott@hpe.com, gmazyland@gmail.com, luto@kernel.org, dave.hansen@linux.intel.com, tglx@linutronix.de, bp@alien8.de, mingo@kernel.org, x86@kernel.org, herbert@gondor.apana.org.au, ardb@kernel.org, dan.j.williams@intel.com, bernie.keany@intel.com, charishma1.gairuboyina@intel.com, lalithambika.krishnakumar@intel.com, nhuck@google.com, "David S. Miller" <davem@davemloft.net>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com> Subject: Re: [PATCH v8 12/12] crypto: x86/aes-kl - Implement the AES-XTS algorithm Date: Tue, 6 Jun 2023 22:35:58 -0700 [thread overview] Message-ID: <20230607053558.GC941@sol.localdomain> (raw) In-Reply-To: <20230603152227.12335-13-chang.seok.bae@intel.com> On Sat, Jun 03, 2023 at 08:22:27AM -0700, Chang S. Bae wrote: > == Key Handle Restriction == > > A key handle may be encoded with some restrictions. It's unclear what this means. Please avoid passive tense and the word "may" like this. I think you mean something like "The AES-KL instruction set supports selecting key usage restrictions at key handle creation time." > Restrict every handle only available in kernel mode via setkey(). I think you mean something like "Restrict all key handles created by the kernel to kernel mode use only." Can you also mention why you are doing this? I suppose it might as well be done, but I'm not seeing how it would actually matter. What other sorts of key usage restrictions does AES-KL support? Are any other ones useful here? > Subsequently the key handle could be corrupted or fail with handle > restrictions. Then, encrypt()/decrypt() returns -EINVAL. Aren't these scenarios actually impossible? At least without memory corruption. > == Userspace Exposition == > > Some hardware implementations may have some performance penalties. Likewise, please avoid vague statements like this. This makes it unclear whether this is something that happens in the real world or whether it's just theoretical. You indeed have actual benchmark results that show that AES-KL is much slower than AES-NI on current CPUs, right? > But, for disk encryption, storage bandwidth may be the bottleneck before > encryption bandwidth. Again, please try to be less vague. E.g. "With a slow storage device, storage bandwidth is the bottleneck, even if disk encryption is enabled..." > Thus, advertise it with a unique name 'xts-aes-aeskl' in /proc/crypto while > not replacing AES-NI under the generic name 'xts(aes)' with a lower priority. The above sentence seems to say that xts-aes-aeskl does *not* have a lower priority than xts-aes-aesni. But actually it does. > Then, the performance is unlikely better than 64-bit which has already a gap > vs. AES-NI. I don't understand what this sentence is trying to say. > diff --git a/arch/x86/crypto/Kconfig b/arch/x86/crypto/Kconfig > index 9bbfd01cfa2f..658adfd7aebf 100644 > --- a/arch/x86/crypto/Kconfig > +++ b/arch/x86/crypto/Kconfig > @@ -2,6 +2,11 @@ > > menu "Accelerated Cryptographic Algorithms for CPU (x86)" > > +config AS_HAS_KEYLOCKER > + def_bool $(as-instr,encodekey256 %eax$(comma)%eax) > + help > + Supported by binutils >= 2.36 and LLVM integrated assembler >= V12 It looks like arch/x86/Kconfig.assembler would be a better place for this. > diff --git a/arch/x86/crypto/aeskl-intel_asm.S b/arch/x86/crypto/aeskl-intel_asm.S > new file mode 100644 > index 000000000000..61addc61dd4e > --- /dev/null > +++ b/arch/x86/crypto/aeskl-intel_asm.S > @@ -0,0 +1,552 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > +/* > + * Implement AES algorithm using AES Key Locker instructions. > + * > + * Most code is based from the AES-NI implementation, aesni-intel_asm.S > + * > + */ > + > +#include <linux/linkage.h> > +#include <linux/cfi_types.h> > +#include <asm/errno.h> > +#include <asm/inst.h> > +#include <asm/frame.h> > +#include "aes-helper_asm.S" > + > +.text > + > +#define STATE1 %xmm0 > +#define STATE2 %xmm1 > +#define STATE3 %xmm2 > +#define STATE4 %xmm3 > +#define STATE5 %xmm4 > +#define STATE6 %xmm5 > +#define STATE7 %xmm6 > +#define STATE8 %xmm7 > +#define STATE STATE1 > + > +#define IV %xmm9 > +#define KEY %xmm10 > +#define INC %xmm13 > + > +#define IN1 %xmm8 > +#define IN IN1 Why do both IN1 and IN exist? Shouldn't there just be IN? > + > +#define AREG %rax Shouldn't %rax just be hardcoded? > +#define HANDLEP %rdi This should be called CTX, to match the function prototypes. > +#define UKEYP OUTP This should be called IN_KEY, to match the function prototypes. > +#define GF128MUL_MASK %xmm11 > + > +/* > + * int __aeskl_setkey(struct crypto_aes_ctx *ctx, const u8 *in_key, unsigned int key_len) > + */ > +SYM_FUNC_START(__aeskl_setkey) > + FRAME_BEGIN > + movl %edx, 480(HANDLEP) > + movdqu (UKEYP), STATE1 > + mov $1, %eax > + cmp $16, %dl > + je .Lsetkey_128 > + > + movdqu 0x10(UKEYP), STATE2 > + encodekey256 %eax, %eax > + movdqu STATE4, 0x30(HANDLEP) > + jmp .Lsetkey_end > +.Lsetkey_128: > + encodekey128 %eax, %eax > + > +.Lsetkey_end: > + movdqu STATE1, (HANDLEP) > + movdqu STATE2, 0x10(HANDLEP) > + movdqu STATE3, 0x20(HANDLEP) The moves to the ctx should use movdqa, since it is aligned. > + > + xor AREG, AREG > + FRAME_END > + RET > +SYM_FUNC_END(__aeskl_setkey) This function always returns 0, so it really should return void. > +/* > + * int __aeskl_enc(const void *ctx, u8 *dst, const u8 *src) > + */ > +SYM_FUNC_START(__aeskl_enc) > + FRAME_BEGIN > + movdqu (INP), STATE > + movl 480(HANDLEP), KLEN > + > + cmp $16, KLEN > + je .Lenc_128 > + aesenc256kl (HANDLEP), STATE > + jz .Lenc_err > + jmp .Lenc_noerr > +.Lenc_128: > + aesenc128kl (HANDLEP), STATE > + jz .Lenc_err > + > +.Lenc_noerr: > + xor AREG, AREG > + jmp .Lenc_end > +.Lenc_err: > + mov $(-EINVAL), AREG > +.Lenc_end: > + movdqu STATE, (OUTP) > + FRAME_END > + RET > +SYM_FUNC_END(__aeskl_enc) In the common case (successful AES-256 encryption) this is executing 'jmp' twice. I think the code should be rearranged to eliminate these jmps. > +/* > + * int __aeskl_xts_encrypt(const struct crypto_aes_ctx *ctx, u8 *dst, > + * const u8 *src, unsigned int len, le128 *iv) > + */ > +SYM_FUNC_START(__aeskl_xts_encrypt) __aeskl_xts_encrypt() and __aeskl_xts_decrypt() are very similar. To reduce code duplication, can you consider generating them from a macro that takes an argument that indicates whether it is encrypt or decrypt? > +static int aeskl_setkey(struct crypto_tfm *tfm, void *raw_ctx, const u8 *in_key, > + unsigned int keylen) > +{ > + struct crypto_aes_ctx *ctx = (struct crypto_aes_ctx *)raw_ctx; > + int err; > + > + if (!crypto_simd_usable()) > + return -EBUSY; > + > + if (keylen != AES_KEYSIZE_128 && keylen != AES_KEYSIZE_192 && > + keylen != AES_KEYSIZE_256) > + return -EINVAL; > + > + kernel_fpu_begin(); > + if (unlikely(keylen == AES_KEYSIZE_192)) { > + pr_warn_once("AES-KL does not support 192-bit key. Use AES-NI.\n"); > + err = aesni_set_key(ctx, in_key, keylen); > + } else { > + if (!valid_keylocker()) > + err = -ENODEV; > + else > + err = __aeskl_setkey(ctx, in_key, keylen); > + } > + kernel_fpu_end(); > + > + return err; > +} [...] > + .cra_ctxsize = XTS_AES_CTX_SIZE, [...] Something that your AES-KL code does that's a bit ugly is that it abuses 'struct crypto_aes_ctx' to store a Keylocker key handle instead of the actual AES key schedule which the struct is supposed to be for. The proper way to represent that would be to make the tfm context for xts-aes-aeskl be a union of crypto_aes_ctx and a Keylocker specific context. If you don't do that and instead keep the proposed workaround, then please add a comment somewhere that very clearly explains how the struct is being used. Above aeskl_setkey() or above .cra_ctxsize might be a good place. > diff --git a/arch/x86/crypto/aesni-intel_glue.h b/arch/x86/crypto/aesni-intel_glue.h > new file mode 100644 > index 000000000000..5b1919f49efe > --- /dev/null > +++ b/arch/x86/crypto/aesni-intel_glue.h > @@ -0,0 +1,16 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > + > +/* > + * Support for Intel AES-NI instructions. This file contains function > + * prototypes to be referenced for other AES implementations > + */ It would be helpful if this comment was more concrete, like "These are AES-NI functions that are used by the AES-KL code as a fallback when it is given a 192-bit key. Key Locker does not support 192-bit keys." - Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org> To: "Chang S. Bae" <chang.seok.bae@intel.com> Cc: x86@kernel.org, herbert@gondor.apana.org.au, "David S. Miller" <davem@davemloft.net>, ardb@kernel.org, dave.hansen@linux.intel.com, dan.j.williams@intel.com, linux-kernel@vger.kernel.org, charishma1.gairuboyina@intel.com, mingo@kernel.org, lalithambika.krishnakumar@intel.com, dm-devel@redhat.com, Ingo Molnar <mingo@redhat.com>, bp@alien8.de, linux-crypto@vger.kernel.org, luto@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, bernie.keany@intel.com, tglx@linutronix.de, nhuck@google.com, gmazyland@gmail.com, elliott@hpe.com Subject: Re: [dm-devel] [PATCH v8 12/12] crypto: x86/aes-kl - Implement the AES-XTS algorithm Date: Tue, 6 Jun 2023 22:35:58 -0700 [thread overview] Message-ID: <20230607053558.GC941@sol.localdomain> (raw) In-Reply-To: <20230603152227.12335-13-chang.seok.bae@intel.com> On Sat, Jun 03, 2023 at 08:22:27AM -0700, Chang S. Bae wrote: > == Key Handle Restriction == > > A key handle may be encoded with some restrictions. It's unclear what this means. Please avoid passive tense and the word "may" like this. I think you mean something like "The AES-KL instruction set supports selecting key usage restrictions at key handle creation time." > Restrict every handle only available in kernel mode via setkey(). I think you mean something like "Restrict all key handles created by the kernel to kernel mode use only." Can you also mention why you are doing this? I suppose it might as well be done, but I'm not seeing how it would actually matter. What other sorts of key usage restrictions does AES-KL support? Are any other ones useful here? > Subsequently the key handle could be corrupted or fail with handle > restrictions. Then, encrypt()/decrypt() returns -EINVAL. Aren't these scenarios actually impossible? At least without memory corruption. > == Userspace Exposition == > > Some hardware implementations may have some performance penalties. Likewise, please avoid vague statements like this. This makes it unclear whether this is something that happens in the real world or whether it's just theoretical. You indeed have actual benchmark results that show that AES-KL is much slower than AES-NI on current CPUs, right? > But, for disk encryption, storage bandwidth may be the bottleneck before > encryption bandwidth. Again, please try to be less vague. E.g. "With a slow storage device, storage bandwidth is the bottleneck, even if disk encryption is enabled..." > Thus, advertise it with a unique name 'xts-aes-aeskl' in /proc/crypto while > not replacing AES-NI under the generic name 'xts(aes)' with a lower priority. The above sentence seems to say that xts-aes-aeskl does *not* have a lower priority than xts-aes-aesni. But actually it does. > Then, the performance is unlikely better than 64-bit which has already a gap > vs. AES-NI. I don't understand what this sentence is trying to say. > diff --git a/arch/x86/crypto/Kconfig b/arch/x86/crypto/Kconfig > index 9bbfd01cfa2f..658adfd7aebf 100644 > --- a/arch/x86/crypto/Kconfig > +++ b/arch/x86/crypto/Kconfig > @@ -2,6 +2,11 @@ > > menu "Accelerated Cryptographic Algorithms for CPU (x86)" > > +config AS_HAS_KEYLOCKER > + def_bool $(as-instr,encodekey256 %eax$(comma)%eax) > + help > + Supported by binutils >= 2.36 and LLVM integrated assembler >= V12 It looks like arch/x86/Kconfig.assembler would be a better place for this. > diff --git a/arch/x86/crypto/aeskl-intel_asm.S b/arch/x86/crypto/aeskl-intel_asm.S > new file mode 100644 > index 000000000000..61addc61dd4e > --- /dev/null > +++ b/arch/x86/crypto/aeskl-intel_asm.S > @@ -0,0 +1,552 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > +/* > + * Implement AES algorithm using AES Key Locker instructions. > + * > + * Most code is based from the AES-NI implementation, aesni-intel_asm.S > + * > + */ > + > +#include <linux/linkage.h> > +#include <linux/cfi_types.h> > +#include <asm/errno.h> > +#include <asm/inst.h> > +#include <asm/frame.h> > +#include "aes-helper_asm.S" > + > +.text > + > +#define STATE1 %xmm0 > +#define STATE2 %xmm1 > +#define STATE3 %xmm2 > +#define STATE4 %xmm3 > +#define STATE5 %xmm4 > +#define STATE6 %xmm5 > +#define STATE7 %xmm6 > +#define STATE8 %xmm7 > +#define STATE STATE1 > + > +#define IV %xmm9 > +#define KEY %xmm10 > +#define INC %xmm13 > + > +#define IN1 %xmm8 > +#define IN IN1 Why do both IN1 and IN exist? Shouldn't there just be IN? > + > +#define AREG %rax Shouldn't %rax just be hardcoded? > +#define HANDLEP %rdi This should be called CTX, to match the function prototypes. > +#define UKEYP OUTP This should be called IN_KEY, to match the function prototypes. > +#define GF128MUL_MASK %xmm11 > + > +/* > + * int __aeskl_setkey(struct crypto_aes_ctx *ctx, const u8 *in_key, unsigned int key_len) > + */ > +SYM_FUNC_START(__aeskl_setkey) > + FRAME_BEGIN > + movl %edx, 480(HANDLEP) > + movdqu (UKEYP), STATE1 > + mov $1, %eax > + cmp $16, %dl > + je .Lsetkey_128 > + > + movdqu 0x10(UKEYP), STATE2 > + encodekey256 %eax, %eax > + movdqu STATE4, 0x30(HANDLEP) > + jmp .Lsetkey_end > +.Lsetkey_128: > + encodekey128 %eax, %eax > + > +.Lsetkey_end: > + movdqu STATE1, (HANDLEP) > + movdqu STATE2, 0x10(HANDLEP) > + movdqu STATE3, 0x20(HANDLEP) The moves to the ctx should use movdqa, since it is aligned. > + > + xor AREG, AREG > + FRAME_END > + RET > +SYM_FUNC_END(__aeskl_setkey) This function always returns 0, so it really should return void. > +/* > + * int __aeskl_enc(const void *ctx, u8 *dst, const u8 *src) > + */ > +SYM_FUNC_START(__aeskl_enc) > + FRAME_BEGIN > + movdqu (INP), STATE > + movl 480(HANDLEP), KLEN > + > + cmp $16, KLEN > + je .Lenc_128 > + aesenc256kl (HANDLEP), STATE > + jz .Lenc_err > + jmp .Lenc_noerr > +.Lenc_128: > + aesenc128kl (HANDLEP), STATE > + jz .Lenc_err > + > +.Lenc_noerr: > + xor AREG, AREG > + jmp .Lenc_end > +.Lenc_err: > + mov $(-EINVAL), AREG > +.Lenc_end: > + movdqu STATE, (OUTP) > + FRAME_END > + RET > +SYM_FUNC_END(__aeskl_enc) In the common case (successful AES-256 encryption) this is executing 'jmp' twice. I think the code should be rearranged to eliminate these jmps. > +/* > + * int __aeskl_xts_encrypt(const struct crypto_aes_ctx *ctx, u8 *dst, > + * const u8 *src, unsigned int len, le128 *iv) > + */ > +SYM_FUNC_START(__aeskl_xts_encrypt) __aeskl_xts_encrypt() and __aeskl_xts_decrypt() are very similar. To reduce code duplication, can you consider generating them from a macro that takes an argument that indicates whether it is encrypt or decrypt? > +static int aeskl_setkey(struct crypto_tfm *tfm, void *raw_ctx, const u8 *in_key, > + unsigned int keylen) > +{ > + struct crypto_aes_ctx *ctx = (struct crypto_aes_ctx *)raw_ctx; > + int err; > + > + if (!crypto_simd_usable()) > + return -EBUSY; > + > + if (keylen != AES_KEYSIZE_128 && keylen != AES_KEYSIZE_192 && > + keylen != AES_KEYSIZE_256) > + return -EINVAL; > + > + kernel_fpu_begin(); > + if (unlikely(keylen == AES_KEYSIZE_192)) { > + pr_warn_once("AES-KL does not support 192-bit key. Use AES-NI.\n"); > + err = aesni_set_key(ctx, in_key, keylen); > + } else { > + if (!valid_keylocker()) > + err = -ENODEV; > + else > + err = __aeskl_setkey(ctx, in_key, keylen); > + } > + kernel_fpu_end(); > + > + return err; > +} [...] > + .cra_ctxsize = XTS_AES_CTX_SIZE, [...] Something that your AES-KL code does that's a bit ugly is that it abuses 'struct crypto_aes_ctx' to store a Keylocker key handle instead of the actual AES key schedule which the struct is supposed to be for. The proper way to represent that would be to make the tfm context for xts-aes-aeskl be a union of crypto_aes_ctx and a Keylocker specific context. If you don't do that and instead keep the proposed workaround, then please add a comment somewhere that very clearly explains how the struct is being used. Above aeskl_setkey() or above .cra_ctxsize might be a good place. > diff --git a/arch/x86/crypto/aesni-intel_glue.h b/arch/x86/crypto/aesni-intel_glue.h > new file mode 100644 > index 000000000000..5b1919f49efe > --- /dev/null > +++ b/arch/x86/crypto/aesni-intel_glue.h > @@ -0,0 +1,16 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > + > +/* > + * Support for Intel AES-NI instructions. This file contains function > + * prototypes to be referenced for other AES implementations > + */ It would be helpful if this comment was more concrete, like "These are AES-NI functions that are used by the AES-KL code as a fallback when it is given a 192-bit key. Key Locker does not support 192-bit keys." - Eric -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2023-06-07 5:36 UTC|newest] Thread overview: 247+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-12 21:12 [PATCH v5 00/12] x86: Support Key Locker Chang S. Bae 2022-01-12 21:12 ` [dm-devel] " Chang S. Bae 2022-01-12 21:12 ` [PATCH v5 01/12] Documentation/x86: Document " Chang S. Bae 2022-01-12 21:12 ` [dm-devel] " Chang S. Bae 2023-06-05 10:52 ` Bagas Sanjaya 2023-06-05 10:52 ` [dm-devel] " Bagas Sanjaya 2022-01-12 21:12 ` [PATCH v5 02/12] x86/cpufeature: Enumerate Key Locker feature Chang S. Bae 2022-01-12 21:12 ` [dm-devel] " Chang S. Bae 2022-01-12 21:12 ` [PATCH v5 03/12] x86/insn: Add Key Locker instructions to the opcode map Chang S. Bae 2022-01-12 21:12 ` [dm-devel] " Chang S. Bae 2022-01-12 21:12 ` [PATCH v5 04/12] x86/asm: Add a wrapper function for the LOADIWKEY instruction Chang S. Bae 2022-01-12 21:12 ` [dm-devel] " Chang S. Bae 2022-01-12 21:12 ` [PATCH v5 05/12] x86/msr-index: Add MSRs for Key Locker internal wrapping key Chang S. Bae 2022-01-12 21:12 ` [dm-devel] " Chang S. Bae 2022-01-12 21:12 ` [PATCH v5 06/12] x86/keylocker: Define Key Locker CPUID leaf Chang S. Bae 2022-01-12 21:12 ` [dm-devel] " Chang S. Bae 2022-01-12 21:12 ` [PATCH v5 07/12] x86/cpu/keylocker: Load an internal wrapping key at boot-time Chang S. Bae 2022-01-12 21:12 ` [dm-devel] " Chang S. Bae 2022-08-23 15:49 ` Evan Green 2022-08-23 15:49 ` [dm-devel] " Evan Green 2022-08-24 22:20 ` Chang S. Bae 2022-08-24 22:20 ` [dm-devel] " Chang S. Bae 2022-08-24 22:52 ` Evan Green 2022-08-24 22:52 ` [dm-devel] " Evan Green 2022-08-25 1:06 ` Chang S. Bae 2022-08-25 1:06 ` [dm-devel] " Chang S. Bae 2022-08-25 15:31 ` Evan Green 2022-08-25 15:31 ` [dm-devel] " Evan Green 2022-08-31 23:08 ` Chang S. Bae 2022-08-31 23:08 ` [dm-devel] " Chang S. Bae 2022-09-06 16:22 ` Evan Green 2022-09-06 16:22 ` [dm-devel] " Evan Green 2022-09-06 16:46 ` Chang S. Bae 2022-09-06 16:46 ` [dm-devel] " Chang S. Bae 2022-01-12 21:12 ` [PATCH v5 08/12] x86/PM/keylocker: Restore internal wrapping key on resume from ACPI S3/4 Chang S. Bae 2022-01-12 21:12 ` [dm-devel] " Chang S. Bae 2022-01-29 17:31 ` [PATCH v5-fix " Chang S. Bae 2022-01-29 17:31 ` [dm-devel] " Chang S. Bae 2022-01-12 21:12 ` [PATCH v5 09/12] x86/cpu: Add a configuration and command line option for Key Locker Chang S. Bae 2022-01-12 21:12 ` [dm-devel] " Chang S. Bae 2022-01-12 21:12 ` [PATCH v5 10/12] crypto: x86/aes - Prepare for a new AES implementation Chang S. Bae 2022-01-12 21:12 ` [dm-devel] " Chang S. Bae 2022-01-12 21:12 ` [PATCH v5 11/12] crypto: x86/aes-kl - Support AES algorithm using Key Locker instructions Chang S. Bae 2022-01-12 21:12 ` [dm-devel] " Chang S. Bae 2022-01-12 21:12 ` [PATCH v5 12/12] crypto: x86/aes-kl - Support XTS mode Chang S. Bae 2022-01-12 21:12 ` [dm-devel] " Chang S. Bae 2022-01-13 22:16 ` [PATCH v5 00/12] x86: Support Key Locker Dave Hansen 2022-01-13 22:16 ` [dm-devel] " Dave Hansen 2022-01-13 22:34 ` Bae, Chang Seok 2022-01-13 22:34 ` [dm-devel] " Bae, Chang Seok 2023-04-10 22:59 ` [PATCH v6 " Chang S. Bae 2023-04-10 22:59 ` [dm-devel] " Chang S. Bae 2023-04-10 22:59 ` [PATCH v6 01/12] Documentation/x86: Document " Chang S. Bae 2023-04-10 22:59 ` [dm-devel] " Chang S. Bae 2023-04-10 22:59 ` [PATCH v6 02/12] x86/cpufeature: Enumerate Key Locker feature Chang S. Bae 2023-04-10 22:59 ` [dm-devel] " Chang S. Bae 2023-04-10 22:59 ` [PATCH v6 03/12] x86/insn: Add Key Locker instructions to the opcode map Chang S. Bae 2023-04-10 22:59 ` [dm-devel] " Chang S. Bae 2023-04-10 22:59 ` [PATCH v6 04/12] x86/asm: Add a wrapper function for the LOADIWKEY instruction Chang S. Bae 2023-04-10 22:59 ` [dm-devel] " Chang S. Bae 2023-04-10 22:59 ` [PATCH v6 05/12] x86/msr-index: Add MSRs for Key Locker internal wrapping key Chang S. Bae 2023-04-10 22:59 ` [dm-devel] " Chang S. Bae 2023-04-10 22:59 ` [PATCH v6 06/12] x86/keylocker: Define Key Locker CPUID leaf Chang S. Bae 2023-04-10 22:59 ` [dm-devel] " Chang S. Bae 2023-04-10 22:59 ` [PATCH v6 07/12] x86/cpu/keylocker: Load an internal wrapping key at boot-time Chang S. Bae 2023-04-10 22:59 ` [dm-devel] " Chang S. Bae 2023-05-05 23:05 ` Eric Biggers 2023-05-05 23:05 ` [dm-devel] " Eric Biggers 2023-05-08 18:18 ` Chang S. Bae 2023-05-08 18:18 ` [dm-devel] " Chang S. Bae 2023-05-08 21:56 ` Dave Hansen 2023-05-08 21:56 ` [dm-devel] " Dave Hansen 2023-05-09 0:31 ` Chang S. Bae 2023-05-09 0:31 ` [dm-devel] " Chang S. Bae 2023-05-09 0:51 ` Dave Hansen 2023-05-09 0:51 ` [dm-devel] " Dave Hansen 2023-05-08 19:18 ` Elliott, Robert (Servers) 2023-05-08 19:18 ` [dm-devel] " Elliott, Robert (Servers) 2023-05-08 20:15 ` Chang S. Bae 2023-05-08 20:15 ` [dm-devel] " Chang S. Bae 2023-04-10 22:59 ` [PATCH v6 08/12] x86/PM/keylocker: Restore internal wrapping key on resume from ACPI S3/4 Chang S. Bae 2023-04-10 22:59 ` [dm-devel] " Chang S. Bae 2023-05-05 23:09 ` Eric Biggers 2023-05-05 23:09 ` [dm-devel] " Eric Biggers 2023-05-08 18:18 ` Chang S. Bae 2023-05-08 18:18 ` [dm-devel] " Chang S. Bae 2023-04-10 22:59 ` [PATCH v6 09/12] x86/cpu: Add a configuration and command line option for Key Locker Chang S. Bae 2023-04-10 22:59 ` [dm-devel] " Chang S. Bae 2023-04-10 22:59 ` [PATCH v6 10/12] crypto: x86/aes - Prepare for a new AES implementation Chang S. Bae 2023-04-10 22:59 ` [dm-devel] " Chang S. Bae 2023-05-05 23:27 ` Eric Biggers 2023-05-05 23:27 ` [dm-devel] " Eric Biggers 2023-05-09 0:55 ` Chang S. Bae 2023-05-09 0:55 ` [dm-devel] " Chang S. Bae 2023-05-11 19:05 ` Chang S. Bae 2023-05-11 19:05 ` [dm-devel] " Chang S. Bae 2023-05-11 21:39 ` Eric Biggers 2023-05-11 21:39 ` [dm-devel] " Eric Biggers 2023-05-11 23:19 ` Chang S. Bae 2023-05-11 23:19 ` [dm-devel] " Chang S. Bae 2023-04-10 22:59 ` [PATCH v6 11/12] crypto: x86/aes-kl - Support AES algorithm using Key Locker instructions Chang S. Bae 2023-04-10 22:59 ` [dm-devel] " Chang S. Bae 2023-05-06 0:01 ` Eric Biggers 2023-05-06 0:01 ` [dm-devel] " Eric Biggers 2023-05-08 18:18 ` Chang S. Bae 2023-05-08 18:18 ` [dm-devel] " Chang S. Bae 2023-05-24 17:18 ` Chang S. Bae 2023-05-24 17:18 ` [dm-devel] " Chang S. Bae 2023-05-12 17:52 ` Milan Broz 2023-05-12 17:52 ` [dm-devel] " Milan Broz 2023-05-08 19:21 ` Elliott, Robert (Servers) 2023-05-08 19:21 ` [dm-devel] " Elliott, Robert (Servers) 2023-05-08 19:24 ` Elliott, Robert (Servers) 2023-05-08 19:24 ` [dm-devel] " Elliott, Robert (Servers) 2023-05-08 20:00 ` Chang S. Bae 2023-05-08 20:00 ` [dm-devel] " Chang S. Bae 2023-04-10 22:59 ` [PATCH v6 12/12] crypto: x86/aes-kl - Support XTS mode Chang S. Bae 2023-04-10 22:59 ` [dm-devel] " Chang S. Bae 2023-05-24 16:57 ` [PATCH v7 00/12] x86: Support Key Locker Chang S. Bae 2023-05-24 16:57 ` [dm-devel] " Chang S. Bae 2023-05-24 16:57 ` [PATCH v7 01/12] Documentation/x86: Document " Chang S. Bae 2023-05-24 16:57 ` [dm-devel] " Chang S. Bae 2023-05-24 16:57 ` [PATCH v7 02/12] x86/cpufeature: Enumerate Key Locker feature Chang S. Bae 2023-05-24 16:57 ` [dm-devel] " Chang S. Bae 2023-05-24 16:57 ` [PATCH v7 03/12] x86/insn: Add Key Locker instructions to the opcode map Chang S. Bae 2023-05-24 16:57 ` [dm-devel] " Chang S. Bae 2023-05-24 16:57 ` [PATCH v7 04/12] x86/asm: Add a wrapper function for the LOADIWKEY instruction Chang S. Bae 2023-05-24 16:57 ` [dm-devel] " Chang S. Bae 2023-05-24 16:57 ` [PATCH v7 05/12] x86/msr-index: Add MSRs for Key Locker wrapping key Chang S. Bae 2023-05-24 16:57 ` [dm-devel] " Chang S. Bae 2023-05-24 16:57 ` [PATCH v7 06/12] x86/keylocker: Define Key Locker CPUID leaf Chang S. Bae 2023-05-24 16:57 ` [dm-devel] " Chang S. Bae 2023-05-24 16:57 ` [PATCH v7 07/12] x86/cpu/keylocker: Load a wrapping key at boot-time Chang S. Bae 2023-05-24 16:57 ` [dm-devel] " Chang S. Bae 2023-05-24 16:57 ` [PATCH v7 08/12] x86/PM/keylocker: Restore the wrapping key on the resume from ACPI S3/4 Chang S. Bae 2023-05-24 16:57 ` [dm-devel] " Chang S. Bae 2023-05-24 16:57 ` [PATCH v7 09/12] x86/cpu: Add a configuration and command line option for Key Locker Chang S. Bae 2023-05-24 16:57 ` [dm-devel] " Chang S. Bae 2023-05-24 16:57 ` [PATCH v7 10/12] crypto: x86/aesni - Use the proper data type in struct aesni_xts_ctx Chang S. Bae 2023-05-24 16:57 ` [dm-devel] " Chang S. Bae 2023-05-26 6:54 ` Eric Biggers 2023-05-26 6:54 ` [dm-devel] " Eric Biggers 2023-05-30 20:50 ` Chang S. Bae 2023-05-30 20:50 ` [dm-devel] " Chang S. Bae 2023-05-24 16:57 ` [PATCH v7 11/12] crypto: x86/aes - Prepare for a new AES implementation Chang S. Bae 2023-05-24 16:57 ` [dm-devel] " Chang S. Bae 2023-05-24 16:57 ` [dm-devel] [PATCH v7 12/12] crypto: x86/aes-kl - Implement the AES-XTS algorithm Chang S. Bae 2023-05-24 16:57 ` Chang S. Bae 2023-05-26 7:23 ` Eric Biggers 2023-05-26 7:23 ` [dm-devel] " Eric Biggers 2023-05-30 20:49 ` Chang S. Bae 2023-05-30 20:49 ` [dm-devel] " Chang S. Bae 2023-06-03 15:22 ` [PATCH v8 00/12] x86: Support Key Locker Chang S. Bae 2023-06-03 15:22 ` [dm-devel] " Chang S. Bae 2023-06-03 15:22 ` [PATCH v8 01/12] Documentation/x86: Document " Chang S. Bae 2023-06-03 15:22 ` [dm-devel] " Chang S. Bae 2023-06-05 10:54 ` Bagas Sanjaya 2023-06-05 10:54 ` [dm-devel] " Bagas Sanjaya 2023-06-06 2:17 ` Randy Dunlap 2023-06-06 2:17 ` [dm-devel] " Randy Dunlap 2023-06-06 4:18 ` Chang S. Bae 2023-06-06 4:18 ` [dm-devel] " Chang S. Bae 2023-06-03 15:22 ` [PATCH v8 02/12] x86/cpufeature: Enumerate Key Locker feature Chang S. Bae 2023-06-03 15:22 ` [dm-devel] " Chang S. Bae 2023-06-03 15:22 ` [PATCH v8 03/12] x86/insn: Add Key Locker instructions to the opcode map Chang S. Bae 2023-06-03 15:22 ` [dm-devel] " Chang S. Bae 2023-06-03 15:22 ` [PATCH v8 04/12] x86/asm: Add a wrapper function for the LOADIWKEY instruction Chang S. Bae 2023-06-03 15:22 ` [dm-devel] " Chang S. Bae 2023-06-03 15:22 ` [PATCH v8 05/12] x86/msr-index: Add MSRs for Key Locker wrapping key Chang S. Bae 2023-06-03 15:22 ` [dm-devel] " Chang S. Bae 2023-06-03 15:22 ` [PATCH v8 06/12] x86/keylocker: Define Key Locker CPUID leaf Chang S. Bae 2023-06-03 15:22 ` [dm-devel] " Chang S. Bae 2023-06-03 15:22 ` [PATCH v8 07/12] x86/cpu/keylocker: Load a wrapping key at boot-time Chang S. Bae 2023-06-03 15:22 ` [dm-devel] " Chang S. Bae 2023-06-03 15:22 ` [PATCH v8 08/12] x86/PM/keylocker: Restore the wrapping key on the resume from ACPI S3/4 Chang S. Bae 2023-06-03 15:22 ` [dm-devel] " Chang S. Bae 2023-06-03 15:22 ` [PATCH v8 09/12] x86/cpu: Add a configuration and command line option for Key Locker Chang S. Bae 2023-06-03 15:22 ` [dm-devel] " Chang S. Bae 2023-06-03 16:37 ` Borislav Petkov 2023-06-03 16:37 ` [dm-devel] " Borislav Petkov 2023-06-04 22:13 ` Chang S. Bae 2023-06-04 22:13 ` [dm-devel] " Chang S. Bae 2023-06-03 15:22 ` [PATCH v8 10/12] crypto: x86/aesni - Use the proper data type in struct aesni_xts_ctx Chang S. Bae 2023-06-03 15:22 ` [dm-devel] " Chang S. Bae 2023-06-04 15:34 ` Eric Biggers 2023-06-04 15:34 ` [dm-devel] " Eric Biggers 2023-06-04 22:02 ` Chang S. Bae 2023-06-04 22:02 ` [dm-devel] " Chang S. Bae 2023-06-05 2:46 ` Eric Biggers 2023-06-05 2:46 ` [dm-devel] " Eric Biggers 2023-06-05 4:41 ` Chang S. Bae 2023-06-05 4:41 ` Chang S. Bae 2023-06-21 12:06 ` [PATCH] crypto: x86/aesni: Align the address before aes_set_key_common() Chang S. Bae 2023-07-14 8:51 ` Herbert Xu 2023-06-03 15:22 ` [PATCH v8 11/12] crypto: x86/aes - Prepare for a new AES-XTS implementation Chang S. Bae 2023-06-03 15:22 ` [dm-devel] " Chang S. Bae 2023-06-03 15:22 ` [PATCH v8 12/12] crypto: x86/aes-kl - Implement the AES-XTS algorithm Chang S. Bae 2023-06-03 15:22 ` [dm-devel] " Chang S. Bae 2023-06-07 5:35 ` Eric Biggers [this message] 2023-06-07 5:35 ` Eric Biggers 2023-06-07 22:06 ` Chang S. Bae 2023-06-07 22:06 ` [dm-devel] " Chang S. Bae 2024-03-11 21:32 ` [PATCH] crypto: x86/aesni - Update aesni_set_key() to return void Chang S. Bae 2024-03-12 2:15 ` Eric Biggers 2024-03-12 7:46 ` Ard Biesheuvel 2024-03-12 15:03 ` Chang S. Bae 2024-03-12 15:18 ` Ard Biesheuvel 2024-03-12 15:37 ` Chang S. Bae 2024-03-22 23:04 ` [PATCH v2 0/2] crypto: x86/aesni - Simplify AES key expansion code Chang S. Bae 2024-03-22 23:04 ` [PATCH v2 1/2] crypto: x86/aesni - Rearrange AES key size check Chang S. Bae 2024-03-22 23:04 ` [PATCH v2 2/2] crypto: x86/aesni - Update aesni_set_key() to return void Chang S. Bae 2024-03-28 10:57 ` [PATCH v2 0/2] crypto: x86/aesni - Simplify AES key expansion code Herbert Xu 2024-03-29 1:53 ` [PATCH v9 00/14] x86: Support Key Locker Chang S. Bae 2024-03-29 1:53 ` [PATCH v9 01/14] Documentation/x86: Document " Chang S. Bae 2024-03-31 15:48 ` Randy Dunlap 2024-03-29 1:53 ` [PATCH v9 02/14] x86/cpufeature: Enumerate Key Locker feature Chang S. Bae 2024-03-29 1:53 ` [PATCH v9 03/14] x86/insn: Add Key Locker instructions to the opcode map Chang S. Bae 2024-03-29 1:53 ` [PATCH v9 04/14] x86/asm: Add a wrapper function for the LOADIWKEY instruction Chang S. Bae 2024-03-29 1:53 ` [PATCH v9 05/14] x86/msr-index: Add MSRs for Key Locker wrapping key Chang S. Bae 2024-03-29 1:53 ` [PATCH v9 06/14] x86/keylocker: Define Key Locker CPUID leaf Chang S. Bae 2024-03-29 1:53 ` [PATCH v9 07/14] x86/cpu/keylocker: Load a wrapping key at boot time Chang S. Bae 2024-04-07 23:04 ` [PATCH v9a " Chang S. Bae 2024-03-29 1:53 ` [PATCH v9 08/14] x86/PM/keylocker: Restore the wrapping key on the resume from ACPI S3/4 Chang S. Bae 2024-03-29 1:53 ` [PATCH v9 09/14] x86/hotplug/keylocker: Ensure wrapping key backup capability Chang S. Bae 2024-03-29 1:53 ` [PATCH v9 10/14] x86/cpu/keylocker: Check Gather Data Sampling mitigation Chang S. Bae 2024-03-29 6:57 ` Pawan Gupta 2024-04-07 23:04 ` [PATCH v9a " Chang S. Bae 2024-04-19 0:01 ` Pawan Gupta 2024-04-22 7:49 ` Chang S. Bae 2024-04-19 17:47 ` [PATCH 15/14] x86/gds: Lock GDS mitigation when keylocker feature is present Pawan Gupta 2024-04-19 18:03 ` Daniel Sneddon 2024-04-19 20:19 ` Pawan Gupta 2024-04-19 20:33 ` Daniel Sneddon 2024-04-22 7:35 ` Chang S. Bae 2024-04-22 21:32 ` Pawan Gupta 2024-04-22 22:13 ` Chang S. Bae 2024-03-29 1:53 ` [PATCH v9 11/14] x86/cpu/keylocker: Check Register File Data Sampling mitigation Chang S. Bae 2024-03-29 6:20 ` Pawan Gupta 2024-04-07 23:04 ` [PATCH v9a " Chang S. Bae 2024-03-29 1:53 ` [PATCH v9 12/14] x86/Kconfig: Add a configuration for Key Locker Chang S. Bae 2024-03-29 1:53 ` [PATCH v9 13/14] crypto: x86/aes - Prepare for new AES-XTS implementation Chang S. Bae 2024-03-29 1:53 ` [PATCH v9 14/14] crypto: x86/aes-kl - Implement the AES-XTS algorithm Chang S. Bae 2024-04-07 23:24 ` [PATCH v9 00/14] x86: Support Key Locker Chang S. Bae 2024-04-08 1:48 ` Eric Biggers 2024-04-15 22:16 ` Chang S. Bae 2024-04-15 22:54 ` Eric Biggers 2024-04-15 22:58 ` Chang S. Bae
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20230607053558.GC941@sol.localdomain \ --to=ebiggers@kernel.org \ --cc=ardb@kernel.org \ --cc=bernie.keany@intel.com \ --cc=bp@alien8.de \ --cc=chang.seok.bae@intel.com \ --cc=charishma1.gairuboyina@intel.com \ --cc=dan.j.williams@intel.com \ --cc=dave.hansen@linux.intel.com \ --cc=davem@davemloft.net \ --cc=dm-devel@redhat.com \ --cc=elliott@hpe.com \ --cc=gmazyland@gmail.com \ --cc=herbert@gondor.apana.org.au \ --cc=hpa@zytor.com \ --cc=lalithambika.krishnakumar@intel.com \ --cc=linux-crypto@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@kernel.org \ --cc=mingo@kernel.org \ --cc=mingo@redhat.com \ --cc=nhuck@google.com \ --cc=tglx@linutronix.de \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.