diff mbox

Problem: security locked disk and partition table read..

Message ID 4D366DF1.3000303@teksavvy.com
State Not Applicable
Delegated to: David Miller
Headers show

Commit Message

Mark Lord Jan. 19, 2011, 4:52 a.m. UTC 
I was sorting through drives here today, and found one that
was "security locked" (had a user passwd set on it),
and for which I did not know the password.

So I hotplugged it to my SiI-3132 card, with the intent
of simply erasing the drive (thereby clearing the passwd)
using hdparm.

Except.. the kernel (?) sat there for a very long time trying
(and failing) over and over and over and over and over and over
to read sector-0 (the partition table).  Of course the reads
each failed, and then got retried 5-times by SCSI, and then
retried again a zillion times at a higher level.

There's no hope of a read (or write) ever succeeding on a
security locked drive.  So why do we even bother allowing them?

To fix the problem at hand, I patched libata-scsi.c to simply
fail any command other that ATA_12 or ATA_16 (passthru).
This resulted in 56 occurences of this in syslog
when the drive was subsequently powered on:

[   11.050986] ata_scsi_translate: blocking SCSI op 0x28 ATA op 0x60
[   11.050991] sd 2:0:0:0: [sdb]  Result: hostbyte=0x00 driverbyte=0x08
[   11.050994] sd 2:0:0:0: [sdb]  Sense Key : 0x5 [current]
[   11.050998] sd 2:0:0:0: [sdb]  ASC=0x21 ASCQ=0x0
[   11.051001] sd 2:0:0:0: [sdb] CDB: cdb[0]=0x28: 28 00 00 00 00 00 00 00 08 00
[   11.051008] end_request: I/O error, dev sdb, sector 0

Why so many attempts to read the partition table???

Anyway, here's the hack I used:

 			goto defer;

Ideally, that should get re-coded to block only READ/WRITE accesses,
and allow all other commands through, but it worked well enough for
the situation at hand.  After the quick failure of the 56 attempts
to read the partition table, I was then able to use hdparm to issue
the security-erase command to clear out the drive.

Suggestions?
Anyone want to gain fame and fortune (well, fame anyway) by implementing
this more properly?

Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Tejun Heo Jan. 19, 2011, 3:08 p.m. UTC | #1 
On Tue, Jan 18, 2011 at 11:52:01PM -0500, Mark Lord wrote:
> I was sorting through drives here today, and found one that
> was "security locked" (had a user passwd set on it),
> and for which I did not know the password.
> 
> So I hotplugged it to my SiI-3132 card, with the intent
> of simply erasing the drive (thereby clearing the passwd)
> using hdparm.
> 
> Except.. the kernel (?) sat there for a very long time trying
> (and failing) over and over and over and over and over and over
> to read sector-0 (the partition table).  Of course the reads
> each failed, and then got retried 5-times by SCSI, and then
> retried again a zillion times at a higher level.

I think SCSI and libata are behaving okay here.  The root cause is how
the partition code handles IO errors.  Different partition table type
probes do IOs separately.  It's somewhat reasonable given that they
may poke at different sectors which sometimes could be near the end of
the device failure of which might not necessarily mean the whole
device is inaccessible, but anyways the end result is that the each
partition table type pokes the drive regardless of how the previous
attempt went.  And yeah we probably need some improvements there.

Thanks.
Alan Cox July 6, 2011, 11:41 a.m. UTC | #2 
> Except.. the kernel (?) sat there for a very long time trying
> (and failing) over and over and over and over and over and over
> to read sector-0 (the partition table).  Of course the reads
> each failed, and then got retried 5-times by SCSI, and then
> retried again a zillion times at a higher level.

It gets prodded by the various partition formats, the userspace hotplug
code and so on, not always for block 0.

> Why so many attempts to read the partition table???

Each partitioning format does its own requests. Normally that is fine but
in this case its bad news.

> Anyway, here's the hack I used:

Presumably we should set a per device flag of 'security locked' and fail
normal I/O to it but allow the other paths ? The 'proper' way would then
be to use the key rings and also a kernel event to poke userspace into
handling it.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

--- a/drivers/ata/libata-scsi.c	2010-12-09 20:39:24.401410310 -0500
+++ b/drivers/ata/libata-scsi.c	2011-01-18 20:04:06.017446657 -0500
@@ -1819,7 +1819,15 @@ 

 	if (xlat_func(qc))
 		goto early_finish;
-
+	/* don't flog a dead horse, err.. drive, if it is security-locked */
+	if (cmd->cmnd[0] != ATA_12 && cmd->cmnd[0] != ATA_16) {
+		if (dev->id[128] & (1<<2)) { /* locked? */
+			printk(KERN_INFO "%s: blocking SCSI op 0x%02x ATA op 0x%02x\n", __func__,
cmd->cmnd[0], qc->tf.command);
+			ata_scsi_set_sense(cmd, ILLEGAL_REQUEST, 0x21, 0x0);
+			goto early_finish;
+		}
+	}
+
 	if (ap->ops->qc_defer) {
 		if ((rc = ap->ops->qc_defer(qc)))