On Tue, Sep 22, 2026 at 3:04 PM Itai Handler <[email protected]> wrote:
> A patch doing that is posted: > > > https://lore.kernel.org/cryptsetup/[email protected]/ > > It is not merged yet. That cryptsetup patch has since been declined, four minutes after I sent this series. Correcting the record here rather than leaving the reference dangling: https://lore.kernel.org/cryptsetup/[email protected]/ Ondrej Kozina's reasoning is that the missing upper bound in LUKS2 header validation is deliberate: bounding it would stop an older cryptsetup from even dumping a header that a newer dm-crypt might support, and the corruption case is already covered by the LUKS2 header checksum. Both points are correct, and I have withdrawn the patch. It does not change the position of this one, and it is worth spelling out why: - cryptsetup caps the encryption sector size at 4096 on every path that *writes* a LUKS header, and this patch does not touch that. No tool creates a LUKS device above 4096, so the portability of what cryptsetup produces is unchanged. - A LUKS header declaring more than 4096 can therefore only come from a deliberate edit, and as Ondrej notes LUKS2 metadata does not protect against deliberate harmful edits in general - changing 512 to 4096 breaks a device just as effectively. So the paragraph above should be read as: this is a case that requires hand-editing metadata, upstream cryptsetup considers guarding it the wrong trade-off, and I agree. Two remarks from that thread bear on this patch. Neither is an ack of it, but both are worth having in this thread: "There may be support for larger sectors in future dm-crypt." "Since dm-crypt constructor currently stops you from activating such device (w/ sector_size > 4096), it's ok." That is, cryptsetup deliberately leaves this limit to the dm-crypt constructor. This patch keeps it exactly there. It only changes the limit from a fixed 4096 to PAGE_SIZE, which is the bound dm-verity already applies to its own block size. Itai
