[PATCH v3 0/1] dm-crypt: allow encryption sector size up to PAGE_SIZE

[Itai Handler]

dm-crypt caps the "sector_size:" option at 4096 bytes.  Commit
8f0009a22517 ("dm crypt: optionally support larger encryption sector
size") gives the reason: the sector has to fit the page limit, so the
cap was set to the smallest page size any architecture has.  This
resolves that same rule against the kernel being built instead, so a
kernel with larger pages is not held to another architecture's limit.

v2: https://lore.kernel.org/dm-devel/20260922120330.127262-1-itai.handler@xxxxxxxxx/
v1: https://lore.kernel.org/dm-devel/CAFpOueRBb9y_Fgb3-c6_eFTKZR9DoAXZmxqqx0UH1Yb2rbV0RQ@xxxxxxxxxxxxxx/

Changes since v2
----------------

- Dropped the dm-verity comparison.  Milan pointed out that dm-verity is
  read-only, so its PAGE_SIZE bound says nothing about a writable
  target.  It was never load-bearing; it is just gone.

- Dropped qce as the motivation.  Eric was right that it is slower than
  the CPU cipher and marked BROKEN, so numbers from it argue for
  nothing.  The commit message now works from the reason the limit was
  given when it was introduced, and mentions DMA offload only as a
  possibility that depends on the driver.

- Documented in dm-crypt.rst that a sector larger than the device's
  atomic write unit can be torn by a power failure, and what that costs
  in each cipher mode, AEAD included.

- Used MIN_T() rather than min_t() for the bound, so it stays usable as
  a constant expression; min_t() expands to a statement expression.

- Dropped the claim that the documented range tops out at 65536.  It
  does not: without transparent hugepages BLK_MAX_BLOCK_SIZE is
  PAGE_SIZE, so on a 256K-page configuration the bound is PAGE_SIZE.
  The documentation now states the rule rather than a number.

On refusing other cipher modes
------------------------------

Mikulas asked for sector sizes above 4096 to be refused for modes other
than XTS and ECB.  This version does not do that.  Since the decision is
his rather than mine, the patch for it is written and tested and will go
out on request.

What gives me pause is only this:

- An allow-list of two mode names has to be revisited whenever a mode is
  added, by someone who remembers why it is there.

- It gives 4096 a safety meaning that the block layer declines to give
  it.  nvme_configure_atomic_write() trusts only NAWUPF and otherwise
  falls back to a single logical block, and nvme_update_disk_info() caps
  physical_block_size by atomic_bs precisely so nothing above it assumes
  a physical block is written atomically.  A drive advertising no atomic
  write unit, which is the common case, can already tear a 4096-byte
  sector.

- Selecting on tear-tolerance alone admits ecb(), which nobody should
  use for disk encryption, while refusing cbc().

Against that, his point that the modes differ in how badly a tear hurts
is right, and v3 writes it down per mode in dm-crypt.rst - which is the
part I should have done in v2 instead of only arguing.

On a 64K-page kernel the restriction refuses aes-cbc-essiv:sha256 at
65536 while leaving XTS and ECB working, including ESSIV-wrapped XTS,
and changes nothing at or below 4096.  Either form works - patch 2/2 of
a v4, or a standalone follow-up - whichever is preferred.

Answering Milan on NVMe
-----------------------

"Which NVMe supports 64K sectors?" - none, and none has to.  The
encryption sector is dm-crypt's own chunking unit, not something the
backing device has to support.  bdev_logical_block_size() appears once
in the whole target, inside a max() that aligns the I/O size.  The
mapped device announces the larger block upward through
dm_stack_bs_limits(); the device underneath keeps its own.  In the
testing below the backing device is /dev/ram0 with a 512-byte logical
block, carrying a 65536-byte encryption sector.

Testing
-------

Built for x86_64 and for arm64 with 4K and with 64K pages; no new
warnings.  A temporary static_assert confirmed the bound is 4096 on
x86_64 and on arm64/4K - so the patch is a no-op on both - and 65536 on
arm64 with 64K pages.

Booted under qemu-system-aarch64, loading crypt tables over /dev/ram0
with dmsetup and reading back what the kernel recorded:

  sector_size   v1.29.0        v1.30.0, 4K   v1.30.0, 64K
       512      ok             ok            ok
      1024      ok             ok            ok
      4096      ok             ok            ok
     65536      EINVAL         EINVAL        ok, lbs 65536
     69632      ok, 4096 (!)   EINVAL        EINVAL
    131072      EINVAL         EINVAL        EINVAL
         0      EINVAL         EINVAL        EINVAL

Every row was run with aes-xts-plain64, aes-cbc-essiv:sha256 and
aes-ecb, and the result was the same for all three: this version refuses
nothing on the basis of the cipher.

The 69632 row is the truncation the patch fixes.  It wraps to 4096
today, the table loads, and the device announces a 4096-byte logical
block.  logical_block_size in sysfs followed the recorded sector size in
every accepted case.

Also exercised at 65536 on 64K pages: aes-xts-essiv:sha256, the capi:
form of xts(aes), and iv_large_sectors, which is where sector_shift
reaches 7.  256 KiB round-tripped through the mapped device
byte-identical at sector_size 65536 and 4096, with the ciphertext on
/dev/ram0 confirmed to differ from the plaintext.

Not covered: dm-integrity caps its block_size at 4096, so the AEAD and
integrity-tag paths cannot be driven above that today and were tested
only at 4096 and below.

Userspace
---------

Nothing is needed for this patch.  cryptsetup caps the sector size at
4096 on every path that writes a LUKS header, so no LUKS device gains a
larger sector however new the kernel is; on-disk format policy stays in
userspace, which was Milan's point in v2 and is why no LUKS2 change is
proposed here.  The LUKS2 header-validation patch posted alongside v2
was withdrawn - Ondrej was right that the missing bound is deliberate.

Itai Handler (1):
  dm-crypt: allow encryption sector size up to PAGE_SIZE

 .../admin-guide/device-mapper/dm-crypt.rst    | 20 ++++++++++++-
 drivers/md/dm-crypt.c                         | 30 +++++++++++++++----
 2 files changed, 43 insertions(+), 7 deletions(-)


base-commit: c0df022cb0fa2bbee74bd9b90c66790bcd4e3050
-- 
2.34.1