Talk:Self-encrypting drives

From ArchWiki
Latest comment: 15 March by Indigo in topic UEFI boot problems on Asus H97M-E

MEK is not changed

I am not sure if this should really be listed under the disadvantages, but it should be made clear, IMO: the "2nd-level data encryption key" (as it is referred in the Key management chapter; MEK (media encryption key) or DEK (data encryption key) as it is mentioned elsewhere, e.g. in the Opal standard, I think) is not changed during the processes described on this page. So typically the factory default would be used. This is a security disadvantage, IMO. Am I right? XX (talk) 09:38, 8 October 2023 (UTC)Reply[reply]

I am going to move with out of this category, so I can close Disadvantages.
This will become its own thread. PolarianDev (talk) 11:01, 8 October 2023 (UTC)Reply[reply]
User:XX Feel free to suggest how to improve the article, instead of just asking.
This page does not seem that active as you can see, so I am not sure if you will get a response, I do not use encrypted disks because I do not like the overhead of it, so I can not help here...
Good luck and take care, PolarianDev (talk) 17:47, 9 October 2023 (UTC)Reply[reply]
It's a valid point and could be added to disadvantages in due course. A regeneration of said data encryption key inevitably needs a factory reset, i.e. totally wiping the device. While this does not mean, it is the same data encryption key, it is less flexible than luks, which can even reencrypt the whole device at runtime. --Indigo (talk) 21:18, 10 October 2023 (UTC)Reply[reply]
I've added [1] and [2] to cover it. closing. --Indigo (talk) 21:16, 15 March 2024 (UTC)Reply[reply]

Create a custom pre-boot authorization (PBA) image

Please add info (link?): how is it possible? I see `mklinuxpba-diskimg` in https://aur.archlinux.org/packages/sedutil/, but when I run it I get several errors ending with "the current kernel is not supported" (at least on Manjaro).

XX (talk) 11:18, 3 October 2023 (UTC)Reply[reply]

Just to note, Manjaro is not Arch, and the contribution guidelines state: "do not add comments peculiar to other Linux distributions or operating systems; for example, a Fedora user contributing to the systemd page would be fine, but mentioning that the newly added content works on Fedora would be edited out as irrelevant;". Any additional explanation is welcome but it should not be associated to troubleshooting problems related to a non-Arch OS. HenriqueBecker91 (talk) 13:51, 3 October 2023 (UTC)Reply[reply]

Download the rescue image (optional)

How is it optional? How can I create my own rescue image?

XX (talk) 11:18, 3 October 2023 (UTC)Reply[reply]

I agree that the text needs to be clearer on how is this optional, but I think it is not optional because you could create your own rescue image (of course this is always a possibility but I think this is not what was meant). But because you could be setting up a disk from another disk in the same machine, and if it has Arch, you can just install `sedutil` and use it to configure the other disk. HenriqueBecker91 (talk) 13:57, 3 October 2023 (UTC)Reply[reply]
It's optional because you can use sedutil-cli on any other system, not necessarily on the rescue image. There are also multiple forks providing various images with different features / updates. Nobodee (talk) 22:41, 3 October 2023 (UTC)Reply[reply]
So, as far as I understand it now, we need the following.
  • drive-A: this will be encrypted; must support SED / Opal
  • drive-B: must be bootable and contain sedutil-cli
  • a PBA image: it will be written from drive-B onto drive-A during the process
If DTA's rescue image is written onto drive-B, then it provides everything needed: it can be booted, has sedutil-cli and a PBA image as well.
But drive-B can be prepared in other ways as well. E.g. it can contain Arch or another Linux. Then the PBA and sedutil-cli can be downloaded from DTA. Or (on Arch) the sedutil AUR package can be installed: it contains sedutil-cli and tools to create a PBA. In such cases the rescue image of DTA is not needed at all.
My question: can drive-A and drive-B be the same? When drive-A is not encrypted yet, it can contain e.g. Arch with sedutil-cli and a PBA. Then all needed sedutil-cli commands can be issued from it without any error messages. Should it work? XX (talk) 20:54, 6 October 2023 (UTC)Reply[reply]
I haven't tried that, but the moment you try to change the master key (not the password you enter) or the locking ranges, it will cause the drive to be wiped. In theory, if you were just enabling the main locking range (0) and then changing the password it may work from the same system. However, this is not behaviour that should be relied upon. Nobodee (talk) 16:58, 15 October 2023 (UTC)Reply[reply]

Executing the steps from the rescue system

This is highlighted as a must. Please add info: why is it a must? This info could be useful for troubleshooting, when a Linux is already installed on the drive and can be booted somehow, but the process is still problematic and the SED settings need changes. Can they be changed from the booted Linux, using `sedutil-cli` on that Linux (on the same drive -- in this case the drive is unlocked)? Or: can I use `sedutil-cli` from another Linux (like normal Arch or Manjaro: not the rescue system), booted from another drive? What is needed on such a Linux? Shall the problematic drive be locked or unlocked when I issue `sedutil-cli` commands, especially `loadPBAimage` from another drive?

XX (talk) 11:18, 3 October 2023 (UTC)Reply[reply]

Yes you can, I think this needs to be made clearer. Last month I did configure all my SED disks by means of another linux installation in the same computer, I never booted from the rescue. HenriqueBecker91 (talk) 13:59, 3 October 2023 (UTC)Reply[reply]
The rescue system or another installation are equivalent. The rescue system itself is a very barebones image Nobodee (talk) 22:39, 3 October 2023 (UTC)Reply[reply]
Please see my question above. (Maybe this part can be deleted then.) As I see we have at least two options.
a) drive-A (to be encrypted) and drive-B (e.g. rescue system) are different -- this case is detailed currently on the main page
b) drive-A and drive-B are the same
Your answers make it not clear to me yet, if drive-A and drive-B can be the same or not. Please clarify.
Plus: is there any requirement to have drive-A locked or unlocked with mbrdone on or off etc. when the PBA is written to it? If drive-A and drive-B are the same, then it is obviously unlocked and (I think) mbrdone is on. Is it OK? This is relevant when the SED setup is done already but needs tweaking. XX (talk) 21:07, 6 October 2023 (UTC)Reply[reply]

Misc update proposals

  • The 1.15 version of sedutil uses a differently named option and the behavior probably changed too:
   # sedutil-cli --setSIDPassword oldpassword newpassword device

now also sets the admin1Pwd, so it is not necessary to execute. The user should at least be informed about this.

  • The links to the PBA image is broken and the ones that work point to broken builds.

Libgxps (talk) 23:10, 24 January 2018 (UTC)Reply[reply]

Right. I've changed it with Special:diff/798868. The PBA image link was already updated long ago with Special:diff/518376. Closing. --Indigo (talk) 20:48, 29 January 2024 (UTC)Reply[reply]

Suspend doesn't work properly

Suspend locks the drive (Dell E6410 + Samsung EVO 850) and drive is not accessible after wake up. One solution is to disable Suspend - see https://wiki.archlinux.org/index.php/Polkit#Disable_suspend_and_hibernate

Is possible to unlock drive after wake up? -> A fork to sedutil-cli is available that allows providing the password *BEFORE* sleeping such that the system can resume: https://aur.archlinux.org/packages/sedutil-sleep-git/ Germafab (talk) 12:39, 10 May 2020 (UTC)Reply[reply]

UEFI boot problems on Asus H97M-E

Unfortunately, OPAL breaks Linux UEFI boot on my Asus motherboard. I use a dualboot configuration. As I understand it, during the initial boot, when the firmware sees an "empty" SSD it removes all UEFI boot entries. When it gets rebooted after entering the encryption password in the PBA, the firmware notices the EFI boot partition and automatically inserts a single new boot entry (of course, only the Windows one). I have only tested it on Asus H97M-E, but I wouldn't be surprised to see this behaviour at least on other Asus motherboards.

Maybe the possibility of firmware bugs of this kind should be mentioned in the "disadvantages" section?

Catnip (talk) 14:40, 9 March 2020 (UTC)Reply[reply]

I see something similar as a consequence of the issue explained in "Troubleshooting: PBA Cold Reboot Locks Drives Again": after unlocking the drive, if I manage to break the cold reboot (by hitting F2 at the right moment) and do a warm reboot instead, I see the unlocked drive in UEFI, but its boot entry doesn't work. My workaround is choosing "Boot From File" in UEFI and select the proper grubx64.efi. Then normal boot is possible. But this has to be done for each boot. -- XX (talk) 11:18, 3 October 2023 (UTC)Reply[reply]
I've added [3]. Ideally, we could add example references of such firmware behaviour (bug report, BBS topic). Please add one, if you come across it (must not be yours, but conclusive for a firmware). --Indigo (talk) 21:22, 15 March 2024 (UTC)Reply[reply]

Troubleshooting: PBA Cold Reboot Locks Drives Again

I have the same issue, but couldn't fix it with the description given here. Please add more details.

  • I assume the commands (from `losetup --find` to `loadPBAimage`) should be done in the rescue system. Please confirm / make it explicit on the page. In the rescue system I get error messages from `losetup`. First, it does not know `--find` (I can use `-f` instead) and `--show`. Then, even if I use `losetup -f ./UEFI64-*.img` it states there is no UEFI img. Even if `ls` shows it. In the rescue system I am root. How to overcome this issue?
  • My workaround is the following. After unlocking the drive, if I manage to break the cold reboot (by hitting F2 at the right moment) and do a warm reboot instead, I see the unlocked drive in UEFI, but its boot entry doesn't work. Choosing "Boot From File" in UEFI and selecting the proper grubx64.efi enables a normal boot. Unfortunately this has to be done for each boot. -- Anyway, it may be useful to add this workaround to the troubleshooting chapter.

XX (talk) 11:18, 3 October 2023 (UTC)Reply[reply]

I did the full configuration from another linux installation in the same PC, so I never have used the rescue image. The workaround comes from the github issue I linked in the start of the section. If you are using a recent Arch distro then `--find` and `--show` should work. Were you in the same folder the UEFI file was? Do the file name matches `UEFI64-*.img` or it is just `UEFI64.img` (and therefore the `UEFI64-*.img` will not match it). HenriqueBecker91 (talk) 14:10, 3 October 2023 (UTC)Reply[reply]
I used the rescue image. After some more trials I would say that the procedure to fix the issue, as it is written on the main page now, can not be done from (the current version of) the DTA rescue image. This should be made clear on the main page, IMO.
  • The DTA rescue image I used is RESCUE64, v1.20.0.
  • It is a BusyBox v1.26.2 (2021-08-18)
  • It does not have partprobe!
  • Its losetup works differently as written in the fixing procedure:
    • --find and --show are not known
    • -f can be used instead
    • But `losetup -f ./UEFI64-1.20.0.img` returns "No such file or directory", even if the file is there, can be listed by e.g. `ls -al ./UEFI64-1.20.0.img`. So I tried another way to mount the .img: `mount ./UEFI64-1.20.0.img /mnt` (or `mount -o offset=1048576 ./UEFI64-1.20.0.img /mnt`) returns "Invalid argument", but after this `losetup -f ./UEFI64-1.20.0.img` works! (Unfortunately I couldn't continue the process because partprobe is "not found".)
XX (talk) 21:37, 6 October 2023 (UTC)Reply[reply]

Troubleshooting: Reset System causes a Cold Reboot, which Locks Drives Again

I applied the procedure described in "Troubleshooting: PBA Cold Reboot Locks Drives Again" (not from the rescue image, but from another Linux), but it didn't help. During the process I realized that the following happens:

  1. after switching on the laptop, it boots the PBA (as expected)
  2. the PBA asks for the SED password and unlocks the drive (as expected)
  3. the PBA triggers a reboot (I think) (as expected)
  4. during(?) the (warm) reboot "Reset System" appears for a very short time (100ms?)
  5. cold reboot happens

I think 5 is the consequence of 4. As I saw on the internet Reset System typically comes from Secure Boot. In my UEFI Secure Boot is disabled.

Any ideas? XX (talk) 22:01, 6 October 2023 (UTC)Reply[reply]

Article should be clearer early on about the negatives

It's unfortunate that there's barely any information on SED/OPAL online. Given that resume from sleep doesn't work, I suspect many notebook users will not want to go this route at all. While it's commendable that the article attempts to show the (hacky) ways of getting OPAL to work, I think there should an early notification about the flaky nature of current solutions, so users can make an informed choice.

Having a cautionary message above every section is not the answer. I'd rather the article be rewritten from scratch based on the current state of information. Adrian5 (talk) 22:00, 25 February 2021 (UTC)Reply[reply]

According to my experience resume from sleep works. Resume from suspend may not work. -- XX (talk) 11:18, 3 October 2023 (UTC)Reply[reply]

Comparison of the different setup methods (PBA vs mkinitcpio)

It would be great to have a chapter about the (dis)advantages of the two methods already described on the page. E.g.

  • Advantages of the PBA method against the mkinitcpio method
    • Being "more standard", independent from the OS
  • Advantages of the mkinitcpio method against the PBA method
    • not requiring reboot --> faster boot
    • not requiring reboot --> rule out the problem described in "Troubleshooting: PBA Cold Reboot Locks Drives Again"
  • Other differences (not necessarily pros or cons)
    • PBA encrypts the "whole" drive (except its "PBA area", of course) (including /boot)
    • mkinitcpio requires unencrypted /boot

XX (talk) 10:04, 8 October 2023 (UTC)Reply[reply]

Changing MEK

Can we add some info about how to change MEK / DEK (=media / data encryption key)? As far as I understand none of the processes on this page changes it. If it would be changed, then everything would be "deleted" (lost, because encrypted with the previous, not-known-anymore(?) MEK) from the drive. XX (talk) 09:48, 8 October 2023 (UTC)Reply[reply]

cryptsetup support for OPAL

Heads-up: If all goes well, the upcoming cryptsetup 2.7.0 gains OPAL support. While it won't be suitable for pre-boot authentification (whole drive encryption), it will make the hardware features much easier to deploy for individual devices. See the release candidate Notes. As a first thought how to integrate the new support, the Self-encrypting drives#Encrypting a non-root drive could be applicable for an initial example once the release lands.? -- Indigo (talk) 23:10, 12 December 2023 (UTC)Reply[reply]

I am so looking forward to this, it was merged 5 months ago. Pottering on how this would fix OPAL and SecureBoot - https://github.com/systemd/systemd/issues/16089#issuecomment-1681980103 What is bash? (talk) 05:04, 25 December 2023 (UTC)Reply[reply]
I did a first test with with a sata ssd. This now triggers a pre-boot pw on uefi and when I plug it into a legacy bios (no tcg support, hence no pre-boot pw), it opens opal with the luks device or also a luks header for opal-only (yay). Performance does not seem to differ with opal-only or opal+luks, could be the drive maxes sata in both cases. What did not work yet was (1) luksFormat on the legacy bios, and a nvme on uefi, (2) a FIDO2 cryptenroll on the opal-only device. --Indigo (talk) 16:20, 14 January 2024 (UTC)Reply[reply]
With cryptsetup 2.7.0-1 now in the repo, a luksFormat on legacy bios and a FIDO2 cryptenroll on the opal-only device was now possible. --Indigo (talk) 21:08, 28 January 2024 (UTC)Reply[reply]
Is it possible for you to add some examples to the wiki? What is bash? (talk) 21:02, 2 February 2024 (UTC)Reply[reply]
Yes, I've collected example output for Special:diff/799562 and will add first paras soon. --Indigo (talk) 16:27, 4 February 2024 (UTC)Reply[reply]
I've added initial examples. Welcome to add to it. I have not tried crypttab/resume yet and will add that if no-one is faster. If it works as expected, it should be enough to crosslink dm-crypt/suspend sections. --Indigo (talk) 19:26, 4 February 2024 (UTC)Reply[reply]