Re: Mounting a device with messed up integrity header

[Milan Broz <gmazyland@gmail.com>]

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