linux-kernel - Re: ATA device reset, shoud I be concerned?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 Aug 2009 20:40:18 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	Tejun Heo <htejun@...il.com>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Georgi Chulkov <g.chulkov@...obs-university.de>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	Mark Lord <liml@....ca>
Subject: Re: ATA device reset, shoud I be concerned?

On 01/21/2008 08:33 AM, Tejun Heo wrote:
> Tejun Heo wrote:
>> IMHO, losing media error information is much better than locking up a
>> machine hard.  We can start white listing known good controllers but I'm
>> skeptical how much benefit it will bring.
>
> Just a data point, even ICHs lock up after PHY event if the wrong TF
> register is accessed.  I just don't think tempting with TF regs after
> timeout is worth the cost.

Nvidia CK804 SATA controllers appear to also explode on reading TF 
registers after media errors in certain cases. (They tend to either 
lockup the machine or throw HyperTransport timeout machine check 
exceptions). I suspect those error paths aren't well tested (except that 
it even explodes in Windows with the default Microsoft IDE driver, when 
reading a scratched DVD on a SATA drive, for example.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/