Re: SATA HDD password problem

[Tejun Heo <htejun@gmail.com>]

Hello, Rus.

Rus V. Brushkoff wrote:
>  Controller is SATA controller [0106]: ATI Technologies Inc SB600 
> Non-Raid-5 SATA (1002:4380). dmesg attached. hdparm -I /dev/sda :

Ah.. okay.  ahci uses SRST for probing the AHCI controller
initialization sequence involves controller-wide reset which results in
PHY reset.

> ATA device, with non-removable media
> 	Model Number:       WDC WD2500BEVS-22UST0                   
> 	Serial Number:      WD-WXEX07G90288
> 	Firmware Revision:  01.01A01
<---snip--->
> 	   *	Software settings preservation
>
> Seems like SSP supported for this unit. But issuing hdparm -k/-K gives :

Yeap, SSP is supported and enabled.  If supported, SSP is turned on by
default unless explicitly disabled and is supposed to preserve security
mode state.

> [Hors]:root:~ # hdparm -k /dev/sda
> 
> /dev/sda:
>  HDIO_GET_KEEPSETTINGS failed: Inappropriate ioctl for device
> [Hors]:root:~ # hdparm -K 1 /dev/sda
> 
> /dev/sda:
>  setting drive keep features to 1 (on)
>  HDIO_DRIVE_CMD(keepsettings) failed: Input/output error
> .....

Those two are different ones.  These are to keep software setting over
soft resets and doesn't have much to do with SSP.  Mark, maybe we need
to add a feature to hdparm to configure SSP?

> :As SATA PHY events can happen at any time and PHY events mean COMRESET
> :which is hardreset for the device and resets most configurations, it's a
> :bit difficult.  Basically, OS should record all relevant configurations
> :and reprogram the drive after such event.  OS can also do thing which
> :are BIOS dependent via ACPI _GTF but the problem is that _GTF can only
> :issue no-data command and SECURITY_UNLOCK isn't one of them.  Even if
> :that wasn't the problem, it's pretty dumb to pass clear text to OS via
> :ACPI method.
> :
> :To solve the problem, ATA added Software Setting Preservation
> :featureset, which makes the drive remember configurations over
> :hardresets but it's an optional feature and not all drives implement it.
> : I think having SSP support in the drive is the only sane way to support
> :password locking on SATA; otherwise, the drive can just go away while
> :the system is running.  That said, it would be nice to have a parameter
> :to force SRST or no reset at all for odd cases.
> 
>  Hmm, if someone enable SSP in the drive after password unlock - does this 
> mean that it will be unlocked forever ? Or drive can distinguish between 
> power-on and hard-reset states ?

SSP by default stays on, so once unlocked it will stay unlocked as long
as power stays applied.  On power loss, it gets locked again.  On
reboots, the BIOS can always lock it again if it wants to.

This is weird.  The drive should have stayed unlocked over
initialization sequence as SSP is in effect.  Either the BIOS is turning
off SSP during POST or the drive isn't preserving security mode state
although SSP is in effect.  Testing who's to blame can be a bit
cumbersome and involves removing power from the drive while the rest of
the system is running.  Can you do that?

Thanks.

-- 
tejun