search

ladar / sedutil

Use sedutil for setting up and using self encrypting drives (SEDs) that comply with the TCG OPAL 2.00 standard. This includes the requisite pre-boot authentication image.
https://trustedcomputinggroup.org/work-groups/storage/
80 stars 24 forks source link

Update Readme with S3 Sleep Setup #4

Open feiyax opened 5 years ago

feiyax commented 5 years ago

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 https://github.com/Drive-Trust-Alliance/sedutil/issues/90

Below are the steps i took after a fresh intall of Ubuntu 18.04.3.

  1. Edit /etc/default/grub to append libata.allow_tpm=1 to the end the line GRUB_CMDLINE_LINUX_DEFAULT= (may be only needed for SATA)

  2. Update grub.cfg by running # update-grub (may be only needed for SATA)

  3. Download the Linux binary from the release of this repo; extract and have it ready to run

  4. Reboot

  5. 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)

  6. Add systemd service for excuting # sedutil-cli -n -x --prepareForS3Sleep 0 Admin1 <password hash> /dev/nvme? Below is my /etc/systemd/system/seds3sleep.service

[Service]
Type=oneshot
ExecStart=/opt/sedutil-1.15.1-87/sedutil-cli -n -x --prepareForS3Sleep 0 Admin1 <my password hash> /dev/nvme?

[Install]
WantedBy=multi-user.target
  1. Enable this service. # systemctl enable seds3sleep.service && systemctl start seds3sleep.service
llunak commented 5 years ago

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. Also, libata.allow_tpm=1 is actually not necessary for NVME (as the name suggests, it should be needed only for SATA SSDs).

feiyax commented 5 years ago

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

ladar commented 4 years ago

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.

MathewCNichols commented 3 years ago

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!

youk commented 3 years ago

I understand this opens some doors for password interception, but I am willing to accept those risks for S3 sleep.

It opens all doors.

MathewCNichols commented 3 years ago

I understand this opens some doors for password interception, but I am willing to accept those risks for S3 sleep.

It opens all doors.

Can it be exploited from a powered off state? I'm trying to close that door right now.

youk commented 3 years ago

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.

feiyax commented 3 years ago

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. 

# *** hibernation side ***

[56455.822879] PM: hibernation entry
[56456.141418] Filesystems sync: 0.007 seconds
[56456.145751] Freezing user space processes ... (elapsed 0.001 seconds) done.
[56456.154561] OOM killer disabled.
[56456.158085] PM: Marking nosave pages: [mem 0x00000000-0x00000fff]
[56456.164246] PM: Marking nosave pages: [mem 0x00090000-0x00090fff]
[56456.170410] PM: Marking nosave pages: [mem 0x000a0000-0x000fffff]
[56456.176578] PM: Marking nosave pages: [mem 0x09cff000-0x09ffffff]
[56456.182731] PM: Marking nosave pages: [mem 0x0a200000-0x0a212fff]
[56456.188887] PM: Marking nosave pages: [mem 0x0b000000-0x0b01ffff]
[56456.195082] PM: Marking nosave pages: [mem 0x8e659000-0x8e659fff]
[56456.201266] PM: Marking nosave pages: [mem 0x8e678000-0x8e679fff]
[56456.207410] PM: Marking nosave pages: [mem 0x8e687000-0x8e687fff]
[56456.213585] PM: Marking nosave pages: [mem 0xc3496000-0xc3496fff]
[56456.219753] PM: Marking nosave pages: [mem 0xc6a47000-0xc6a8cfff]
[56456.225930] PM: Marking nosave pages: [mem 0xc6fa5000-0xc6fa5fff]
[56456.232079] PM: Marking nosave pages: [mem 0xca5ef000-0xcbbfefff]
[56456.238267] PM: Marking nosave pages: [mem 0xcd000000-0xffffffff]
[56456.244766] PM: Basic memory bitmaps created
[56456.249535] PM: Preallocating image memory... done (allocated 2426447 pages)
[56457.628978] PM: Allocated 9705788 kbytes in 1.37 seconds (7084.51 MB/s)
[56457.635644] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.

# omitted

[56463.593815] PM: Using 3 thread(s) for compression
[56463.920671] PM: Compressing and saving image data (2382011 pages)...
[56463.927666] PM: Image saving progress:   0%
[56464.820588] PM: Image saving progress:  10%
[56465.727719] PM: Image saving progress:  20%
[56466.621716] PM: Image saving progress:  30%
[56467.515424] PM: Image saving progress:  40%
[56468.422113] PM: Image saving progress:  50%
[56469.406140] PM: Image saving progress:  60%
[56470.407787] PM: Image saving progress:  70%
[56471.588171] PM: Image saving progress:  80%
[56472.724623] PM: Image saving progress:  90%
[56473.494671] PM: Image saving progress: 100%
[56473.499621] PM: Image saving done
[56473.503515] PM: Wrote 9528044 kbytes in 9.57 seconds (995.61 MB/s)

# *** restore side ***

[   13.270208] PM: Image signature found, resuming
[   13.274832] PM: resume from hibernation
[   13.280455] Freezing user space processes ... (elapsed 0.001 seconds) done.
[   13.288769] OOM killer disabled.
[   13.292065] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[   13.300883] PM: Marking nosave pages: [mem 0x00000000-0x00000fff]
[   13.307085] PM: Marking nosave pages: [mem 0x00090000-0x00090fff]
[   13.313265] PM: Marking nosave pages: [mem 0x000a0000-0x000fffff]
[   13.319472] PM: Marking nosave pages: [mem 0x09cff000-0x09ffffff]
[   13.325667] PM: Marking nosave pages: [mem 0x0a200000-0x0a212fff]
[   13.331869] PM: Marking nosave pages: [mem 0x0b000000-0x0b01ffff]
[   13.338032] PM: Marking nosave pages: [mem 0x8e659000-0x8e659fff]
[   13.344231] PM: Marking nosave pages: [mem 0x8e678000-0x8e679fff]
[   13.350405] PM: Marking nosave pages: [mem 0x8e687000-0x8e687fff]
[   13.356629] PM: Marking nosave pages: [mem 0xc3496000-0xc3496fff]
[   13.362888] PM: Marking nosave pages: [mem 0xc6a48000-0xc6a8dfff]
[   13.369080] PM: Marking nosave pages: [mem 0xc9295000-0xc9295fff]
[   13.375277] PM: Marking nosave pages: [mem 0xca5ef000-0xcbbfefff]
[   13.381490] PM: Marking nosave pages: [mem 0xcd000000-0xffffffff]
[   13.388026] PM: Basic memory bitmaps created
[   13.518933] PM: Using 3 thread(s) for decompression
[   13.523938] PM: Loading and decompressing image data (2382011 pages)...
[   13.545491] PM: Image loading progress:   0%
[   15.309390] PM: Image loading progress:  10%
[   16.195704] PM: Image loading progress:  20%
[   17.098225] PM: Image loading progress:  30%
[   17.997804] PM: Image loading progress:  40%
[   18.895022] PM: Image loading progress:  50%
[   19.787227] PM: Image loading progress:  60%
[   20.699837] PM: Image loading progress:  70%
[   21.610595] PM: Image loading progress:  80%
[   22.521664] PM: Image loading progress:  90%
[   23.361585] PM: Image loading progress: 100%
[   23.365992] PM: Image loading done
[   23.369469] PM: Read 9528044 kbytes in 9.83 seconds (969.28 MB/s)
[   23.376003] PM: Image successfully loaded
[   23.380096] printk: Suspending console(s) (use no_console_suspend to debug)
[56457.652633] r8169 0000:0a:00.0 enp10s0: Link is Down

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

youk commented 3 years ago

I disagree with hibernation being fast. The entering and restoring from hibernation are a lot slower than suspend-to-RAM on modern computers.

That only shows that desktop Linux sucks. Bad for you.

darkbasic commented 2 years ago

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.

youk commented 2 years ago

Hybernation has always been slow and will always be on every OS.

BS. It's very fast on modern SSDs. Dumping 32GB is a matter of a few seconds.

KVAnton-WEB commented 1 year ago

Tried to configure with User1 password (hash and user instead of Admin1), started getting (spam) error ata5.00: device reported invalid CHS sector 0 after resume after suspension, reconfigured with Admin1, so far everything seems to be fine (I will add if I notice any problems). Maybe it will be useful for someone..