tcplay: 4k/sector hard disk

[devnullmail]

attempting to mount a volume created by tcplay on a 4k/sector hard disk, using the original truecrypt software, does not work (and vice versa).

analysis

tcplay appears to calculate the volume start offset incorrectly on 4k hard disks.

steps to reproduce

blank the disk, so we can see what's happening

dd if=/dev/zero of=/dev/sda bs=4096 count=`expr 1024 \* 1024`

create volume using insecure erase. (weak crypto optional; saves time).

tcplay -c -d /dev/sda -z -w

inspect the volume header, and observe that Sector Size=4096, IV Offset=32, Block Offset=32.

tcplay -i -d /dev/sda

inspect the raw disk sectors, observe that encrypted headers are written at 0x0

hd /dev/sda | less

map volume and write some test data

tcplay -m test -d /dev/sda
echo "HELLO WORLD" > /dev/mapper/test
tcplay -u test

inspect the raw disk sectors again. observe that encrypted headers are written at byte offset 0x0, and the encrypted "HELLO WORLD" text written at byte offset 0x4000 (32 * 512).

hd /dev/sda | less

expected result

the encrypted "HELLO WORLD" text should be written at byte offset 0x20000 (32 * 4096).

bonus points

make -i more meaningful. consider printing "sectors" after the IV Offset and Block Offset values.

[bwalex]

Last time I did anything with "4k" hard disks they turned out to report a physical block size of 512 bytes to the OS, so I don't really know much about this.

Does Linux report a 4k block size for the BLKSSZGET ioctl?

As far as I know, dm (device mapper) always uses 512-byte blocks for all its "blocks" which is probably what's going wrong here. If BLKSSZGET returns a 4k block size, then all the block numbers are probably adjusted to that and then passed to dm like that. However, dm would expect 512-byte blocks, so they are all off by a factor of 8.

I'll review the code to make sure that all the block offsets are stored based on the actual disk block size (4k in this case) [although I think this is already the case] and that all dm blocks are passed to dm as 512-byte blocks. Whenever I've done that I'll push an experimental branch for you to try this out - I don't have any 4k disk myself.

[bwalex]

It'd be helpful if you could confirm that tcplay's "info" works just fine (as in, shows something and accepts the passphrase) with a truecrypt volume created with a 4k block size.

[bwalex]

well, I haven't been able to find anything that actually tells me what the block size for dm itself and dm-crypt is. From the fact that it doesn't work, I suspect dm does indeed use 512-byte blocks, but I can't find any reference actually confirming that.

[bwalex]

Here we go, found the reference:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/device_mapper.html

" Sizes in the Device Mapper are always specified in sectors (512 bytes)."

[bwalex]

Well - please do let me know if that fixes it.

[devnullmail]

fixed. that was fast. tested against latest truecrypt for linux & windows. thanks.

(in answer to question above: BLKSSZGET reports 4096 for /dev/sda)