Interaction between OPAL drives, LUKS and TRIM/discard

Interaction between OPAL drives, LUKS and TRIM/discard

[neitsab]

Hi *,

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
Enter passphrase for /dev/nvme0n1p2:
Unsupported parameters on device root.
```

(I can provide the debug output if you tell me whether to send it in the 
body of a reply, as an attachment or on a paste service)

However, fstrim seemed to be working before that:

```
fstrim -v -a
/boot/efi : 424,3 MiB (444919808 bytes) trimmed on /dev/nvme0n1p1
/ : 1,8 TiB (1995819851776 bytes) trimmed on /dev/mapper/root
```

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?

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?

Thanks and regards,
Bastien

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

[Milan Broz]

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