Non-boot drive prompts password on startup and fails.

[droll80]

We have project with similar requirements as mentioned here: https://github.com/Drive-Trust-Alliance/sedutil/issues/331. The setup is as following: PC with Ubuntu <- SSD SQF-S25V8-960G-SCC -> SOM-7569 module with Yocto. The goal is to transfer data from Ubuntu to Yocto and vise-versa using SSD. Following the solved approach https://github.com/Drive-Trust-Alliance/sedutil/issues/331#issuecomment-669554304 I succeeded to lock/unlock SSD on Ubuntu without any issue. But on Yocto side I faced different behavior. First, I see password prompt on system startup (on Ubuntu there is no such prompt) Providing password I used during "initialsetup" ./sedutil-cli --initialsetup MyRealPassword /dev/nvme0n1p1 Returns "Invalid Password" error. Then after several retries I get "TCG Storage device is Locked" message and enters into the system.

After that I use following command for unlocking SSD without any issue: ./sedutil-cli --setlockingrange 0 rw MyRealPassword /dev/nvme0n1

My questions are:

1. Why password fails on startup prompt but succeeds on command mentioned above?
2. How can I disable password prompt at all? I would like to unlock disk using command after system boot (again, on Ubuntu there is no such prompt).

What am I missing?

[Blacklands]

How can I disable password prompt at all? I would like to unlock disk using command after system boot (again, on Ubuntu there is no such prompt).

You can just leave out all the stuff involving the "Shadow MBR", and putting the PBA boot image onto the drive, during setting it up. If you just want to unlock the drive in the OS then you don't need that. Then you can just use sedutil-cli to unlock the drive. I believe that's discussed in the issue you linked (#331), see last comments.

[droll80]

How can I disable password prompt at all? I would like to unlock disk using command after system boot (again, on Ubuntu there is no such prompt).

You can just leave out all the stuff involving the "Shadow MBR", and putting the PBA boot image onto the drive, during setting it up. If you just want to unlock the drive in the OS then you don't need that. Then you can just use sedutil-cli to unlock the drive. I believe that's discussed in the issue you linked (#331), see last comments.

Hi, thank you for your reply. I used commands set exactly as described in the last comment. I didn't put boot image onto the drive. That's why I don't understand why do I see password prompt.

[Blacklands]

Is the prompt from the picture you posted supposed to be the prompt for the drive? Because that is not how the PBA looks, that one is just a terminal text prompt without any GUI.

Could it be that something in Ubuntu (or its bootloader) auto-detects that the drive is an OPAL-encrypted drive and thinks you want to unlock it on boot? I've only used these with Windows so far, but I think Linux has built-in support for Self-Encrypting Drives?

Was the drive fully cleared (e.g. with a PSID revert) before you set it up without the PBA image? Because once you set up the Shadow MBR (MBREnable, MBRDone, and so on), that setting persists, unless you disable it again. Just wondering if the drive might have that enabled still so maybe Ubuntu detects that and presents you with its own version of a boot unlocker prompt. Or maybe it just always does that when it detects an SED drive?

Can anyone using Linux/Ubuntu comment on that?

Maybe you should check the Linux/Ubuntu documentation for OPAL/SED drives.

Then after several retries I get "TCG Storage device is Locked" message and enters into the system.

After that I use following command for unlocking SSD without any issue:

This part is also weird to me. From what I understand, OPAL drives have a retry limit built in, after some failed tries (it varies by drive, it could be 3, or 5, or something else) the drive will completely lock itself, and it should not be possible to unlock it anymore without first power-cycling it. (You can find the retry limit by doing --query on the drive and checking the value for MaxAuthentications in the result.)

[jmollerhoj]

Hi. I have the same pass-prompt-problem as depicted above. It's presented by my ASUS bios, when I turn on the machine and MBR is set to off. I want MBR to be set to off because the SSD's are not supposed to be bootable. But then I get an annoying password-prompt for each drive with MBR set to off. If I enable MBR no more password prompt. EDIT: Point being: it doesn't seem to be a linux/Ubuntu-thing but instead related to an ASUS MB eager to unlock non-MBR OPAL2-drives (which it cannot btw).

[Blacklands]

On one hand, it sounds cool that that exists, as in, some BIOS vendors implement that natively. (Though it would be unlikely to be compatible with the sedutil setup unless you had disabled hashing the password when setting it up, probably?)

On the other hand, if this can't be disabled then that sucks, yeah, they can't just assume that a connected drive with OPAL enabled is supposed to be a boot drive...

You can probably set MBR to enabled for the drive to bypass that then, right? I think Windows especially needs that anyway for non-boot drives because otherwise it will hang for minutes trying to access the drive initially. But then you need to disable it again first before you can unlock the drive. See e.g. #390. Sorry, I can't think of a better way right now.

[jmollerhoj]

Hello again. So after having spend a couple of hours trying to figure out, what's going on I've learned, that the - I take it - BIOS-prompting for passwords for locked non-MBR Opal-drives apparently hasn't got anything to do with MBR being set or not. Not directly anyway.

If I set up a locking range 1 for a partition starting at for instance sector 2048 (instead of sector 0) the BIOS doesn't run amok with password-prompts. And at the same time I can leave MBR off.

Context: I'm trying to configure a couple of Samsung drives on ArchLinux so that the boot partition on drive 1 is the only thing unlocked. So when the system runs it prompts for the pass during /boot which unlocks the rest of the drives/partitions without having to restart. After a lot of trial, error and guessing when it comes to the ins and outs of Sedutil and Opal-behavior things seem to be moving in the right direction

[Blacklands]

That sounds like that BIOS only looks at the global locking range ("range 0"), then. That range covers all of the drive apart from other locking ranges you set up (it can be non-contiguous, unlike the other ranges) IIRC. I guess if you don't set the global range up for locking, you can avoid the whole issue then, maybe.

[droll80]

You can probably set MBR to enabled for the drive to bypass that then, right? I think Windows especially needs that anyway for non-boot drives because otherwise it will hang for minutes trying to access the drive initially. But then you need to disable it again first before you can unlock the drive. See e.g. #390. Sorry, I can't think of a better way right now.

Thanks for this point. I succeeded to overcome the issue with password prompt using following: Settings: ./sedutil-cli --initialsetup MyRealPassword /dev/nvme0n1p1 ./sedutil-cli --EnableLockingRange 0 MyRealPassword /dev/nvme0n1p1 MBREnable will be ON as default Usage/Unlocking: ./sedutil-cli --setlockingrange 0 rw MyRealPassword /dev/nvme0n1 ./sedutil-cli --setMBREnable OFF MyRealPassword /dev/nvme0n1 ./sedutil-cli --setMBREnable ON MyRealPassword /dev/nvme0n1 - Important! Should be set back to ON! Without it prompt will be shown again next power up!

Thanks to all.

[youk]

@jmollerhoj If I set up a locking range 1 for a partition starting at for instance sector 2048 (instead of sector 0) the BIOS doesn't run amok with password-prompts. And at the same time I can leave MBR off.

I assume when you set up locking range 1, you disabled the global locking range or made it unlocked? Then the behavior seems natural. If you have the global locking range enabled and locked, the drive is reported as locked. That's why the password prompt. Otherwise, even with other locking ranges present, it will be reported as not locked.

@Blacklands That sounds like that BIOS only looks at the global locking range ("range 0"), then.

It looks at particular LBA, as any BIOS/UEFI is supposed to: LBA 1 (GPT disk) or LBA 0 (MBR disk). That LBA just happens to be in the global locking range. But I don't think this plays any role here – if my assumption about the global locking range above is correct.

@Blacklands I think Linux has built-in support for Self-Encrypting Drives

If you mean management capabilities similar to sedutil then no, Linux has no "built-in" support. In fact, there's nothing much else to support (except proper resume from S3 sleep).

[Blacklands]

@jmollerhoj I assume when you set up locking range 1, you disabled the global locking range or made it unlocked? Then the behavior seems natural. If you have the global locking range enabled and locked, the drive is reported as locked. That's why the password prompt. Otherwise, even with other locking ranges present, it will be reported as not locked.

You can check each locking range for its status independently if you wish (see listLockingRanges). But yeah, I think what shows up in query (Locked) is taken from the state of the global range.

If you mean management capabilities similar to sedutil then no, Linux has no "built-in" support. In fact, there's nothing much else to support (except proper resume from S3 sleep).

Oh, okay, I saw something in the Arch Wiki and just assumed it meant that there's some basic functionality there (just unlocking). Also because I saw an issue where someone had an unlock prompt in Ubuntu. But it seems that wiki article is mostly just referring to sedutil, too.

[youk]

You can check each locking range for its status independently if you wish

Sure. But I am yet to see a pre-boot solution (PBA using MBR shadowing, UEFI support) which takes into account other locking ranges.

[Blacklands]

sedutil is sadly missing a lot beyond the most basic features of the spec. There's also no real support for users and multiple passwords and all that, afaik. It's too bad that the development stopped when it did.

[youk]

TrueNAS has a fork where some development is going on. However, I'd say that the features already present in sedutil are beyond basic. What is it that you are missing in practical terms?

As for multiple users, you seem to have read "A Practical Guide to Use of Opal Drives". It says opaltoolc can do that. However, OpalTool.exe which I downloaded from SourceForge didn't detect my drive at all. Not even sure it's the same opaltoolc.

[Blacklands]

Oh, nice, hadn't seen that fork yet. Seems it's based on another fork that already did some additional work as well. I hope development will continue there.

What is it that you are missing in practical terms?

At some point I wanted to go through the spec and make a list of missing stuff. Right now from the top of my head I only remember user support as a big thing (imo), but I had some other things in my head as well. I do agree that for basic single users, the features are mostly there (but see the next paragraph).

Imo what is a bigger hole right now are features around the boot image: Secure Boot support, chain-loading support, support for touch devices (I have a tablet with an SSD I wish I could use OPAL on, but being unable to boot without having a keyboard around is kind of a dealbreaker), potential support for other unlock methods (probably not in the spec, but could be translated into a password behind the scenes maybe?)... Right now for a regular PC user the whole process is very unfriendly. You can try using BitLocker with your SED but I personally had a bunch of bad experiences with that in the past.

I know the Shadow MBR is only so big (and the size is fixed, right?), but surely you could fit a more advanced boot image than the PBA image we have right now in there.