Re: libata's awful reaction to passworded disks

Re: libata's awful reaction to passworded disks

[Norman Diamond]

Believe it or not, libata's reaction to passworded disks is even more awful than
Yahoo web mail's latest handling of plain text e-mail.
 
Let's see if manual formatting is better.
 If someone has set a password on an ATA/SATA hard drive and someone later
connects the drive to a Linux system (before or after booting that Linux
system), libata reacts in an unbearably stupid manner.

Someone might have connected the drive with the intention of running the
hdparm command to unlock the drive, or maybe even to remove the password.
Or maybe they didn't know that the drive was passworded. But either way,
there's no reason for libata to make a mess.

It is possible to look at the drive's inquiry data to find out if the
drive has a password set and currently locked. It is possible to know
that READ DMA QUEUED and READ DMA etc. are all going to fail. It is
possible to know that no purpose in resetting the drive, resetting the
port multiplier, retyring the reads, retrying the reads, retrying the
resets, retrying the reads, retrying the resets, retrying the reads,
retrying the resets, retrying the reads, retrying the resets, wow this
stuff sure is trying.

Now, is it really insane to retry the same command over and over again
hoping for a different result? Not always. If a glitch is transient,
it might be helpful to observe the error return, maybe try a reset if
necessary, and wait 30 seconds before retrying the read. In fact if
four drives are connected to the same port multiplier or two drives are
connected to the same SATA controller then transient glitches are
frequent and retries (after patient delays) are meaningful.

But retrying automatically, over and over again, when the user hasn't
had time to type an hdparm command? Come on.

Just look to see if the drive is passworded. Don't bother trying to do
the read.

Some time later, if the user runs some program that tries to do a read,
try it and see if maybe the password is gone. Try it when the user
asks for it. But even then, if it fails because the drive is
passworded, don't reset the drive, don't reset the port multiplier, and
don't retry. OK?

Re: libata's awful reaction to passworded disks

[Norman Diamond]

Sorry that Yahoo web mail is probably going to deformat this message.

Tejun Heo replied to me and One Thousand Gnomes:
>>>
>>> If someone has set a password on an ATA/SATA hard drive and someone
>>> later connects the drive to a Linux system (before or after booting
>>> that Linux system), libata reacts in an unbearably stupid manner.
>> 
>> Yes. It's well known. Send patches if you care. So far nobody has cared
>> enough to write the code to use the key rings to deal with drive
>> unlocking.
>
>Hmmm... the reads are prolly from the partition code
 
What?  When the driver doesn't even know whether the disk has partitions
(it might not have been partitioned before the password was set)
there is already code trying to read partitions?
 
And it is partition code that sends resets to the port and to the
port multiplier, interfering with all drives connected to the port?
 
Anyway, the drive's identification data already reveals that the drive
is passworded and locked.  hdparm knows how to interpret and display
that fact.  The driver has enough information to decide not to even
try looking for partitions, not try reading, not issue an error, etc.
 
Only later if a program tries to read something, it might be reasonable
to try reading before delivering an error, because maybe the driver
didn't check if the drive has become unlocked in the meantime.  But
when the error occurs, check to see if the reason is a password lock
and do not send resets to the port and the port multiplier.

>Does anyone want to give a crack at it?

One Thousand Gnomes said I should ^_^
 
I think it was last year that I asked about my proposed code to
increase some timeouts (drives connected through port multipliers
do not always respond as quickly as the driver thinks) but no one
answered.  I made the change myself but am not sure yet if it helps.
 
I think it was last year that I commented on some WTF code in a
Marvell SAS driver.  No one answered.
 
Even if I find time to make this contribution (fat chance), I cannot
realisticly expect anyone to accept my code.

Re: libata's awful reaction to passworded disks

[Tejun Heo]

On Thu, Jun 19, 2014 at 11:38:07AM +0100, One Thousand Gnomes wrote:
> On Thu, 19 Jun 2014 13:18:34 +0900 (JST)
> Norman Diamond <n0diamond@yahoo.co.jp> wrote:
> 
> > If someone has set a password on an ATA/SATA hard drive and someone later connects the drive to a Linux system (before or after booting that Linux system), libata reacts in an unbearably stupid manner.
> 
> Yes. It's well known. Send patches if you care. So far nobody has cared
> enough to write the code to use the key rings to deal with drive
> unlocking.

Hmmm... the reads are prolly from the partition code but I wonder why
libata is not classifying it as AC_ERR_DEV.  ie. why isn't
ata_eh_link_autopsy() delivering just the ATA_EH_REVALIDATE verdict?
Another thing to be updated is ata_eh_worth_retry() so that it returns
false for IO commands if the device is locked.  Or maybe
ata_eh_link_autopsy() can set AC_ERR_INVALID for this case.  Yeah,
that'd make more sense.  Anyways, it should be relatively straight
forward.

Does anyone want to give a crack at it?

-- 
tejun

Re: libata's awful reaction to passworded disks

[One Thousand Gnomes]

On Thu, 19 Jun 2014 13:18:34 +0900 (JST)
Norman Diamond <n0diamond@yahoo.co.jp> wrote:

> If someone has set a password on an ATA/SATA hard drive and someone later connects the drive to a Linux system (before or after booting that Linux system), libata reacts in an unbearably stupid manner.

Yes. It's well known. Send patches if you care. So far nobody has cared
enough to write the code to use the key rings to deal with drive
unlocking.

Alan

libata's awful reaction to passworded disks

[Norman Diamond]

If someone has set a password on an ATA/SATA hard drive and someone later connects the drive to a Linux system (before or after booting that Linux system), libata reacts in an unbearably stupid manner.
 
Someone might have connected the drive with the intention of running the hdparm command to unlock the drive, or maybe even to remove the password.  Or maybe they didn't know that the drive was passworded.  But either way, there's no reason for libata to make a mess.
 
It is possible to look at the drive's inquiry data to find out if the drive has a password set and currently locked.  It is possible to know that READ DMA QUEUED and READ DMA etc. are all going to fail.  It is possible to know that no purpose in resetting the drive, resetting the port multiplier, retyring the reads, retrying the reads, retrying the resets, retrying the reads, retrying the resets, retrying the reads, retrying the resets, retrying the reads, retrying the resets, wow this stuff sure is trying.
 
Now, is it really insane to retry the same command over and over again hoping for a different result?  Not always.  If a glitch is transient, it might be helpful to observe the error return, maybe try a reset if necessary, and wait 30 seconds before retrying the read.  In fact if four drives are connected to the same port multiplier or two drives are connected to the same SATA controller then transient glitches are frequent and retries (after patient delays) are meaningful.
 
But retrying automatically, over and over again, when the user hasn't had time to type an hdparm command?  Come on.
 
Just look to see if the drive is passworded.  Don't bother trying to do the read.
 
Some time later, if the user runs some program that tries to do a read, try it and see if maybe the password is gone.  Try it when the user asks for it.  But even then, if it fails because the drive is passworded, don't reset the drive, don't reset the port multiplier, and don't retry.  OK?