I have a Framework Laptop 13 with the Ryzen 5 7640U
When I set a storage password in the BIOS settings for the SSD (NOT master HDD password, and NOT supervisor password), resuming from suspend (s2idle) always results in an unreadable storage disk until I do a full power cycle. If I do not set a storage password, this problem never occurs. Can anyone else reproduce this issue?
Specs: I am running Linux (Debian 12 with recommendations from the community thread), and BIOS version 3.03. My SSD is the WD Blue SN580 1TB.
I’m having this issue as well when resuming from s2idle on my AMD Framework 13.
The problem occurs with secure boot disabled, HDD storage password enabled. No issues with the storage password disabled. Workarounds from the “Suspend” section of the Framework Laptop 13 - ArchWiki page are ineffective.
OS: Linux (Arch)
CPU: Ryzen 7, 7840U
BIOS: 3.03
SSD: Samsung 990 Pro 2TB (MZ-V9P2T0B/AM)
Status update: I have been in contact with Framework support since 2023-12-26. After six correspondences, we are no closer to actually root-causing the problem.
I am disappointed by the quality of support from Framework Support.
They gave incorrect and unclear instructions to reset the mainboard (and later, a slight different set of instructions with fewer steps that actually works)
They gave me a set of terminal commands that fails to capture any system or kernel logs. I pointed out the mistakes, but they did not acknowledge it in their response. I just replied with a set of corrected commands.
Their responses lack of attention to previous correspondences. I have had to repeat several key details (e.g. the fact that I have reset my mainboard, my installed Linux distro). In their last response, they made the illogical request to capture logs after installing an officially supported distro to the SSD. Not only have they failed to acknowledge the invalid logging commands, but they also failed to understand that it’s impossible to capture any logs from a system running on the SSD (with storage password set) after resuming from s2idle.
They asked if I had a different SSD to test with. I didn’t have one, so I ordered a WD_BLACK SN770 just for this issue and told them to let me know (twice!) if they actually need the SSD. They have yet to acknowledge that I ordered the SSD.
The only reason I continue to work with Framework Support is it’s the only way I know of to actually reach the core Framework team. I firmly believe the core team is interested in diagnosing and fixing bugs like these. However, I hope my message encourages Framework to evaluate its Support team and improve, for the sake of its customers.
I have the ticket now, I will be replying in the ticket from here on.
The initial contact team was running through our usual process, but yes, this is different.
I will be replying to your ticket directly from here on as I have it in my personal queue.
Some considerations going forward:
This was a very uncommon ticket inquiry. We recommend LUKS vs storage password in the BIOS.
Debian is not a tested distro. We test against and support Fedora 39 and Ubuntu LTS.
I am replicating this now using Fedora 39. I will update in the ticket, but suspect this will be a bug in how the BIOS interacts. Officially, we recommend LUKS. But if I can replicate this, I will escalate this to the engineering team.
And finally, I went through the ticket replies personally. Everything, everything they asked was correct and expected. The first contact team did everything to the letter as we would expect them to do.
If you feel this is not meeting your expectations, I would ask you to review the email thread again as I see absolutely nothing but correct procedure presented in what I read.
I can’t speak for others, but I use both LUKS and storage passwords (or, i used to, before i got a Framework laptop). Keep in mind, when using LUKS, the boot loader is not encrypted. This can be mitigated by going through the trouble of setting up secure boot, but it’s not ideal. This is part of why i use Samsung SSDs to begin with: they support transparent encryption, so locking the drive means that it’s also secured with another layer of encryption.
Update: I’ve wrapped up the conversation with Matt. The current recommendation is still LUKS (and Bitlocker on Windows), but he has put in a feature request to officially support SSD hardware encryption/storage passwords.
Matt also tried reproducing the issue with his own AMD Framework and a WD PC SN740 512 GB, but strangely he is unable to select the option in the BIOS to set the storage password, even though it is visible. We weren’t able to determine the cause.
Also regarding my last message, Matt and I have discussed them in more detail. For the record, I’d like to thank Matt for taking in the feedback and resolving all the remaining questions I had.
@Matt_Hartley Please feel free to correct me on any of the above.
I have the same problem with a SK hynix Platinum P41/PC801 on a stock 6.7.3 kernel.
No secure boot, enabling hard drive password in the bios breaks s2idle resume.
I also completely agree with you regarding hard drive encryption in addition to LUKS.
To be clear, is the current state is that using the BIOS to set a hard drive password is supported but only when not using s2idle?
I have the same issue. It’s quite disappointing that it’s unsupported because when dual booting, hardware encryption is the most convenient option.
@Matt_Hartley: What does “not supported” mean? Does it mean that you’re asserting that hardware encryption doesn’t work, or does it only mean that you are not asserting that it does work?
For what it’s worth, I had no trouble setting the storage password on my WD_BLACK SN850X and SN770M drives in the Laptop 16 BIOS 3.03, and the BIOS prompts to unlock each drive during POST (and will not proceed until both drives are successfully unlocked). Then everything about the drives works perfectly from there… until the system tries to resume from suspend.
One possibly relevant observation is that the drives appear to relock upon a warm reset. That is, even when doing a warm reboot (without a power cycle), the BIOS still prompts for the passwords for both drives before proceeding through POST. I do not know if this behavior is inherent to NVMe, but my Samsung and Crucial SATA SSDs (in another system) only relock when power cycled.
Anyway, this appears to be a BIOS bug, as either the BIOS needs to save the computed Opal keys in RAM during boot and then later retransmit them to the drives during resume from sleep, or (less than ideally) it needs to prompt again for the passwords before handing control back to the OS kernel when resuming.
You can’t set a storage password until you have set the master password. The master password controls access to the drive’s security features, including the ability to set the storage password, so you must set the master password before you will be able to set the storage password. I don’t remember, but you might need to save and exit from the BIOS setup after setting the master password and then subsequently re-enter it to set the storage password.
I did discover a workaround to the issue that the BIOS does not resubmit the Opal key to the drive when resuming from suspend: the Linux kernel can actually do it itself by means of the IOC_OPAL_SAVE ioctl that was added in Linux 4.11. However, sedutil-cli has not yet been updated to support the new ioctl, so either you have to apply this PR to sedutil, or you can use Michal Gawlik’s sed-opal-unlocker:
Arrange for the above command (substituting your drive’s device path and password) to be run during your system boot, and Linux will hold your password in RAM and resubmit it to the drive when resuming from suspend.
Big caveat: This works only for Opal drives. The WD_BLACK SN770M supports the old ATA security lock (NVMe protocol 0xEF) but not Opal, so if you have set a storage password on it in the BIOS, then I still know of no way of auto-unlocking it when resuming from suspend. I ended up removing the passwords from my SN770M since I am only using it for dmcrypt-swap and non-sensitive scratch/cache space.