Installing on a self-encrypting (OPAL) drive

Hello everyone and happy holidays! I plan on installing CachyOS on an SSD with OPAL2 support and would like some guidance on what’s the best way to go about it. Please note that I’m specifically interested in OPAL-only encryption - I’m aware that it’s theoretically not as secure as having an additional layer of LUKS’ own encryption, but for my threat model the speed increase is worth it.
Apparently, there are currently two ways to go about it:

Using LUKS/cryptsetup

In this scenario the boot partition is left unencrypted and LUKS is utilized like it would be for non-OPAL drive. From my understanding, this has the following advantages and disadvantages:

  • + Secure boot more likely to work
  • - Boot partition left unencrypted
  • - CachyOS will have to be installed on a different drive and then moved as it doesn’t support setting up OPAL-only encryption or installing into an existing LUKS partition

I’m also not completely certain how should I set up swap partition in this scenario - make a second LUKS partition? Make a partition table on the LUKS partition? I’d rather avoid overhead of LVM.

Using pre-boot authorization via sedutil

In this case unlocking is handled using a special image that’s loaded before everything else. From my understanding, this has the following advantages and disadvantages:

  • + No special partitioning needed, drive appears completely plain to OS, can be directly installed onto
  • + Boot partition encrypted
  • - Slower boot times with PBA having to do a reset
  • - (S3) sleep issues - apparently not relevant to me as I’m only using s2idle
  • - Secure boot apparently less likely to work (then again, why care if everything is encrypted?)
  • - sedutil seems to be unmaintained, might have to build PBA image myself

Have I missed anything significant here? Which way would you recommend to go with? Thanks!

Alright, so I went the whole drive encryption with pre-boot authorization way, and it turned out to be… quite an adventure.

  • Current version of sedutil-cli has a bug in command line argument parsing that breaks the --loadPBAimage command, so I had to patch that. Repeatedly, as I used cachy’s live stick to do the setup and needed to reboot a couple of times.
  • Then I had to build a custom PBA image because of a known bug in old kernels causing keyboard inputs not to be recognized. Thankfully, arch package includes a script for it, so after adding cachy’s kernel support to it everything went fairly smoothly.
  • As it turns out, s0ix sleep on my device nonetheless powers the disk down, causing it to lock and system to freak out after resuming. Unless there’s a setting in bios for changing that, guess I’ll be living without sleep mode. Oh well, boot is really fast anyways and s0ix sleep wasn’t especially good at conserving power in the first place… It’s worth noting that there are solutions for this, but they aren’t applicable for system drive encryption - at which point LUKS --hw-opal-only will probably serve you better.
  • Haven’t tried setting up secure boot, so don’t know how that would go; would probably need to sign the PBA kernel as well, so that’s bonus fun.

Overall, I think I’m satisfied with the result despite the caveats.