Update Readme with S3 Sleep Setup #4
Comments
|
Does it really work for you if you just use e.g. /dev/nvme0? I get "Error saving the password to the kernel errno = 25" and I have to use /dev/nvme0n1 to get it to work. |
|
I do have to specify the namespace for nvme. Like you said, /dev/nvme0n1 As for libata.allow_tpm, good to know that it's sata only |
|
This is a great tutorial. I think a little cleanup, and it can be incorporated into the README.md file. I only have two concerns. The first, is I recall that a specific kernel module is required for sleep support. I don't recall what it is, but I think, at least when I did my research awhile back, RHEL kernel images didn't support the required module, so additional steps were required beyond simply modifying the parameters supplied by GRUB to the kernel during boot. And I didn't want to add anything to the documentation that was specific to a particular distro, because it would only lead to users complaining about why it doesn't work for them. The second issue involves my concerns with the way sleep works now. Namely it requires saving the encryption key on disk (for it to work automatically), and/or in kernel memory. Typing the password every time eliminates the issue of having it stored on disk, but it means the password could be intercepted. Either way, it becomes possible for malware on a system to steal key for your device, and thus enabling sleep defeats one of the major benefits to using hardware disk encryption. Namely that it's impossible for malware to steal your disk encryption password. With OPAL 1.0... the BIOS intercepts a wake up request and collects the password and unlocks the drive, creating a secure process, similar to what is used during a normal system start. I don't think anything like this is even possible with OPAL 2.0, which I find to be very disturbing. Of course if I'm wrong please let me know. I've toyed with some alternatives, like having the PBA generate a key which can only be used for a single boot session, but such a solution would be incredibly trick to implement, and still isn't perfect. All of that said, I'd welcome a pull request which adds the steps above to the README file, provided you add a discussion of the caveats I mentioned. Like how to see if your kernel supports this function, and what the security implications are. |
|
I was able to follow @feiyeung's tutorial and successfully get S3 sleep working in Ubuntu 20.04 using @ladar's 1.16.0 SHA1 RESCUE image with SHA1 binaries from 1.15.1-87 ! Thank you! FYI, I run dual boot and was able to get sleep working in Windows 10 with @lukefor's SEDSleep too! I understand this opens some doors for password interception, but I am willing to accept those risks for S3 sleep. You all are awesome! |
It opens all doors. |
Can it be exploited from a powered off state? I'm trying to close that door right now. |
No, assuming the implementation wipes the stored password hash after it's no longer needed. Honestly, I did not check how this is implemented. The whole thing is an information security joke. Use hibernation (or what you have in Linux) instead, it's very fast with modern SSDs. |
I disagree with hibernation being fast. The entering and restoring from hibernation are a lot slower than suspend-to-RAM on modern computers. Below are the serial logs i have with my desktop suspending and resuming. The machine has a Ryzen 3950X CPU, 32GB of RAM, and a PCIe 4.0 x4 SSD (whose throughput exceeding 4 GB/s). Yet, the hibernation took 17 seconds from allocating suspend image space to finish writing the suspend image into swap. The restore side took over 23 seconds; 13 seconds between kernel initially up to the beginning of reading suspend image; another ~10 sec for reading and extracting suspend image. Side note 1, the magic number of 3 for compressing/decompressing is hard coded in the krenel source. I can probably experiment with bumping that, but it wont' help with the noticeable timespan outside of (de)compression.) Side note 2, there have been comments on it being already unsafe to use unsigned suspend image, which is why the hibernation is disabled with kernel lockdown / secure boot since 5.4 |
That only shows that desktop Linux sucks. Bad for you. |
|
How long did you expect dumping 32GB of ram should have taken? Hybernation has always been slow and will always be on every OS. What are the security implications of this? If I understand correctly it doesn't prompt for the encryption password, it adds a new key which gets removed once you exit S3. That doesn't sound like a big security hole, because your main key is safe and during S3 your data is as safe as it was while the computer was not sleeping. |
BS. It's very fast on modern SSDs. Dumping 32GB is a matter of a few seconds. |
|
Tried to configure with User1 password (hash and user instead of Admin1), started getting (spam) error |
I think the readme can also include how to set up S3 sleep support for Linux kernel >= 4.13. It could save some people from crawling through Drive-Trust-Alliance/sedutil#90
Below are the steps i took after a fresh intall of Ubuntu 18.04.3.
Edit
/etc/default/grubto appendlibata.allow_tpm=1to the end the lineGRUB_CMDLINE_LINUX_DEFAULT=(may be only needed for SATA)Update grub.cfg by running
# update-grub(may be only needed for SATA)Download the Linux binary from the release of this repo; extract and have it ready to run
Reboot
Find your encryption key by
# sedutil-cli --printPasswordHash <password> /dev/nvme?(namespace needs to be included for NVMe, e.g./dev/nvme0n1; same for the following)Add systemd service for excuting
# sedutil-cli -n -x --prepareForS3Sleep 0 Admin1 <password hash> /dev/nvme?Below is my/etc/systemd/system/seds3sleep.service# systemctl enable seds3sleep.service && systemctl start seds3sleep.serviceThe text was updated successfully, but these errors were encountered: