From: Milan Broz <gmazyland@gmail.com>
To: Herbert Xu <herbert@gondor.apana.org.au>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gilad Ben-Yossef <gilad@benyossef.com>,
device-mapper development <dm-devel@redhat.com>,
linux-fscrypt@vger.kernel.org, linux-crypto@vger.kernel.org,
Eric Biggers <ebiggers@google.com>
Subject: Re: [dm-devel] [PATCH v4 0/6] crypto: switch to crypto API for ESSIV generation
Date: Mon, 24 Jun 2019 08:52:11 +0200 [thread overview]
Message-ID: <5ebd992b-cb01-6dcc-f571-55afbb05c03b@gmail.com> (raw)
In-Reply-To: <20190623101241.6cr4sbxyviigu3sz@gondor.apana.org.au>
On 23/06/2019 12:12, Herbert Xu wrote:
> On Sun, Jun 23, 2019 at 11:30:41AM +0200, Ard Biesheuvel wrote:
>>
>> So with that in mind, I think we should decouple the multi-sector
>> discussion and leave it for a followup series, preferably proposed by
>> someone who also has access to some hardware to prototype it on.
>
> Yes that makes sense.
Yes.
And TBH, the most important optimization for dm-crypt in this case
is processing 8 512-bytes sectors in 4k encryption block (because page
cache will generate page-sized bios) and with XTS mode and linear IV (plain64),
not ESSIV.
Dm-crypt can use 4k sectors directly, there are only two
blockers - you need LUKS2 to support it, and many devices
just do not advertise physical 4k sectors (many SSDs).
So switching to 4k could cause some problems with partial 4k writes
(after a crash or power-fail).
The plan for the dm-crypt side is more to focus on using 4k native
sectors than this micro-optimization in HW.
Milan
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2019-06-24 6:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-21 8:09 [PATCH v4 0/6] crypto: switch to crypto API for ESSIV generation Ard Biesheuvel
2019-06-21 8:09 ` [PATCH v4 1/6] crypto: essiv - create wrapper template " Ard Biesheuvel
2019-06-21 8:09 ` [PATCH v4 2/6] fs: crypto: invoke crypto API for ESSIV handling Ard Biesheuvel
2019-06-21 8:09 ` [PATCH v4 3/6] md: dm-crypt: infer ESSIV block cipher from cipher string directly Ard Biesheuvel
2019-06-21 8:09 ` [PATCH v4 4/6] md: dm-crypt: switch to ESSIV crypto API template Ard Biesheuvel
2019-06-24 7:05 ` [dm-devel] " Milan Broz
2019-06-24 7:40 ` Surachai Saiwong
2019-06-21 8:09 ` [PATCH v4 5/6] crypto: essiv - add test vector for essiv(cbc(aes),aes,sha256) Ard Biesheuvel
2019-06-21 8:09 ` [PATCH v4 6/6] crypto: arm64/aes - implement accelerated ESSIV/CBC mode Ard Biesheuvel
2019-06-23 9:30 ` [dm-devel] [PATCH v4 0/6] crypto: switch to crypto API for ESSIV generation Ard Biesheuvel
2019-06-23 10:12 ` Herbert Xu
2019-06-24 6:52 ` Milan Broz [this message]
2019-06-26 4:49 ` Eric Biggers
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=5ebd992b-cb01-6dcc-f571-55afbb05c03b@gmail.com \
--to=gmazyland@gmail.com \
--cc=ard.biesheuvel@linaro.org \
--cc=dm-devel@redhat.com \
--cc=ebiggers@google.com \
--cc=gilad@benyossef.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fscrypt@vger.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