Switching from Thinkpad X1 9th Gen to Framework 13 AMD AI 300: my experience with Opal encryption

NixOS

Which releease version?

Unstable at commit c2a0396 built on 2025-06-03

Which kernel are you using?

6.15.0

Which BIOS version are you using?

Vendor: INSYDE Corp.
Version: 03.03
Release Date: 03/10/2025

Which Framework Laptop 13 model are you using?

AMD Ryzen™ AI 300 Series

Hello, I just want to share my experience moving from a top “traditional” laptop
to the Laptop 13, replicating all my current configuration. I hope it may help
others.

TL;DR

  • Opal with LUKS (option --hw-opal-only) works. Suspension also works, however
    after hibernation on the next boot the BIOS requests a password to unlock the
    disk, which is not any of the two set during the initialization operation with
    cryptsetup luksFormat /dev/part --type luks2 --hw-opal-only;

  • using only the password (so no LUKS setup) set on the storage works, but upon
    resuming the operating system fails to access the disk and after a few seconds
    the kernel starts to complain;

  • resuming from S2Idle is extremely slow;

  • the Thinkpad really misses the trackpoint and discrete buttons for page up and
    down;

end TL;DR

So, I switched from a ThinkPad X1 Carbon 9th gen to a Laptop 13 Ryzen 7 AI 300.
I started by installing Windows, otherwise it would cause chaos later.
Subsequently, I prepared the new configuration by deriving it from the old
laptop’s
(in the configuration
repository, the old laptop is called bean and the new one alai).

Almost everything worked out of the box, I only had to adjust the suspension
configuration, because the X1 supports S3 (suspension method deep in kernel
jargon), while the Laptop 13 supports only S2Idle (I even tried to force it, but
the kernel just doesn’t accept it).

Anyway, on the old laptop I use Opal configured with the utility sedutil to
encrypt the entire disk, with an additional patch (all of this is visible in the
configuration) that allows transparently restoring disk access after suspension.
How the configuration worked is that the password is requested at boot, but not after
resuming. To improve things from a security perspective, the X1 is configured
with suspend-then-hibernate so that after a set time (2 hours in my case), the
system completely shuts down, and therefore at the next boot the password will
be asked again to the user.

I wanted to reproduce more or less the same configuration on the new machine,
but this time using LUKS instead of sedutil because last year LUKS added
support for Opal (and sedutil instead seems to be less maintained) but I
couldn’t manage to have it working more or less like the older.

Everything seems to work perfectly, but when the system goes into hibernation,
probably the disk is not “closed” correctly by LUKS, I don’t know for sure. The
fact is that upon the next reboot, a BIOS dialog window appears asking to unlock
the disk in question (as if it were globally locked instead of per partition as
configured via cryptsetup), but none of the passwords configured during
initialization (of the root and swap partitions) work in this situation.

At this point, if I continue without entering a password, I can boot into
Windows or a rescue system from a USB drive. In the latter case, I can still
manually “open” the two partitions and mount their contents. Alternatively, I
can enter the BIOS and configure a new “master” password, and subsequently
remove the disk’s “lock” status, but after this operation, booting the rescue
system results in the cryptsetup “open” operation failing miserably, and the
data is no longer recoverable.

Since LUKS encryption isn’t working as it should, I tried using only the
“storage password” set via BIOS, but in this case, the operating system can no
longer read data from the disk upon reboot. I felt the defeat… for now, I’ve
removed any type of disk lock, I’ll set it up manually when I’m in a public
place. But it’s a bit like doing manual backups… it’s fine until you forget.

2 Likes

As a possible theory of where the bug is with storage password - try turning off the iommu (amd_iommu=off) or try running it in passthrough (iommu=pt).

If either of those work it’s a hint that this is a BIOS bug.

As for the LUKS issue I feel like you need a systemd hook that will close the LUKS session when hibernating.

Thanks @Mario_Limonciello, I’ll try that amd_iommu, even if I don’t know configuration , even if don’t currently understand why and how it should be relevant, I’ll do some research.

About the LUKS issue, I must say that one of the reasons to move away from sedutil was also it’s poor documentation, but I must say that LUKS appears to be no better on that front… basically the official documentation of all the SED feature is in the release notes and it’s very difficult to find relevand docs, probably because other people simply find it to be working very well or very few are using it. That’s sad.