How do you access an SED-enabled non-boot drive after power-cycling the chassis?

[nufosmatic]

We have a project which involves a data acquisition module populated with NVMe devices that can be removed from a larger assembly and placed in a data extraction system. We have assembled a COTS chassis to do evaluate all of the pieces. The chassis runs CentOS 7.5 and the sedutil is from the distribution. In this setup, the boot media will NOT be encrypted, just the data module devices. We are not interested in ranges - setting up encryption for the entire device aka Global would seem to be the right solution at this time.

It would seem that to set up the data module you do at least the following steps:

sedutil-cli --revertTPer MyOldPassword /dev/nvme0n1 # to make quite certain the drive is erased
sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID /dev/nvme0n1
sedutil-cli --initialsetup debug /dev/nvme0n1
sedutil-cli --enablelockingrange 0 debug /dev/nvme0n1
sedutil-cli --setlockingrange 0 lk debug /dev/nvme0n1
sedutil-cli --setsidpassword debug MyRealPassword /dev/nvme0n1
sedutil-cli --setadmin1pwd debug MyRealPassword /dev/nvme0n1
sedutil-cli --setlockingrange 0 rw MyRealPassword /dev/nvme0n1

So far everything is making sense in its behavior. Writes and reads are all happy. On a simple reboot the drive is completely accessible.

Not so much after a power-cycle. Our understanding from docs and from #93 is after power-cycling the chassis is it only necessary to unlock the range again:

sedutil-cli --setlockingrange 0 rw MyRealPassword /dev/nvme0n1

This command succeeds - apparently the password is recognized (a different value for password will fail), and the "--listlockingranges" option will display sensible values.

However, the LBAs on the drive all come back with all '0's on a read and issues errors on a write.

We are not operating on the MBR as this is not a boot device.

The SuperMicro chassis we are using will prompt for a password. From what we've read this is ATA Security and does not relate to the SED security being set up here. It does not accept any password I present.

What are we missing?

[dtasupport]

mbrenable/mbrdone is what you are missing. Initial setup enables the shadowmbr so you need to either: Set mberdone On whenever you unlock the drive ——-or——- set mbrenable off once

On Wed, Aug 5, 2020 at 09:16 NUFOSMATIC ***@***.***> wrote: We have a project which involves a data acquisition module populated with NVMe devices that can be removed from a larger assembly and placed in a data extraction system. We have assembled a COTS chassis to do evaluate all of the pieces. The chassis runs CentOS 7.5 and the sedutil is from the distribution. In this setup, the boot media will NOT be encrypted, just the data module devices. We are not interested in ranges - setting up encryption for the entire device aka Global would seem to be the right solution at this time. It would seem that to set up the data module you do at least the following steps: sedutil-cli --revertTPer MyOldPassword /dev/nvme0n1 # to make quite certain the drive is erased sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID /dev/nvme0n1 sedutil-cli --initialsetup debug /dev/nvme0n1 sedutil-cli --enablelockingrange 0 debug /dev/nvme0n1 sedutil-cli --setlockingrange 0 lk debug /dev/nvme0n1 sedutil-cli --setsidpassword debug MyRealPassword /dev/nvme0n1 sedutil-cli --setadmin1pwd debug MyRealPassword /dev/nvme0n1 sedutil-cli --setlockingrange 0 rw MyRealPassword /dev/nvme0n1 So far everything is making sense in its behavior. Writes and reads are all happy. On a simple reboot the drive is completely accessible. Not so much after a power-cycle. Our understanding from docs and from #93 <#93> is after power-cycling the chassis is it only necessary to unlock the range again: sedutil-cli --setlockingrange 0 rw MyRealPassword /dev/nvme0n1 This command succeeds - apparently the password is recognized (a different value for password will fail), and the "--listlockingranges" option will display sensible values. However, the LBAs on the drive all come back with all '0's on a read and issues errors on a write. We are not operating on the MBR as this is not a boot device. The SuperMicro chassis we are using will prompt for a password. From what we've read this is ATA Security and does not relate to the SED security being set up here. It does not accept any password I present. What are we missing? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#331>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD52TFDPZCYRDQRP2LCTUSDR7GAWTANCNFSM4PVVKPHA> .

-- ========== Mike

[nufosmatic]

Thank you.

In the setup the diagnostic output indicates that MBREnable is on

$ sedutil-cli --initialsetup debug /dev/nvme0n1
takeOwnership complete
Locking SP Activate Complete
LockingRange0 disabled
LockingRange0 set to RW
MBRDone set on
MBRDone set on
MBREnable set on
Initial setup of TPer complete on /dev/nvme0n1

So my first try I set MBREnable "on" and suddenly my data becomes visible and I can write the drive:

sedutil-cli --setlockingrange 0 rw MyRealPassword /dev/nvme0n1
sedutil-cli --setmbrenable on MyRealPassword /dev/nvme0n1

It looks like MBREnable "on" sets both MBREnable and MBRDone "on". Also, after another power-cycle, it was only necessary to do set the locking range "rw"! So the MBREnable "on" looks to be persistent.

So I re-cycled everything and tried MBRDone; my data becomes visible and I can write the drive:

sedutil-cli --setlockingrange 0 rw MyRealPassword /dev/nvme0n1
sedutil-cli --setmbrenable on MyRealPassword /dev/nvme0n1

HOWEVER - it looks like the right solution is to set up the drive with MBREnable "off" to begin with, given I am not using MBR, but the CLI tool assumes I am.

SOLVED:

sedutil-cli --revertTPer MyOldPassword /dev/nvme0n1 # to make quite certain the drive is erased
sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID MyDrivePSIDFromLabel /dev/nvme0n1
sedutil-cli --initialsetup debug /dev/nvme0n1
sedutil-cli --enablelockingrange 0 debug /dev/nvme0n1
sedutil-cli --setlockingrange 0 lk debug /dev/nvme0n1
sedutil-cli --setsidpassword debug MyRealPassword /dev/nvme0n1
sedutil-cli --setadmin1pwd debug MyRealPassword /dev/nvme0n1
sedutil-cli --setlockingrange 0 rw MyRealPassword /dev/nvme0n1
sedutil-cli --setmbrenable off MyRealPassword /dev/nvme0n1 # this is what was missing

Now once the system is booted, the drive can be accessed again with just this one command:

sedutil-cli --setlockingrange 0 rw MyRealPassword /dev/nvme0n1

I suspect this can be simplified (avoid all of that password dancing)...

Again, thanks.

[nufosmatic]

Simplified - if you are not setting up a bootable drive, then the command set can probably be shortened to this:

sedutil-cli --revertTPer MyOldPassword /dev/nvme0n1 # to make quite certain the drive is erased
sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID MyDrivePSIDFromLabel /dev/nvme0n1
sedutil-cli --initialsetup MyRealPassword /dev/nvme0n1
sedutil-cli --enablelockingrange 0 MyRealPassword /dev/nvme0n1
sedutil-cli --setlockingrange 0 rw MyRealPassword /dev/nvme0n1
sedutil-cli --setmbrenable off MyRealPassword /dev/nvme0n1

Now once the system is booted, the drive can be accessed again with just this one command:

sedutil-cli --setlockingrange 0 rw MyRealPassword /dev/nvme0n1

[nufosmatic]

We think we're good. Thank you again.