On 20/06/2019 15:40, Herbert Xu wrote: > On Thu, Jun 20, 2019 at 03:02:04PM +0200, Ard Biesheuvel wrote: >> >> It also depend on how realistic it is that we will need to support >> arbitrary sector sizes in the future. I mean, if we decide today that >> essiv() uses an implicit sector size of 4k, we can always add >> essiv64k() later, rather than adding lots of complexity now that we >> are never going to use. Note that ESSIV is already more or less >> deprecated, so there is really no point in inventing these weird and >> wonderful things if we want people to move to XTS and plain IV >> generation instead. > > Well whatever we do for ESSIV should also extend to other IV > generators in dm-crypt so that potentially we can have a single > interface for dm-crypt multi-sector processing in future (IOW > you don't have special code for ESSIV vs. other algos). > > That is why we should get the ESSIV interface right as it could > serve as an example for future implementations. > > What do the dm-crypt people think? Are you ever going to need > processing in units other than 4K? For the "technical" limit, dm-crypt supports 512, 1024, 2048 and 4096-byte encryption sector size (power of two) since commit 8f0009a225171cc1b76a6b443de5137b26e1374b. As the commit says, the 4k limit is because of page limit where whole IO must fit (4k is minimal page size). I do not want to introduce devices that are created on some architecture and cannot be opened elsewhere with a smaller page size. But maybe some reason appears, or there is some trick we did not tried... (I guess fs has the same limits?) Milan
