lkml.org 
[lkml]   [2022]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [dm-devel] [PATCH v4 00/13] x86: Support Key Locker
From
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

\
 
 \ /
  Last update: 2022-01-06 17:26    [W:0.073 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site