Samsung PM-1733 NVMe, cannot revert to default manufactured state while preserving data

[gearshot]

This is the Samsung Opal 2 SED drive:
Series: PM1733
Hardware version: MZWLJ3T8HBLS-00007
Firmware version: EPK9FB5Q

Using on Linux.

My goal was to disable SED (such that --initialSetup works again) while preserving data. I followed the recommended steps from sedutil.com, and extras-- see ChubbyAnt#4. Initially I thought I was successful, but upon power-cycling the drive all data was gone.

I did not see any error in the code, the --revertNoErase should set the KeepGlobalRangeKey parameter correctly, which should prevent --revertTper from erasing data. The problem may be in the drives implementation.

I did find a workaround of sorts, but it will require a modification to the sedutil-cli code to be useful in my case. The below sequence of commands, with password hashing turned off (-n) seems to work. I'm not sure if a 100% revert to factory is accomplished, but the drive will respond to --initialSetup again, and no data is lost.

sedutil-cli -n --initialSetup debug /dev/nvme0
< snip>

sedutil-cli -n --disableLockingRange debug /dev/nvme0
LockingRange0 disabled
sedutil-cli -n --revertNoErase debug /dev/nvme0
Revert LockingSP complete
sedutil-cli --printDefaultPassword /dev/nvme0
MSID: MSID_string
sedutil-cli -n --setSidPassword debug MSID_string /dev/nvme0
SID password changed

sedutil-cli -n --initialsetup debug /dev/nvme0
SID password changed
takeOwnership complete
Locking SP Activate Complete
LockingRange0 disabled
LockingRange0 set to RW
method status code NOT_AUTHORIZED
Set Failed
Unable to update table
Unable to set setMBRDone on
unable to set MBRDone
Initial setup of TPer complete on /dev/nvme0

(The MBR-related step always prints errors, but this is a non-boot drive so it's not a concern here.)

Password hashing cannot be used above, because the SID password must be set back to the MSID. In order to use password hashing, perhaps the -n option could be expanded to:
-n: do not hash any passwords
-n old: do not hash the old password when two are used
-n new: do not hash the new password when two are used

Does this idea have merit?

[gearshot]

Update: I resolved this issue with a FW upgrade on the drive from revision EPK9FB5Q to EPK9GB5Q. I can now disable SED and power cycle the drive without data loss. I used these commands:

sedutil-cli --disablelockingrange 0 debug /dev/nvme0
LockingRange0 disabled
sedutil-cli –revertnoerase debug /dev/nvme0
Revert LockingSP complete
sedutil-cli --reverttper debug /dev/nvme0
revertTper completed successfully

I do still think the CLI option I proposed is useful to set a hashed SID password back to the default MSID, but feel free to close upon review.

[r0m30]

For some reason, this function has always been a problem, when I first wrote this only about one in three drives worked. I really hate working around manufacturer errors, but can see where this might be useful. The reason I am skeptical about adding it is that it would be a false workaround. There are a lot of other things that could cause problems because they weren't reset (locking ranges are the most obvious)

[iyanucodes]

Hey, I was just wondering how you were able to get a firmware update. I have a PM1733A but I have been unable to get firmware updates. Any assistance is appreciated

[gearshot]

iyanucodes, I work in the storage industry and was able to get a firmware update for this drive through company contacts. I was also unable to find a public URL for the firmware; I think this is often the case for enterprise-level drives that are mainly found in data centers and not sold by retail. Unfortunately I cannot be of further assistance, as I would be violating one or more company rules...

[greenertux]

You can find a newer firmware here: linux-nvme/nvme-cli#1126 (comment)