All of lore.kernel.org
 help / color / mirror / Atom feed
From: Milan Broz <gmazyland@gmail.com>
To: "Bae, Chang Seok" <chang.seok.bae@intel.com>
Cc: "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Krishnakumar,
	Lalithambika" <lalithambika.krishnakumar@intel.com>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	"Lutomirski, Andy" <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@suse.de>, Ingo Molnar <mingo@kernel.org>,
	"Gairuboyina, Charishma1" <charishma1.gairuboyina@intel.com>,
	"Dwarakanath, Kumar N" <kumar.n.dwarakanath@intel.com>,
	Eric Biggers <ebiggers@kernel.org>
Subject: Re: [dm-devel] [PATCH v4 00/13] x86: Support Key Locker
Date: Thu, 6 Jan 2022 17:25:34 +0100	[thread overview]
Message-ID: <120368dc-e337-9176-936c-4db2a8bf710e@gmail.com> (raw)
In-Reply-To: <YdZ5HrOKEffBrQIm@sol.localdomain>

On 06/01/2022 06:07, Eric Biggers wrote:
> On Wed, Jan 05, 2022 at 09:55:17PM +0000, Bae, Chang Seok wrote:
>>>> +-----------+---------------+---------------+
>>>> | Cipher    |   Encryption  | Decryption    |
>>>> | (AES-KL)  |    (MiB/s)    | (MiB/s)       |
>>>> +-----------+---------------+---------------+
>>>> | AES-CBC   |     505.3     |   2097.8      |
>>>> | AES-XTS   |     1130      |   696.4       |
>>>> +-----------+-------------------------------+
>>>
>>> Why is AES-XTS decryption so much slower than AES-XTS encryption?  They should
>>> be about the same.
>>
>> Analyzing and understanding this with specific hardware implementation takes
>> time for us. Will come back and update you when we have anything to share here.
> 
> Note that for disk encryption, decryption performance is usually more important
> than encryption performance.  So your performance results are strange.

If the test results are from "cryptsetup benchmark", it just run benchmark
through userspace crypto API (AF_ALG) - no dm-crypt is involved at all.

Proper test with dm-crypt should be run to get some numbers too.

(But the test results are really strange... there is no reason
decryption should be slower for XTS.)

Also you mention that
> Bare metal disk encryption is the only use case intended by these patches.
> Userspace usage is not supported because there is no ABI provided to
> communicate and coordinate wrapping-key restore failures to userspace.

The cryptsetup benchmark is userspace use (just with kernel netlink
access to kernel crypto). So I am not sure if these number are so important.

Milan

WARNING: multiple messages have this Message-ID (diff)
From: Milan Broz <gmazyland@gmail.com>
To: "Bae, Chang Seok" <chang.seok.bae@intel.com>
Cc: "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Eric Biggers <ebiggers@kernel.org>,
	"Krishnakumar,
	Lalithambika" <lalithambika.krishnakumar@intel.com>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	"Lutomirski, Andy" <luto@kernel.org>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	Borislav Petkov <bp@suse.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Gairuboyina, Charishma1" <charishma1.gairuboyina@intel.com>,
	"Dwarakanath, Kumar N" <kumar.n.dwarakanath@intel.com>
Subject: Re: [dm-devel] [PATCH v4 00/13] x86: Support Key Locker
Date: Thu, 6 Jan 2022 17:25:34 +0100	[thread overview]
Message-ID: <120368dc-e337-9176-936c-4db2a8bf710e@gmail.com> (raw)
In-Reply-To: <YdZ5HrOKEffBrQIm@sol.localdomain>

On 06/01/2022 06:07, Eric Biggers wrote:
> On Wed, Jan 05, 2022 at 09:55:17PM +0000, Bae, Chang Seok wrote:
>>>> +-----------+---------------+---------------+
>>>> | Cipher    |   Encryption  | Decryption    |
>>>> | (AES-KL)  |    (MiB/s)    | (MiB/s)       |
>>>> +-----------+---------------+---------------+
>>>> | AES-CBC   |     505.3     |   2097.8      |
>>>> | AES-XTS   |     1130      |   696.4       |
>>>> +-----------+-------------------------------+
>>>
>>> Why is AES-XTS decryption so much slower than AES-XTS encryption?  They should
>>> be about the same.
>>
>> Analyzing and understanding this with specific hardware implementation takes
>> time for us. Will come back and update you when we have anything to share here.
> 
> Note that for disk encryption, decryption performance is usually more important
> than encryption performance.  So your performance results are strange.

If the test results are from "cryptsetup benchmark", it just run benchmark
through userspace crypto API (AF_ALG) - no dm-crypt is involved at all.

Proper test with dm-crypt should be run to get some numbers too.

(But the test results are really strange... there is no reason
decryption should be slower for XTS.)

Also you mention that
> Bare metal disk encryption is the only use case intended by these patches.
> Userspace usage is not supported because there is no ABI provided to
> communicate and coordinate wrapping-key restore failures to userspace.

The cryptsetup benchmark is userspace use (just with kernel netlink
access to kernel crypto). So I am not sure if these number are so important.

Milan

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


  parent reply	other threads:[~2022-01-06 16:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-14  0:51 [PATCH v4 00/13] x86: Support Key Locker Chang S. Bae
2021-12-14  0:52 ` [PATCH v4 01/13] Documentation/x86: Document " Chang S. Bae
2021-12-14  0:52 ` [PATCH v4 02/13] x86/cpufeature: Enumerate Key Locker feature Chang S. Bae
2021-12-14  0:52 ` [PATCH v4 03/13] x86/insn: Add Key Locker instructions to the opcode map Chang S. Bae
2021-12-14  0:52 ` [PATCH v4 04/13] x86/asm: Add a wrapper function for the LOADIWKEY instruction Chang S. Bae
2021-12-14  0:52 ` [PATCH v4 05/13] x86/msr-index: Add MSRs for Key Locker internal wrapping key Chang S. Bae
2021-12-14  0:52 ` [PATCH v4 06/13] x86/keylocker: Define Key Locker CPUID leaf Chang S. Bae
2021-12-14  0:52 ` [PATCH v4 07/13] x86/cpu/keylocker: Load an internal wrapping key at boot-time Chang S. Bae
2021-12-14  0:52 ` [PATCH v4 08/13] x86/power/keylocker: Restore internal wrapping key from the ACPI S3/4 sleep states Chang S. Bae
2021-12-17 15:42   ` Rafael J. Wysocki
2021-12-22  4:58     ` Bae, Chang Seok
2021-12-14  0:52 ` [PATCH v4 09/13] x86/cpu: Add a configuration and command line option for Key Locker Chang S. Bae
2021-12-14  0:52 ` [PATCH v4 10/13] crypto: x86/aes - Prepare for a new AES implementation Chang S. Bae
2021-12-14  0:52 ` [PATCH v4 11/13] crypto: x86/aes-kl - Support AES algorithm using Key Locker instructions Chang S. Bae
2021-12-24 17:42   ` Andy Lutomirski
2022-01-07 18:06     ` Bae, Chang Seok
2021-12-14  0:52 ` [PATCH v4 12/13] crypto: x86/aes-kl - Support CBC mode Chang S. Bae
2021-12-14  0:52 ` [PATCH v4 13/13] crypto: x86/aes-kl - Support XTS mode Chang S. Bae
2021-12-16  1:09 ` [PATCH v4 00/13] x86: Support Key Locker Eric Biggers
2022-01-05 21:55   ` Bae, Chang Seok
2022-01-05 21:55     ` [dm-devel] " Bae, Chang Seok
2022-01-06  5:07     ` Eric Biggers
2022-01-06  5:07       ` [dm-devel] " Eric Biggers
2022-01-06  6:13       ` Bae, Chang Seok
2022-01-06  6:13         ` [dm-devel] " Bae, Chang Seok
2022-01-06 16:25       ` Milan Broz [this message]
2022-01-06 16:25         ` Milan Broz

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=120368dc-e337-9176-936c-4db2a8bf710e@gmail.com \
    --to=gmazyland@gmail.com \
    --cc=bp@suse.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=dm-devel@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=kumar.n.dwarakanath@intel.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=ravi.v.shankar@intel.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: link
Be 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.