From: "Chang S. Bae" <chang.seok.bae@intel.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: <linux-kernel@vger.kernel.org>, <linux-crypto@vger.kernel.org>,
<dm-devel@redhat.com>, <gmazyland@gmail.com>, <luto@kernel.org>,
<dave.hansen@linux.intel.com>, <tglx@linutronix.de>, <bp@suse.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>,
"David S. Miller" <davem@davemloft.net>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
"Nathan Chancellor" <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Tom Rix <trix@redhat.com>
Subject: Re: [PATCH v6 11/12] crypto: x86/aes-kl - Support AES algorithm using Key Locker instructions
Date: Mon, 8 May 2023 11:18:06 -0700 [thread overview]
Message-ID: <288de217-f0ff-658c-5490-6fbf5f57f5a7@intel.com> (raw)
In-Reply-To: <ZFWY6/VelArVYy1F@gmail.com>
On 5/5/2023 5:01 PM, Eric Biggers wrote:
> 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!
Yeah. But, there are more things to go away here as you pointed out here.
I thought some generic establishment (patch10) then introduce some
mode-specific code (patch11). Considerably, this incremental change was
expected to help reviewers.
Now I realize this introduces dead code on its hindsight. And this
approach seems not helping that much.
> 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.
Yes, I agree to merge them.
>> 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?
I think AES-KL could be a drop-in replacement for AES-NI IF it performs
well -- something on par with AES-NI or better, AND it also supports all
the key sizes. But, it can't be the default because that's not the case
(at least for now).
> 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?
I think those AES implementations are functionally the same to end
users. The key envelopment is not something user-visible to my
understanding. So, I thought that same name makes sense.
Now looking at the changelog, this text in the 'performance' section
appears to be relevant:
> 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.
But, this does not seem to be clear enough. Maybe, this exposition story
can go under a new section. The changelog is already tl;dr...
> 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.
Yeah, will do. Also, I'd make the module available only with X86-64.
Then, a bit of comments for the reason should come along.
>> +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.
I thought this is something benign to stay here. But, yes, I agree that
it is better to simplify the code.
Thanks,
Chang
next prev parent reply other threads:[~2023-05-08 18:18 UTC|newest]
Thread overview: 147+ 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 ` [PATCH v5 01/12] Documentation/x86: Document " Chang S. Bae
2023-06-05 10:52 ` 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 ` [PATCH v5 03/12] x86/insn: Add Key Locker instructions to the opcode map 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 ` [PATCH v5 05/12] x86/msr-index: Add MSRs for Key Locker internal wrapping key 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 ` [PATCH v5 07/12] x86/cpu/keylocker: Load an internal wrapping key at boot-time Chang S. Bae
2022-08-23 15:49 ` Evan Green
2022-08-24 22:20 ` Chang S. Bae
2022-08-24 22:52 ` Evan Green
2022-08-25 1:06 ` Chang S. Bae
2022-08-25 15:31 ` Evan Green
2022-08-31 23:08 ` Chang S. Bae
2022-09-06 16:22 ` Evan Green
2022-09-06 16:46 ` 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-29 17:31 ` [PATCH v5-fix " 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 ` [PATCH v5 10/12] crypto: x86/aes - Prepare for a new AES implementation 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 ` [PATCH v5 12/12] crypto: x86/aes-kl - Support XTS mode Chang S. Bae
2022-01-13 22:16 ` [PATCH v5 00/12] x86: Support Key Locker Dave Hansen
2022-01-13 22:34 ` Bae, Chang Seok
2023-04-10 22:59 ` [PATCH v6 " Chang S. Bae
2023-04-10 22:59 ` [PATCH v6 01/12] Documentation/x86: Document " 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 ` [PATCH v6 03/12] x86/insn: Add Key Locker instructions to the opcode map 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 ` [PATCH v6 05/12] x86/msr-index: Add MSRs for Key Locker internal wrapping key 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 ` [PATCH v6 07/12] x86/cpu/keylocker: Load an internal wrapping key at boot-time Chang S. Bae
2023-05-05 23:05 ` Eric Biggers
2023-05-08 18:18 ` Chang S. Bae
2023-05-08 21:56 ` Dave Hansen
2023-05-09 0:31 ` Chang S. Bae
2023-05-09 0:51 ` Dave Hansen
2023-05-08 19:18 ` Elliott, Robert (Servers)
2023-05-08 20:15 ` 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-05-05 23:09 ` Eric Biggers
2023-05-08 18:18 ` 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 ` [PATCH v6 10/12] crypto: x86/aes - Prepare for a new AES implementation Chang S. Bae
2023-05-05 23:27 ` Eric Biggers
2023-05-09 0:55 ` Chang S. Bae
2023-05-11 19:05 ` Chang S. Bae
2023-05-11 21:39 ` Eric Biggers
2023-05-11 23:19 ` 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-05-06 0:01 ` Eric Biggers
2023-05-08 18:18 ` Chang S. Bae [this message]
2023-05-24 17:18 ` Chang S. Bae
2023-05-12 17:52 ` Milan Broz
2023-05-08 19:21 ` Elliott, Robert (Servers)
2023-05-08 19:24 ` Elliott, Robert (Servers)
2023-05-08 20:00 ` Chang S. Bae
2023-04-10 22:59 ` [PATCH v6 12/12] crypto: x86/aes-kl - Support XTS mode Chang S. Bae
2023-05-24 16:57 ` [PATCH v7 00/12] x86: Support Key Locker Chang S. Bae
2023-05-24 16:57 ` [PATCH v7 01/12] Documentation/x86: Document " 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 ` [PATCH v7 03/12] x86/insn: Add Key Locker instructions to the opcode map 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 ` [PATCH v7 05/12] x86/msr-index: Add MSRs for Key Locker wrapping key 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 ` [PATCH v7 07/12] x86/cpu/keylocker: Load a wrapping key at boot-time 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 ` [PATCH v7 09/12] x86/cpu: Add a configuration and command line option for Key Locker 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-26 6:54 ` Eric Biggers
2023-05-30 20:50 ` 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 ` [PATCH v7 12/12] crypto: x86/aes-kl - Implement the AES-XTS algorithm Chang S. Bae
2023-05-26 7:23 ` Eric Biggers
2023-05-30 20:49 ` Chang S. Bae
2023-06-03 15:22 ` [PATCH v8 00/12] x86: Support Key Locker Chang S. Bae
2023-06-03 15:22 ` [PATCH v8 01/12] Documentation/x86: Document " Chang S. Bae
2023-06-05 10:54 ` Bagas Sanjaya
2023-06-06 2:17 ` Randy Dunlap
2023-06-06 4:18 ` 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 ` [PATCH v8 03/12] x86/insn: Add Key Locker instructions to the opcode map 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 ` [PATCH v8 05/12] x86/msr-index: Add MSRs for Key Locker wrapping key 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 ` [PATCH v8 07/12] x86/cpu/keylocker: Load a wrapping key at boot-time 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 ` [PATCH v8 09/12] x86/cpu: Add a configuration and command line option for Key Locker Chang S. Bae
2023-06-03 16:37 ` Borislav Petkov
2023-06-04 22:13 ` 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-04 15:34 ` Eric Biggers
2023-06-04 22:02 ` Chang S. Bae
2023-06-05 2:46 ` Eric Biggers
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 ` [PATCH v8 12/12] crypto: x86/aes-kl - Implement the AES-XTS algorithm Chang S. Bae
2023-06-07 5:35 ` Eric Biggers
2023-06-07 22:06 ` 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=288de217-f0ff-658c-5490-6fbf5f57f5a7@intel.com \
--to=chang.seok.bae@intel.com \
--cc=ardb@kernel.org \
--cc=bernie.keany@intel.com \
--cc=bp@alien8.de \
--cc=bp@suse.de \
--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=ebiggers@kernel.org \
--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=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=tglx@linutronix.de \
--cc=trix@redhat.com \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).