Data vanished after poweroff/poweron

Hi,

I have a problem accessing my data after enabling the encryption on my disk.

The disk in question is Crucial MX500 1TB ssd, part no. CT1000MX500SSD1, installed as /dev/sda. I have another disk, a Samsung 990 pro m.2 (/dev/nvme0), which works fine with opal and pba. The 990pro is my boot disk, the Crucial my data store.

Before, the Crucial SSD was password protected using ata-security, I used hdparm to unlock the drive. Apparently ata-security is incompatible with opal, so I wanted to reset the drive in order to use sedutil from now on.

The disk supports opal:

sedutil-cli --scan
# Scanning for Opal compliant disks
# /dev/nvme0 12  Samsung SSD 990 PRO 1TB                  xxxxxxx
# /dev/sda    2  CT1000MX500SSD1                          xxxxxxx

so everything should be fine.

First I unlocked the drive and disabled the security lock:

hdparm --security-unlock ${passphrase} /dev/sda
hdparm --security-disable ${passphrase} /dev/sda

After that, I tried to initialize the drive with sedutil-cli --initialsetup ${passphrase} /dev/sda, which returned a "not_authorized" error. As restoring the psid helped when I had the same issue with my Samsung 990 pro nvme, I did the same here:

sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID ${psid} /dev/sda
sedutil-cli --initialsetup ${passphrase} /dev/sda

Which worked. The disk's data even was still there and usable, fwiw.

I reformatted the disk, put all my precious data on it and double checked it by comparing checksums of the written files and so on. No problem so far.

Now, after powering off the computer and starting it again, I was asked as usual by the pba for my passphrase (for /dev/nvme0). Strange to say that the pba told me that /dev/sda was not locked. Anyway, the computer rebooted and started my OS, but the disk /dev/sda was empty. I expected that the pba probably did not unlock all the drives it could find, so I tried to unlock it manually:

sedutil-cli --setLockingRange 0 RW ${passphrase} /dev/sda
# LockingRange0 set to RW

Unfortunately, the drive still only returns null bytes on reading and i/o errors on writing:

parted /dev/sda print
# Error: /dev/sda: unrecognised disk label
# Model: ATA CT1000MX500SSD1 (scsi)                                         
# Disk /dev/sda: 1000GB
# Sector size (logical/physical): 512B/512B
# Partition Table: unknown
# Disk Flags: 

dd if=/dev/sda bs=1M count=100 status=none | xxd -a
# 00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
# *
# 063ffff0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

dd if=/dev/random of=/dev/sda bs=1 count=1
# 1+0 records in
# 1+0 records out
# 1 byte copied, 0,398703 s, 0,0 kB/s

dmesg | tail
# [ 3567.232894] ata1.00: supports DRM functions and may not be fully accessible
# [ 3567.233588] ata1.00: configured for UDMA/133
# [ 3567.233594] sd 0:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
# [ 3567.233596] sd 0:0:0:0: [sda] tag#7 Sense Key : Illegal Request [current] 
# [ 3567.233597] sd 0:0:0:0: [sda] tag#7 Add. Sense: Unaligned write command
# [ 3567.233599] sd 0:0:0:0: [sda] tag#7 CDB: Write(10) 2a 00 00 00 00 00 00 00 08 00
# [ 3567.233599] I/O error, dev sda, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 2
# [ 3567.233602] buffer_io_error: 119 callbacks suppressed
# [ 3567.233603] Buffer I/O error on dev sda, logical block 0, lost async page write
# [ 3567.233612] ata1: EH complete

However, the disk seems unlocked:

sedutil-cli --query /dev/sda
# /dev/sda ATA CT1000MX500SSD1                          xxxxxxx  xxxxxxxxxxxx
# TPer function (0x0001)
#     ACKNAK = N, ASYNC = N. BufferManagement = N, comIDManagement  = N, Streaming = Y, SYNC = Y
# Locking function (0x0002)
#     Locked = N, LockingEnabled = Y, LockingSupported = Y, MBRDone = N, MBREnabled = Y, MediaEncrypt = Y
# Geometry function (0x0003)
#     Align = Y, Alignment Granularity = 1 (512), Logical Block size = 512, Lowest Aligned LBA = 0
# SingleUser function (0x0201)
#     ALL = N, ANY = N, Policy = Y, Locking Objects = 9
# DataStore function (0x0202)
#     Max Tables = 10, Max Size Tables = 10485760, Table size alignment = 1
# OPAL 2.0 function (0x0203)
#     Base comID = 0x0888, Initial PIN = 0x00, Reverted PIN = 0x00, comIDs = 1
#     Locking Admins = 4, Locking Users = 9, Range Crossing = N
# **** 1 **** Unknown function codes IGNORED
# 
# TPer Properties:
#   MaxComPacketSize = 32256  MaxResponseComPacketSize = 32256
#   MaxPacketSize = 32236  MaxIndTokenSize = 32200  MaxPackets = 1
#   MaxSubpackets = 1  MaxMethods = 1  MaxSessions = 1
#   MaxAuthentications = 14  MaxTransactionLimit = 1  DefSessionTimeout = 300000
#   MaxSessionTimeout = 0  MinSessionTimeout = 5000
# Host Properties:
# 
#   MaxComPacketSize = 2048  MaxPacketSize = 2028  MaxIndTokenSize = 1992
#   MaxPackets = 1  MaxSubpackets = 1  MaxMethods = 1

sedutil-cli --listLockingRanges ${passphrase} /dev/sda
# Locking Range Configuration for /dev/sda
# LR0 Begin 0 for 0
#             RLKEna = N  WLKEna = N  RLocked = N  WLocked = N
# LR1 Begin 0 for 0
#             RLKEna = N  WLKEna = N  RLocked = Y  WLocked = Y
# LR2 Begin 0 for 0
#             RLKEna = N  WLKEna = N  RLocked = Y  WLocked = Y
# LR3 Begin 0 for 0
#             RLKEna = N  WLKEna = N  RLocked = Y  WLocked = Y
# LR4 Begin 0 for 0
#             RLKEna = N  WLKEna = N  RLocked = Y  WLocked = Y
# LR5 Begin 0 for 0
#             RLKEna = N  WLKEna = N  RLocked = Y  WLocked = Y
# LR6 Begin 0 for 0
#             RLKEna = N  WLKEna = N  RLocked = Y  WLocked = Y
# LR7 Begin 0 for 0
#             RLKEna = N  WLKEna = N  RLocked = Y  WLocked = Y
# LR8 Begin 0 for 0
#             RLKEna = N  WLKEna = N  RLocked = Y  WLocked = Y

The passphrase is correct:

sedutil-cli --listLockingRanges wrongpassphrase /dev/sda
# method status code NOT_AUTHORIZED
# Session start failed rc = 1
# One or more header fields have

What did I do wrong? Was the disk some kind of security erased after being powered off? Even if so, why can't I write on the disk? Any help is appreciated.

Hi, @philfry

The performed by you command:

sedutil-cli --initialsetup ${passphrase} /dev/sda

left your disk with MBREnabled = Y (ON) and with MBRDone = Y (ON).

First of all, after performing that command (--initialsetup), you should do also the following commands:

sedutil-cli --enableLockingRange 0 <_yourAdmin1password_> /dev/sda sedutil-cli --setLockingRange 0 LK <_yourAdmin1password_> /dev/sda sedutil-cli --setMBREnable OFF <_yourAdmin1password_> /dev/sda

The last one from mentioned above is telling the device that it will not have the shadow MBR partition, since this is not the booting device. You should perform also

sedutil-cli --setLockingRange 0 RW <_yourAdmin1password_> /dev/sda

if you were going to access the data partition before making power cycle, followed by the linuxpba.

For some reason the linuxpba performed on your booting disk (/dev/nvme0) left your non-booting disk (/dev/sda) with the parameters MBREnabled = Y (ON) and with MBRDone = N (OFF), that means it gave you access to the shadow MBR partition of your data disk, that there is nothing on it (on that partition since you did nod load any PBA image to it), and which partition should not exist on non booting device.

ATB

Hi @JaBoMa

Many thanks for your help!

I can access my data after issuing sedutil-cli --setMBRDone on ${passphrase} /dev/sda even though fdisk/parted tell me there's some data corruption regarting the backup gpt:

fdisk -l /dev/sda
# The backup GPT table is corrupt, but the primary appears OK, so that will be used.
# Disk /dev/sda: 931,51 GiB, 1000204886016 bytes, 1953525168 sectors
# Disk model: CT1000MX500SSD1 
# Units: sectors of 1 * 512 = 512 bytes
# Sector size (logical/physical): 512 bytes / 512 bytes
# I/O size (minimum/optimal): 512 bytes / 512 bytes
# Disklabel type: gpt
# Disk identifier: 7D59C85D-3056-274A-BB7D-6681918209D3
# 
# Device     Start        End    Sectors   Size Type
# /dev/sda1   2048 1953523711 1953521664 931,5G Linux filesystem

sgdisk -e /dev/sda
# Caution: invalid backup GPT header, but valid main header; regenerating
# backup header from main header.
# [...]
# Warning! Secondary partition table overlaps the last partition by
# 591 blocks!
# Try reducing the partition table size by 2364 entries.
# Aborting write of new partition table.

To me it looks like some hidden reserved spaces that was taken from the already allocated data partition. Dunno.

I guess it's not enough just issueing the three commands you gave me to fix my issue. Should I start over, like reverting psid, initialize, enableLockingRange 0, setLockingRange LK (what does 'LK' stand for?) and setMBREnable off, or is there an easier way possibly without data loss?

Hi, @philfry

What I wrote before is from the Wiki's "Encrypting your drive" page, with my modest modification to a non-bootable drive.

I should also mention that your command: sedutil-cli --initialSetup <_yourAdmin1password_> /dev/sda left the LockingRange 0 of your disk disabled.

So don't ask me why you have anything corrupted on this drive because I don't understand at all how you achieved anything by writing data to the drive without executing the command: sedutil-cli --enableLockingRange 0 <_yourAdmin1password_> /dev/sda

Also: I've never used PSID Revert so I don't know why you had data on disk after doing it. Did you get a message after it: "revertTper completed successfully" ?

Here is my humble advice to everyone who is going/starting with sedutil-cli: Please read the instructions on the Wiki pages first. If something is incomprehensible, or works differently than you thought, check the "Issues" pages to see if someone has already asked about it, and maybe someone else has already answered it.

ATB

Sorry, I need to correct my previous message.

The command "sedutil-cli --initialSetup ..." left the LockingRange 0 disabled, but also left it set as RW, and that means it was available as for writing, and for reading as well, just the locking by power cycling was disabled. So you could write the data.

initialSetup aalso prepared disk for partition shadowing. I don;t know, if it "stole" some of the disk space for the shadow PBA partition.

I use the disk that it had many data written already, before I have used the sedutil-cli to prepare it to be locked according to the TCG Opal, including the shadow PBA partition, and I don't have any problems with the data corruption.

I think, however, that the better practice is to prepare the TCG Opal shadowing and locking first, and then to install the system and to write the data on it.

Regards

Hi @JaBoMa

thanks a lot for your explanations and after reading a bit further I think most questions are answered why this happened and what I did wrong.

Kind regards

fwiw: after issueing the three commands from https://github.com/Drive-Trust-Alliance/sedutil/issues/420#issuecomment-1360874163 and re-writing the partition table the disk was perfectly usable again (even the reserved space came back) and it was unlocked automatically by the pba. Thanks!

Drive-Trust-Alliance / sedutil

Data vanished after poweroff/poweron #420