Do not operate on drives which are security locked by password

[Andreas E]

The following is not me, but it's fairly similar:
​https://bbs.archlinux.org/viewtopic.php?id=178554

scsiModePageOffset: response length too short, resp_len=xx offset=yy bd_len=zz

Well after I got this message when trying to do a smartctl long test, I thought my drive was faulty as this guy's one was, but it was 100% OK.

The actual reason for the "error" was almost to be called hilarious: my drive was security locked!
This happened after using security erase (enhanced) via hdparm:

# hdparm --user-master u --security-set-pass /dev/sdc blahdiblah
# hdparm --user-master u --security-erase enhanced /dev/sdc blahdiblah

It may be a bug in hdparm that it doesn't always release the lock as soon as it has finished erasing.

Anyways, that "faulty" drive was actually a great drive, and after doing a DISPWD on it via MHDD, it gave me a PERFECT rating on HDD Sentinel.

tl;dr ?

What this enhancement request is about:

• Do not operate on drives that are security locked by password (makes less sense), instead:
• Inform the user THAT their drive is security locked and write out something like "Can't operate on this drive - unlock it first" so that the user knows what they're up to.
• Do not lead the user down the garden path by telling them about a responselength being too short, making them think it's their drive which is at (hardware) fault.

[Christian Franke]

The ATA commands issued by smartctl shall even work if the (S)ATA drive is in SECURITY LOCKED state.

See commands IDENTIFY, SMART READ DATA, SMART READ LOG, ... in table 9 of ATA/ATAPI-8 Command Set (ACS) revision 6a.

[Alex Samorukov]

I just tested this with my old laptop:

1. I booted from USB and issues sleep command to "unfreeze" disk (freezed by bios)
2. Password was set using hdparm --user-master u --security-set-pass 123456 /dev/sda
3. At this time disk changes status to "password set, not locked", so i put laptop to sleep again to force status change.
4. After wakeup it is in locked state, smartctl -i works fine, smartctl -x shows most of the data correctly, but some commands failing (write SCT Data Table failed) and return scsi error.

Anyway, symptoms are very different from yours, so probably i will check if it is a real issue and will open another ticket.

[Alex Samorukov]

Created bug #637 to deal with ATA security issues.

[Andreas E]

but some commands failing (write SCT Data Table failed) and return scsi error.

samm2, thanks for your concern and for taking the time to do a testcase.

Whilst my 'wontfix' will probably stay, arousing some interest on smartctl's behavior on drives in locked state may not have been the wrongest thing to do, after all. :)