Given a physical device with sectors 0, 1, 2, ..., LUKS will reserve some sectors at the beginning for the header. Other than this offset, can we assume the remaining sectors are mapped in order (offset+1 => 1, offset+2 => 2, etc.)? Is this documented anywhere?

Knowing this is crucial when resizing a LUKS partition. If sectors are mapped in order, then we can simply cryptsetup resize --size <sectors> if we know how much space is actually used in the mapped device. Otherwise, we may lose data when doing so.

  • Why do you suspect LUKS performs a kind of scrambling in mapping of sector numbers? The LUKS security relies on strong encryption of the stored data, this is enough and there is no practical reason to play with sector numbers. And yes, it is documented in LUKS source code. – Serge Dec 11 '17 at 23:31
  • @Serge Well I'm not saying LUKS depends its security on the scrambling of sector numbers. But if there's no such restriction in specification then implementations can choose to do it or not. I didn't seem to find a word about this in this document. – Cyker Dec 11 '17 at 23:47
  • Cyker, for some reason I can't access that file to check the spec (it loads an empty page). I just wanted to point that there should be a rational reason to implement a 'scrambled' mapping and I cant imagine one: the only goal of LUKS is to encrypt the on-disk data (any interleave configurations for IO performance boost are in the past). Also the man page for cryptsetup does not say a word that its resize command is dangerous because of some sophisticated mapping (yes, it is dangerous as any other volume resize operation but not more). – Serge Dec 12 '17 at 0:14
  • @Serge Yes I checked man page and that doc and some more materials and they don't seem to mention whether the mapping is linear or not. Intuitively scrambling the sectors doesn't look good. But we still need to be responsible for user data and be extremely careful when performing potentially dangerous operations (such as shrinking a filesystem or partition). There has to be a green light to signal good to go. – Cyker Dec 12 '17 at 0:24
  • 1
    I just checked the source code. All the driver does to the original bio's sector number is an extra offset: check yourself git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/… for all occurrences of bi_sector. – Serge Dec 12 '17 at 0:33

On my system the output of dmsetup table crypto is:

0 209711104 crypt aes-xts-plain64 0000000000000[...]0000000000 0 254:6 4096

This is a linear mapping (like with all device mapper targets), just encrypted.


A better argument may be that encrypted volumes can be resized. If the underlying device is increased by one sector and the encrypting / decrypting DM device is increased by one sector, too, then it is obvious that the new upper layer sector can be mapped to the new lower layer sector only because otherwise the data in the upper layer would change.

In theory the lower layer data might be rewritten but as you can easily try this is not the case:

  1. The resize operation finishes instantly.
  2. The data in the lower old area does not change when the new upper area is written.
  • I have similar results running dmsetup. But why does this mean the mapping is linear? The table parameters are documented here, but still it doesn't mention if it's linear or not. – Cyker Dec 12 '17 at 0:14
  • Interestingly, the linear target does say it maps a linear range to a linear range (ref). However, this doesn't mean it's the same for crypt target. – Cyker Dec 12 '17 at 0:18
  • @Cyker See my edit. – Hauke Laging Dec 12 '17 at 1:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.