unable to take ownership on 'initialsetup'

[ghost]

Hi,

I have an already full-encrypted drive, a Crucial MX500 (CT1000MX500SSD1). In order to use this drive as system drive, I have my /boot partition on an unencrypted usb stick where I unlock the drive from. Now I'd like to setup a pba on that drive in order to get rid of the usb stick.
But I'm not succeeding by following the well-known guides.

# hdparm -I /dev/sda | sed -n '/^Security/,/level/p'
Security: 
	Master password revision code = 1
		supported
		enabled
	not	locked
		frozen
	not	expired: security count
		supported: enhanced erase
	Security level high

# sedutil-cli --scan
Scanning for Opal compliant disks
/dev/sda    2  CT1000MX500SSD1                          M3CR023

# sedutil-cli --query /dev/sda

/dev/sda ATA CT1000MX500SSD1                          M3CR023  myserial        
TPer function (0x0001)
    ACKNAK = N, ASYNC = N. BufferManagement = N, comIDManagement  = N, Streaming = Y, SYNC = Y
Locking function (0x0002)
    Locked = N, LockingEnabled = N, LockingSupported = Y, MBRDone = N, MBREnabled = N, 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 = 0x0, Reverted PIN = 0x0, 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

Now when trying to run initialsetup sedutil-cli claims it cannot take the ownership:

# sedutil-cli --initialsetup 'mypassphrase' /dev/sda
method status code NOT_AUTHORIZED
Session start failed rc = 1
One or more header fields have 0 length
EndSession Failed
takeOwnership failed
Initial setup failed - unable to take ownership

I'm pretty stuck here, can anyone point me to the right direction please? I'd prefer not to revert the PSID

[oom-is]

You said that: "I have my /boot partition on an unencrypted usb stick where I unlock the drive from."

What tool are you using to unlock the drive, because whatever it is (whether it's SEDutil or something else) it apparently has already taken crypto ownership of the drive so the Manufacturer SID (MSID) is already set to something other than the default.

SEDutil expects the MSID to be set to default when taking ownership - so you need to (in some way) revert whatever tool you've previously used to take ownership. Does that make sense?

If you were previously using SEDutil, then the process to revert back to default MSID would be:

  sedutil-cli --revertNoErase <passphrase> /dev/sda
  sedutil-cli --revertTPer <passphrase> /dev/sda

The revertTPer call warns about erasing data, and if it's run without the revertNoErase then it would in fact do a crypto-erase and erase all data. However, if the revertNoErase is run first, then (by design) the revertTPer just restores things to ~near-factory state.

However, since you didn't specify I'm guessing you've been unlocking with some other tool (such as hdparm since you're familiar with that. Whatever you've previously done to encrypt the drive needs to be undone before --initialSetup will work....

[ghost]

Hi, thanks for your answer.
Yes, I'm using hdparm to unlock the drive at boot. I'll try undoing the encryption either by resetting the password to whatever sedutil-cli --printDefaultPassword /dev/sda gives me or by fully disabling ata security. Which might require a little hack because I own a Gigabyte mainboard which freezes the disk state after boot, as you can see in my initial posting (frozen). Oh, could that also be the cause for sedutil not being able to take ownership?

[oom-is]

I wasn't familiar with the "frozen" state shown in hdparm, but after a look it does appear that the drive being in the frozen state could also be part of the problem ("frozen" is intended to make it impossible to modify security-relevant settings on the drive AFAICT.)

Now that you've confirmed that you were using ATA security through hdparm - yep, you'll need to undo that entirely as the TCG Opal functions are essentially orthogonal to ATA security. They are intended to achieve a similar-but-related set of goals, but through a whole different set of commands - so a drive that has ATA Security enabled is fundamentally not in a state where the TCG Opal "take crypto ownership" process can reasonably start.

Good luck and keep folks posted - note that I'm a user of SEDutil with my own fork, here only as a volunteer since Drive Trust Alliance hasn't made any code updates since 2017 or answered issue posts since 2018 to my knowledge.

[ghost]

Hi,

unfortunately it didn't work.

I detached all availabled drives, got myself a live usb stick, booted from it (with libata.allow_tpm), put the drive in question into a docking station (to avoid the frozen state) and tried again.

To check whether or not the frozen state was responsible for my problem, I tried the initialsetup again while the drive was unlocked and not frozen:

$ hdparm --security-unlock 'mypassphrase' /dev/sdd                                                                                                               
# => ata security is:
#  supported
#  enabled
#  NOT locked
#  NOT frozen

$ sedutil-cli --initialsetup 'mypassphrase' /dev/sdd
# => method status code NOT_AUTHORIZED

Ok, didnt work. Was kind of expecting that.
Next I tried to disable the ata security:

$ hdparm --security-disable 'mypassphrase' /dev/sdd
$ hdparm --user-master m --security-disable 'mypassphrase' /dev/sdd
# => ata security is:
#  supported
#  NOT enabled
#  NOT locked
#  NOT frozen

$ sedutil-cli --initialsetup 'mypassphrase' /dev/sdd
# => method status code NOT_AUTHORIZED

Maybe disabling the passphrase wasn't enough, so I reset it to the drive's default one:

$ sedutil-cli --printDefaultPassword /dev/sdd
# => MSID: crucial_bymicron

$ hdparm --user-master m --security-set-pass 'crucial_bymicron' /dev/sdd
# => ata security is:
#  supported
#  NOT enabled
#  NOT locked
#  NOT frozen

$ hdparm --user-master u --security-set-pass 'crucial_bymicron' /dev/sdd
# => ata security is:
#  supported
#  enabled
#  NOT locked
#  NOT frozen

$ hdparm --security-disable 'crucial_bymicron' /dev/sdd
# => ata security is:
#  supported
#  NOT enabled
#  NOT locked
#  NOT frozen

$ sedutil-cli --initialsetup 'mypassphrase' /dev/sdd
# => method status code NOT_AUTHORIZED

Bummer! Now trying to revert according these steps: #316 (comment)

$ sedutil-cli --revertNoErase 'crucial_bymicron' /dev/sdd
# => method status code INVALID_PARAMETER
# Session start failed rc = 12
# One or more header fields have 0 length
# EndSession Failed
# Start session failed

$ sedutil-cli --disablelockingrange 0 'crucial_bymicron' /dev/sdd
# => INVALID_PARAMETER

Still no luck. So even by disabling all possible ata security stuff (without security-erase as last resort) I cannot get sedutil to work. Guess I'll stick with my usb stick then 😄
Anyway, thanks a lot for your help 👍

[Demetrio92]

this solved it for me: ChubbyAnt#40 (comment)