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

3

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).

linux
hard-drive
security
sata
kernel
asked on Super User May 11, 2013 by Chris Cogdon • edited May 11, 2013 by pnuts

1 Answer

1

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.

answered on Super User Jan 17, 2014 by masgo

User contributions licensed under CC BY-SA 3.0