Re: Interaction between OPAL drives, LUKS and TRIM/discard

[Milan Broz <gmazyland@gmail.com>]

Hi,

On 7/5/24 3:34 PM, neitsab wrote:
> I have been trying out the new OPAL support on the root drive for a new
> Arch Linux install (using a Samsung 980 Pro and --hw-opal-only): to my
> surprise it worked flawlessly and I could boot from my OPAL-encrypted,
> LUKS-managed SED. I really wanted to thank you for adding this support
> to cryptsetup: it's a whole world of improved usability and integration
> compared with sedutils.
> 
> After the fact I wanted to add discard support to my LUKS container so I
> ran:
> 
> ```
> cryptsetup refresh --allow-discards --persistent /dev/nvme0n1p2 root

(There should be only name (test) not device. Open takes the device param.)

> Enter passphrase for /dev/nvme0n1p2:
> Unsupported parameters on device root.
> ```

If you use --hw-only, there is no sw encryption layer (only a dm linear
mapping to isolate locking range) and so discard are not blocked.

IOW with sw+hw encryption (--hw-opal) it works as normal LUKS2 device
(discards need to be enabled), with hw OPAL only (--hw-opal-only) there
is no way to disable discards.

You can always check which device in storage stack blocks/allows discards
with lsblk, for example here it is with discards enabled (--hw-opal):

# lsblk -D /dev/nvme0n1
NAME    DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
nvme0n1        0      512B       2T         0
└─test         0      512B       2T         0

This is with discards blocked on dm-crypt device (discard max size -> 0)

# lsblk -D /dev/nvme0n1
NAME    DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
nvme0n1        0      512B       2T         0
└─test         0      512B       0B         0


...

> This made me wonder about the interaction between hardware-only OPAL,
> LUKS and TRIM/discard. In the hardware-only OPAL encrypted case, I guess
> there are no barriers to discards being sent to the drive. Is that why
> --allow-discards is an "unsupported parameter" and fstrim works by default?

yes, but it is a little but confusing. maybe a better error description
would help too.

> If so, do you think it's something that could be added to the docs, a
> bit like there is a warning about incompatibility with --tcrypt-hidden
> so as to warn users there is no need to try that?

yes, we should add some note to documentation, you can create an issue
for the cryptsetup project, if you want.


Thanks,
Milan