dm-crypt: allow encryption sector size up to PAGE_SIZE

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/[email protected]/
v1: https://lore.kernel.org/dm-devel/CAFpOueRBb9y_Fgb3-c6_eFTKZR9DoAXZmxqqx0UH1Yb2rbV0RQ@mail.gmail.com/

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