Are you all having this issue on the same Samsung 990 drive?
We have run through validation with other drives which do not have an issue with bitlocker.
But I do not think we validate encryption explicitly using hardware OPAL SED support.
Does this issue also happen if you enable bitlocker without HW OPAL SED?
Hello @Kieran_Levin, so good to see someone from Framework here!
I purchased the Samsung 990 Pro instead of the WD SN850X specifically for Bitlocker hardware encryption. I did quite some research and from what I understand Bitlocker requires SEDs to respect the IEEE1667 standard, also known as eDrive.
Found online:
“TCG Opal is another security storage specification and it is not enough for Bitlocker hardware encryption.”
However, the Samsung 990 Pro datasheet is totaly clear about supporting both Opal and IEEE1667. (source of the Datasheet )
“AES 256-bit Full Disk Encryption, TCG/Opal V2.0, Encrypted Drive (IEEE1667)”
So I don’t understand what you mean by:
I’m also seeing the issue with the 990 Pro, I don’t have another drive to test with. Software bitlocker doesn’t cause the issue.
I’d love to have hardware support for encryption on the ssd but at every place i’ve worked, they asked bios companies to remove user configuration in laptops until CVE’s are addressed - i think lenovo obliged for one workplace because they have several hundred thousand employees.
basically last i checked anyone with physical access to ssd can break the opal encryption merely through simple firmware and AT commands yet software bit locker is fine.
Thanks. Anyone who’s checked more recently than four years ago want to weigh in on whether this feature that comes with the laptop should actually work instead of erasing your data?
I am experiencing the same issue as @Damian_Edwards when trying to use a Samsung 990Pro’s OPAL2 hardware encryption. In my case the system is a FW13 13th Gen Intel CPU.
Following the guides completely, I got Windows 11 installed where it enabled hardware encrypted bitlocker. Upon next boot I am receiving the same Boot Manager message where the UEFI cannot see the drive to boot from. Doesn’t matter whether I have Secure Boot enable and enforced, optional or disabled, the very same issue occurs. I went a step further and tried to use DISKPART and BCDEDIT to repair the boot partition, to no success.
I have another system with an Asus motherboard and this system allowed me to use hardware encryption with my 990Pro and W11Pro 23H2. Something is wrong with the FW13 UEFI/BIOS. Can we get this fixed please? @Twistgibber @nrp @Kieran_Levin @ctl
@Damian_Edwards Appears you and I are two FW13 owners actively trying to find a solution to this 990Pro OPAL2 issue. I have an idea on this. Here I go…
I notice that when the 990Pro is not set for encryption enabled, I have the following menu in BIOS/UEFI. Security > Storage Password Setup. In Storage password Setup there are Disable SID settings (several of them and I’m not sure what they all do).
Once I enable encryption using Magician and do the Secure Wipe to fully enable hardware encryption on the 990Pro, when I next enter BIOS/UEFI, the Storage Password Setup menu is gone. Are you seeing the same?
I was thinking to try to do another secure wipe of the 990Pro, then use Magician to disable hardware encryption. Once its disabled, I would then go into BIOS/UEFI Security > Storage Password Setup and “enable Block SID”. Save, then reboot and begin the process all over again with the 990Pro to see if this works around the issue. I do not yet know if the “enable Block SID” function is sticky and will survive multiple reboots or until the hardware encryption key is validated by the Block SID at which time the UEFI/BIOS can safely disable it again on its own. I’m not sure how Framework programmed this to work or if the behavior is proper for what we’re trying to accomplish.
Thoughts before I spend another hour or two on this? Almost as annoying as my time lost on this project is the wear and tear on the 990Pro…ho hum.
The “Block SID” function is to stop changes to the drive encryption key. Toggling it after encryption is enabled is a security measure to prevent software tampering with the key. It’s technically not required after encryption is enabled, but it is important to block attempts to silently disable the encryption by hostile software running from the encrypted drive. Enabling it prior to enabling encryption will just prevent you from completing it - or at least it should; this functionality is obviously currently not working as intended.
As @Ansley_Barnes says, these operations are intended to protect TPM operations if I understand correctly. The “PPRequired” options mean “physical presence required” and is what is supposed to cause the BIOS to stop during POST and prompt for input.
All that said, if one of those options (perhaps “Disable_BlockSIDFunc”) is persistent across reboots, then selecting it BEFORE preparing the 990 Pro for encryption might help, but if the BIOS is then hiding the menu, you won’t be able to unselect it again, leaving the system open to silent encryption changes. Although it might be possible to set the flag from Windows PowerShell as the guide we’ve been using indicates.
Ultimately, it seems this is a BIOS bug that is resulting in the menu being hidden when the drive is ready for encryption. I never saw the menu show up myself, but I know others have reported what @Scott_H has seen, so that definitely seems related to the issue.
Another thought. Perhaps after getting BitLocker hardware encryption enabled, shut down the machine, remove the SSD, then boot into the BIOS and see if the menu shows up again? Probably unlikely because it’s under the storage section and there’d be no drive installed, but might be worth a try. Actually, @Scott_H if you’re in this state right now, perhaps remove the drive and boot into the BIOS to see what’s there?
Thanks for the explanation. If by default FW is setting BlockSID to “no operation” what should we infer from that? Is it enabled or disabled or is the function completely ignored (if that’s even an option)?
I agree with you that there’s a behavior issue here and very likely FW never designed or tested for use with SED. Hopefully this is a wake up call for them to correct the issue(s). And I hope we don’t have to wait months for a fix.
Thank you for this. What you write makes sense. When I have some spare time to work on this I will do some additional testing with the disable block sid function either before enabling the SED functionality of the 990Pro or see if this menu is accessible with no SSD installed (somehow I doubt it will be available with no SSD).
My FW13 is my almost daily driver when I’m outside my home or office so I’ve got to find time for it to be offline for a bit while I try this out. This holiday weekend would normally be a good time for that but this year I’ve got a full schedule.
I’m hoping someone from FW will acknowledge this and let us know a workaround or that a fix is forthcoming.
“No operation” means “there is currently no pending change.” It just means there’s going to be nothing happening in this area when you save and leave the UEFI. It’s the default because by default, nothing is supposed to happen until it’s told to do something. This is normal and expected of any BIOS/UEFI supporting this functionality.
Hi guys, just noticed this place/topic via some Google Search and thought I might help a bit.
I struggled with HW encryption for 990 Pro on another laptop (Legion Pro7i). Ultimately I ended up enabling HW encryption via sedutil (GitHub - Drive-Trust-Alliance/sedutil: DTA sedutil Self encrypting drive software) and plugged a tiny USB stick that acts as startup drive to decrypt the 990 Pro on startup.
AFAIR 990 Pro had some FW issue with HW BitLocker, apparently improved in some FW update, but it still didn’t work properly for me (AFAIR I wasn’t alone and there was some big topic around this on Samsung forums).
I’ve spent lots of time trying to get this to work, I would advise to not waste too much time on this and either go with HW sedutil or SW encryption via BitLocker.
I’m happy with HW encryption via sedutil, quite fast to boot to pwd prompt via usb stick and the 990 Pro speeds are nearly unaffected, as expected from HW encryption.
Good luck guys!
Appreciate the pointers, but many places mandate BitLocker so other encryption utils don’t work for all. FWIW I’ve successfully configured a 990 Pro with BitLocker hardware encryption on my desktop (after the firmware issue was fixed) so I know it works. The issues folks in this thread are having is almost certainly due to issues with the Framework firmware.
I was able to successfully enable hardware bitlocker without complications on a samsung 990 Pro in a GPD Win 3 laptop. The 990 Pros I’ve been testing with (including the one I have issues with in the framwork) are new and have the latest firmware from the factory.
I may have just dodged a bullet here. I was trying to get hardware encryption to work on my new AMD board that arrived today for my FW13. Probably my mess up was enabling BLOCK_SID on my drive before doing the secure erase using the Samsung Boot USB. Now I can’t see any storage options for security in the BIOS anymore.
I did get secure boot re-enabled, I loaded Windows 11, I had already set Samsung Magician to “Ready to Encrypt”. When I finished the windows install and looked, Samsung Magician shows now enabled. Changed Group Policy to only allow hardware encryption. Attempting to encrypt the volume gives the “this volume does not support hardware encryption”. I looked also at MSINFO32 and all looks well there as well.
I guess since folks are having issues on reboot. Maybe it is wise to stick with software encryption for now. It is not like this is a gaming PC anyway and I need the random IO performance.
Correct. BLOCK_SID should only be enabled after the encryption process is complete. The BLOCK_SID function stops the drive’s encryption key from being changed, which is why you got the error.
To get the storage security options back, go into Magician and disable encrypted drive. The UEFI hides the storage security options when the drive OPAL functions are enabled, I’m guessing so they don’t step on each other. I think there’s some logic flaws in this process that lead to the issue we’re seeing.
I’m well aware that FW is knee deep into FW16 BIOS and USBPD related things…However it would be nice if they acknowledged this thread to let us know they are or will look into this issue. All FW laptops will clearly need a BIOS fix to allow the use of HW encryption for our SSD’s supporting this function. HW encryption not only will boost performance, but it should also increase battery life. HELP!
So happy I scored a deal on a 990 pro right now. /s
