From: Mikulas Patocka <mpatocka@redhat.com>
To: Itai Handler <itai.handler@gmail.com>
Cc: Eric Biggers <ebiggers@kernel.org>,
Milan Broz <gmazyland@gmail.com>,
Alasdair Kergon <agk@redhat.com>,
Mike Snitzer <snitzer@kernel.org>,
Benjamin Marzinski <bmarzins@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
dm-devel@lists.linux.dev, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/1] dm-crypt: allow encryption sector size up to PAGE_SIZE
Date: Wed, 23 Sep 2026 11:58:25 +0200 (CEST) [thread overview]
Message-ID: <9a6c20da-4da9-4a8d-a6d4-f18900228bf6@redhat.com> (raw)
In-Reply-To: <CAFpOueSjekxhjEosQGiZ9BiDh5tFOqBPX5w_2PVsrcN6pO+dHw@mail.gmail.com>
On Wed, 23 Sep 2026, Itai Handler wrote:
> If there is a specific correctness, security, or architectural reason
> why dm-crypt should retain 4096 bytes as an absolute limit even on
> systems with larger PAGE_SIZE, I would be very interested to understand
> it. Otherwise, I think the question is better evaluated independently
> of whether QCE is a suitable accelerator.
>
> Thanks,
> Itai
There is one important problem - the SSDs and HDDs today have 4k hardware
sector size.
If you use 64k encryption sectors, the disk may write only a part of the
64k sector during power failure. When you attempt to read and decrypt such
a sector, you get garbage.
This is not a problem for XTS or ECB, but it is problem for CBC and most
other encryption modes. So, the patch should reject using larger sectors
with cipher modes other than XTS and ECB.
Mikulas
next prev parent reply other threads:[~2026-09-23 9:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 12:03 [PATCH v2 0/1] dm-crypt: allow encryption sector size up to PAGE_SIZE Itai Handler
2026-09-22 12:03 ` [PATCH v2 1/1] " Itai Handler
2026-09-22 12:34 ` [PATCH v2 0/1] " Itai Handler
2026-09-22 13:07 ` Milan Broz
2026-09-22 13:49 ` Itai Handler
2026-09-22 21:34 ` Eric Biggers
2026-09-23 7:29 ` Itai Handler
2026-09-23 9:58 ` Mikulas Patocka [this message]
2026-09-23 11:39 ` Itai Handler
2026-09-23 11:59 ` Mikulas Patocka
2026-09-23 12:43 ` Itai Handler
2026-09-23 15:28 ` David Laight
2026-09-23 15:42 ` Itai Handler
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=9a6c20da-4da9-4a8d-a6d4-f18900228bf6@redhat.com \
--to=mpatocka@redhat.com \
--cc=agk@redhat.com \
--cc=bmarzins@redhat.com \
--cc=corbet@lwn.net \
--cc=dm-devel@lists.linux.dev \
--cc=ebiggers@kernel.org \
--cc=gmazyland@gmail.com \
--cc=itai.handler@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.org \
--cc=snitzer@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