Mounting a device with messed up integrity header

Mounting a device with messed up integrity header

[generalmanager]

Hi everyone,

I'm trying to mount a partition which was created with "--integrity 
aead" when the integrity feature was brand-spanking new.

Unfortunately integritysetup doesn't recognize the integrity header anymore.
I can unlock the volume with

cryptsetup luksOpen /dev/sdb1/data_crypt

which creates the (symlinks to) devices containing the data and 
integrity information respectively:

/dev/mapper/data_crypt (containing an ext4 file system)
/dev/mapper/data_cryptdata_crypt_dif

but because the integrity check fails, I get I/O errors when trying to 
mount or fsck the corresponding /dev/mapper/data_crypt device.
I assume this is because of issues with the integrity check as described 
in https://gitlab.com/cryptsetup/cryptsetup/-/issues/490#note_227927246.

cryptsetup luksDump /dev/sdb1
correctly reports the integrity mode to be aead:

LUKS header information
Version:        2
Epoch:          5
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           XXXX-XXXX-XXXX-XXXXX-XXXXXXXXXXX
Label:          DATA_crypt
Subsystem:      (no subsystem)
Flags:        (no flags)

Data segments:
   0: crypt
  offset: 16777216 [bytes]
  length: (whole device)
  cipher: morus1280-random
  sector: 4096 [bytes]
  integrity: aead


As I wrote in the beginning, the output of

integritysetup dump /dev/sdb1
is:
No integrity superblock detected on /dev/sdb1.

Which means that

integritysetup open --integrity-recovery-mode /dev/sdb1 data_crypt 
data_crypt

fails with the same error, just as using --integrity-recalculate does.

I'm looking for the correct way to proceed. I don't care if it's by 
recalculating/recreating the integrity header & data, by disabling 
integrity checking temporarily or permanently or my modifying the header 
and stripping the integrity part.

Unfortunately I couldn't find a good writeup online or information in 
the faq regarding the best way to go forward in such a case.
I also searched the mailing list, but it's either well hidden or I 
didn't choose the right search terms.

If more verbose debugging output or the full original command with which 
the partition was encrypted would be helpful, I'll gladly provide them.

Thanks in advance for any hints!
Tom

Re: Mounting a device with messed up integrity header

[Milan Broz]

Hi,

On 2/1/23 03:38, generalmanager@mailbox.org wrote:
> Hi everyone,
> 
> I'm trying to mount a partition which was created with "--integrity
> aead" when the integrity feature was brand-spanking new.
> 
> Unfortunately integritysetup doesn't recognize the integrity header anymore.
> I can unlock the volume with
> 
> cryptsetup luksOpen /dev/sdb1/data_crypt
> 
> which creates the (symlinks to) devices containing the data and
> integrity information respectively:
> 
> /dev/mapper/data_crypt (containing an ext4 file system)
> /dev/mapper/data_cryptdata_crypt_dif

Kernel will not activate dm-integrity device if the header is not
available. What is in the kernel log?

Also full cryptsetup --debug log is needed here - could you paste it somewhere?
(Better not spam the list, just send link to the log on pastebin or so.)

...
> Data segments:
>     0: crypt
>    offset: 16777216 [bytes]
>    length: (whole device)
>    cipher: morus1280-random

MORUS cipher was removed from the kernel long time ago
(as they did not want to support it).
See https://lore.kernel.org/dm-crypt/6cfcaab8-70c4-5f78-2483-ca53ce89ef8f@gmail.com/

So either you have very old kernel, or something should scream that crypto cannot be initialized...

> As I wrote in the beginning, the output of
> 
> integritysetup dump /dev/sdb1
> is:
> No integrity superblock detected on /dev/sdb1.

This is not integrity standalone device, do no try to use integritysetup,
It will not work (even if you use the proper embedded integrity header,
you will not able to activate it as used AEAD cipher is processed in dm-crypt.

> 
> Which means that
> 
> integritysetup open --integrity-recovery-mode /dev/sdb1 data_crypt
> data_crypt
> 
> fails with the same error, just as using --integrity-recalculate does.

These options cannot bu supported with LUKS2. (With some exceptions
that requires manual table load.)


Milan