Sleep support

[lulkipvx]

Are there any plans for sedutil to support HDD sleep? This is the single most feature that has got me disabling sedutil currently.

[adrian5]

@Venemo I ended up not pursuing this further and went with software encryption. If I ever try again and succeed, I'll post here.

[tarruda]

Some interesting articles regarding this subject

• https://blog.cloudflare.com/speeding-up-linux-disk-encryption/
• https://www.zdnet.com/article/flaws-in-self-encrypting-ssds-let-attackers-bypass-disk-encryption/

Bitlocker now defaults to using software encryption regardless of the hardware. This is due to discovered vulnerabilities in SED implementations, and even samsung seems to recommend against relying on the native encryption for non-portable SSDs: https://semiconductor.samsung.com/consumer-storage/support/notice/

It seems LUKS might be the way to go for full disk encryption, especially in newer Linux versions (5.9+) where dm-crypt was optimized and performance impact is lower.

[onnonym]

@fornellas: Could you make a more extensive guide for your method, especially on how to modify the initrd? Do the manual changes survive OS updates?

And would something like this work to avoid storing the password in RAM? sedutil-cli --setlockingrange 1 rw $PASS $DEVICE HASH=$(sedutil-cli --printPasswordHash $PASS $DEVICE) sedutil-cli --prepareForS3Sleep 1 $HASH $DEVICE

[fornellas]

@onnonym pplease check https://github.com/fornellas/tcg_opal_rootfs

[matthewlenz]

https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/461 ... since this is the most commented bug I though you guys might want to see this.

[darkbasic]

since this is the most commented bug I though you guys might want to see this

How does it help with the sleep issue?

[xBelladonna]

It seems this will help the sleep issue the same way LUKS currently helps the sleep issue with its own dm-crypt stack by caching the hashed passphrase in memory. Basically, guys I actually trust have merged support for OPAL into the well-known cryptsetup library and once the changes propagate down to distros we all use, we don't have to rely on the unmaintained sedutil, it'll all just work like another type of LUKS backend.

This is great news but still means probably 2 years until it's available in Debian, so I'll stick with LUKS for now, but I'll be watching.

[darkbasic]

I still don't see how this is going to help: I don't decrypt the drive using luks open (I might use it if I ever need to attach the HDD to another PC to recover the data), instead I run the decrypting bootloader from the HDD which gets served whenever it's locked.

[xBelladonna]

Exactly, by introducing security hole. It is simply impossible to do so otherwise. @darkbasic, LUKS can be used in the initramfs to decrypt at boot time, even in an EFI image, which is what I do on my servers; everything except the EFI partition is encrypted at rest with LUKS and I unlock remotely using SSH that runs in the initramfs stage. This will help if you are using a Linux-based OS. If not, it will be irrelevant to you.

[darkbasic]

@xBelladonna and where do you plan to put your EFI partition with the initramfs? With SED encryption is all or nothing, so unless you have a spare HDD just for the EFI you're out of luck.

[darkbasic]

Ever heard of locking ranges?

Nope, but thanks for pointing it out.

[darkbasic]

New laptop and you seriously tempted me to attempt the TPM + SED + cryptsetup route, but it looks like cryptsetup-git is still needed (the aforementioned PR didn't land in a stable release yet) plus I'm not even sure if the LUKS2 header has changed to accomodate OPAL support and thus if grub2 is still capable of unlocking it. This time I'll pass in favour of zfs native encryption, but I will watch out for someone brave enough to attempt this.

[darkbasic]

Nothing except making the use of an additional layer of encryption feasible: I already use zfs encryption and I'd like to experiment with the new cryptsetup OPAL support but I definitely don't want to bother with another passphrase.

[darkbasic]

You said that I can encrypt single partitions using SED via locking ranges, which I wasn't aware of. I want to use that to encrypt my Arch Linux root partition via SED, but since my rootfs already uses zfs and I already have zfs native encryption enabled I don't want to have to type an additional passphrase for SED. I want to use cryptsetup + OPAL to manage the SED encryption and I want to store the passphrase in the TPM to avoid having to manually type it: cryptsetup is already supported by systemd's sd-encrypt initramfs hook and it can use the TPM via the tpm2-device option. Unfortunately I'm not sure if grub2 is capable of interfacing with the TPM for the decryption or if it is compatible with cryptsetup-OPAL at all, so I might have to put the boot partition on a separate unencrypted partition (not a big deal with secureboot but annoying enough with an existing partitioning scheme).

[desgua]

Can someone confirm if @badicsalex fork still works on newer kernels?

/opt/sedutil-cli -n -x --prepareForS3Sleep 0 <hash> /dev/sda works well on Debian Stable 12 from linux-image-6.1.0-9-amd64 to linux-image-6.1.0-13-amd64 but since linux-image-6.1.0-14-amd64 (up to linux-image-6.1.0-18-amd64) it seems to doesn't work anymore (the system goes to sleep and most of the time it never wakes up again. Sometimes it wakes up, but the disk is unreadable).

bug reports: 1058028 1058052 1058890 Debian forum: 793323

[badicsalex]

@desgua I'm running on 6.6.7-arch1-1 right now, and it's working fine.

[desgua]

Is there any specific module to compile when compiling Linux kernel to allow S3 to work? I compiled the kernel 6.1.76 from Debian sources without applying any patch and it can't wake up from suspend :-(

[desgua]

@badicsalex I'm suspecting some patch from ~November 2023 was back ported to all stable kernels preventing the waking up to be successful. Have you tried the kernel 6.6.18?

[badicsalex]

@desgua Not yet, but now I'm afraid to pacman -Syu 😅

[desgua]

cryptsetup now support --hw-opal-only (for Linux kernel > 6.4). Has anyone tested if the system can wake up from suspend with it?

[Asteriod1]

With an Nvme-SSD suspend to ram is working for me on archlinux with kernels 5.10.209-1-lts510, 6.6.17-1-lts, and 6.7.5-arch1-1. With Sata-SSDs suspend to ram is working only with kernel 5.10.209 of the above. So the problem seems to be related to the libata.allow_tpm=1 kernel boot parameter, which is required only for Sata drives. Something in the newer kernels concerning libata.allow_tpm seems to have changed. Or perhaps a race condition ?

[desgua]

@Asteriod1 that makes sense. My notebook is old and I have to use Sata-SSD with libata.allow_tpm=1

[desgua]

I submitted a bug to Linux Kernel Bugzilla: 218538. It seems very similiar to an old, already fixed bug 211227.

[desgua]

Update: The new linux kernel 6.1.80 is out and the bug on SATA is still present :-( A bisect is needed to pinpoint the problematic patch. I'm not being able to do it RN because my notebook gets too hot and shuts down. If anyone can and want to do the bisect, the bugzilla report is here: 218538.

[darkbasic]

my notebook gets too hot and shuts down

Open it and blow the dust from the fan. If it's still overheating try changing the thermal paste: clean it with isopropyl alcohol and apply a new one.

[desgua]

@darkbasic Thank you so much <3 I've dust the fan and changed the thermal paste about 3 months ago, and I really got a lot of improvement (the notebook use to shutdown on daily tasks like watching YouTube or opening LibreOffice, which never happened again), but compiling isn't easy for this 2011 machine :-/

[darkbasic]

@desgua you can also reduce the number of concurrent threads used for compilation (-j 1) to reduce the heat. ccache will help you to make the bisect fast despite lowering the number of threads used.

[desgua]

@darkbasic I use -j1 but at the end there is some final step (I think it is when building the deb-pkg) that the cpu (and fan) goes crazy and (sometimes) overheat. Do you know what is it and how to workaround it? (the command I use after configuring is "make -j1 deb-pkg").

[gohrner]

@desgua: You could try htop or pstree when it starts doing it to capture what's going on.

[desgua]

@gohrner Thank you so much! I will do that.

[darkbasic]

It's probably the package compression step which can be heavy if multithreaded, but you'll need htop to verify. If that's the case I'm sure there must be an option to skip compression or tune the number of threads. You can also use cpufreq or similar to set an upper frequency limit, which would reduce the power usage.

[desgua]

I managed to bisect and updated the bug report. Thank you so much for everyone! And thanks to gitpod.io for their servers that helped with the buildings.

[desgua]

Great news, Damien is looking into the problem and a patch is on its way to the next kernel.

[desgua]

Fixed upstream (6.1.85, 6.9) and on Debian (6.1.0-20).