[pkg-cryptsetup-devel] Bug#949336: Mapped integrity devices of size ≥2TiB are unusable on 32-bits platforms

[nbf at waifu.club]

Hi,

> I won't be able to help debugging this as I don't have a >2TiB disk
> around.  (Could fake the size and format with --no-wipe, but ...

I recall integrity checks failing on all sectors. It should be enough
to format only a part of the device with 32-bit 2:2.0.

e.g.
prepare# head -c 4096 /dev/urandom >/IDISK.ikey
2:2.0.x# integritysetup --sector-size 4096 --tag-size 32 --integrity 
hmac-sha256 --integrity-key-size=4096 --integrity-key-file=/IDISK.ikey 
format /dev/sda
2:2.0.x# ^C after a gigabyte
2:2.2.2# integritysetup --integrity hmac-sha256 
--integrity-key-size=4096 --integrity-key-file=/IDISK.ikey open /dev/sda 
IDISK



> I definitely need a clear reproducer (with the latest stable
> - 2.2.2 or 2.3.0-rc0) - ideally with attached debug and system log.

I don't have that system at hand, but I am sure it was running on latest 
stock linux-image-armmp from testing.

I upgraded/downgraded between 2:2.2.2-1 and some old 2:2.0.x multiple
times to try rule out the kernel version.
The result was always the same. When I use 2:2.2.2-1, the disk seems to
return only checksum errors. When I use 2:2.0.x, it works as expected.

How do I add testing's 2:2.2.2-1 to affected versions?
Something like "Control: found -1 2:2.2.2-1"?



Any idea how is dm-integrity supposed to interact with truncation?
Does device size or device blocksize affect checksum layout?
If the underlying device is truncated, should checksums of remaining 
sectors stay valid?
If the mapped length gets truncated like in #935702, should checksums of 
available sectors stay valid?




Best,
n.b.f.