How to connect Linux to a HDD that has been "security locked"

In the process of playing around with several hard-drives, and hdparm's --security-set-pass and --security-erase options, I have a pile of HDDs that are in a "locked" state and I cannot unlock them.

I know what the password is, and I am sure that if I can convince Linux to create my /dev/sdc block device, I can use hdparm to --security-unlock the devices. However, Linux refuses to create that block device. I believe it is attempting to identify the device and, because it is locked, it fails.

Is there any way of convincing the Linux kernel to create the block device even if it can't (yet) talk to the drive? The following are the kernel messages emitted, over and over:

May 10 18:40:02 kernel: [  480.989385] ata10: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen
May 10 18:40:02 kernel: [  480.989395] ata10: irq_stat 0x00000040, connection status changed
May 10 18:40:02 kernel: [  480.989401] ata10: SError: { DevExch }
May 10 18:40:02 kernel: [  480.989414] ata10: limiting SATA link speed to 1.5 Gbps
May 10 18:40:02 kernel: [  480.989421] ata10: hard resetting link
May 10 18:40:04 kernel: [  483.216053] ata10: SATA link down (SStatus 1 SControl 310)
May 10 18:40:04 kernel: [  483.216073] ata10: EH complete

Kernel is 2.6.38-16-generic. Ubuntu. Using a eSATA controller (AHCI drive), but the same thing happens plugged into the motherboard directly. I am yet unable to test this with AHCI disabled. (Will need a different computer for that).

Chris Cogdon

Posted 2013-05-11T02:00:52.410

Reputation: 131

Answers

I had the same problem, with roughly the same dmsg errors.

The problem was that although I knew the password the drive rejected it. The problem was a result of trying to unlock a drive which had been locked in the BIOS of one PC with a different PC. Long story short: the PC's BIOS did not send the actual password to the drive, but a 32 char string consisting of the password padded with zeros.

On another occasion this got even worse: the BIOS did some kind of hashing (so I suppose) and sent a totally different password to the drive. I tried several different paddings but without any success. (It was an Acer.) ThinkPads are also known to do this kind of stuff. Look here for an example: http://shackspace.de/?p=1976

So try unlocking the drive in the same PC the password was set with; try different paddings (0x00, 0xFF, ...); try locking a drive with hdparm and see if you can unlock it again.

masgo

Posted 2013-05-11T02:00:52.410

Reputation: 1 541

Thanks for the tips. Unfortunately not applicable here, since I set the password using the hdparm utility itself, not through bios. – Chris Cogdon – 2014-04-07T23:44:16.000

Have you tried a different SATA cable, a different SATA port and a different controller/mainboard? – masgo – 2014-04-15T15:25:21.387

Yep. All of the above, including using the on-board controller in two computers, and two different PCIe SATA controllers. One thing I tried to do was find a SATA controller that did not present the newer AHCI specification, which would have forced the kernel to treat the drives as an ATA drive rather than a SCSI-emulated drive. What I think is happening is that the kernel sees the drive and tries to determine it's capabilities before I've had a chance to issue the security unlock password. Since it can't do that, it decides the drive is dead and then does not let me talk to it. – Chris Cogdon – 2014-04-16T17:17:15.393