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
