[arch-general] Hibernation Failure

[Markus Schaaf]

Am 12.01.20 um 12:19 schrieb Markus Schaaf via arch-general:
> 
> 
> Am 12.01.20 um 01:39 schrieb Paul Dann via arch-general:
>> I'm having trouble getting hibernation to work on my new Dell Inspiron
>> 7590. It seems that the image is stored correctly (onto LUKS+LVM thin-lv),
> 
> I've noticed something similar on a similar setup. It looks like the
> kernel is taking some shortcuts when accessing the (swap-) space during
> hibernation, which are not compatible with dm-crypt. I'm using an AEAD
> cipher and the integrity data is wrong after resume.

I know it is terribly late, but for those curious:

While investigating this I managed to make my laptop unbootable, because
dm-crypt decided that every single sector on my encrypted partition had
a bad AEAD tag and wouldn't let me read a single byte. That was exactly
what had been happening to my swap-partition before, when I tried to
resume from hibernation. But this time it had eaten my root-partition
too. Of course I had backups, encrypted (of course), with a key I had
changed recently ... that I knew I needed to save somewhere else, but
somehow forgot to.

I'm writing this on exactly that laptop, restored completely from the
"unreadable" SSD. But it took me some time to read the relevant kernel
code, develop and run some helpful tools to search and decrypt the data
on said partition.

What I have found: It is unlikely that hibernation is the cause to the
problem I have encountered. It is just the trigger. Somehow dm-integrity
or dm-crypt manages to fuck up it's on-disk meta-data. (Meanwhile the
same happened to my work desktop, which had a similar setup, after
suspend to RAM.) After I had determined the exact encryption algorithm
and layout of my data, I was able to not only read all of it, but the
on-disk integrity-tags matched 100%. Every single sector.

BR