linux-kernel - Re: [PATCH 4/5] pata: Update experimental tags

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:	Thu, 19 Nov 2009 16:27:38 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	Alan Cox <alan@...ux.intel.com>, linux-kernel@...r.kernel.org,
	linux-ide@...r.kernel.org
Subject: Re: [PATCH 4/5] pata: Update experimental tags

> > > already have a buggy cable detection (since ->pre_reset ignores the mandatory
> > 
> > Wrong.
> 
> You cannot know it unless you know how chip operates internally.  That's it.

Read the code. How the chip operates is irrelevant.

> You are taking chances that the controller does what most of similar hardware
> do.  Unfortunately we have seen so many counterexamples of this in the past
> (i.e. I wouldn't be so surprised if some hosts just snoop IDENTIFY data to get
> their cable info) that I prefer to stick to safe approaches.

I would be very suprised indeed because neither IDE stack nor the
reference drivers would work in that case.

Even then switch to cable_detect would make no difference. Read the code.

> > Have a free hint. If the host detects the cable type then we don't ask
> > the drive. See the standard if you don't understand why. Even if we
> > didn't the code would still be correct because we properly evaluate
> > the speed configuration from all the data sources.
> 
> Please spare your 'free hints' and preaching tone.

If you don't know or follow the standards you'll get bugs. Thats why I
went to so much trouble researching and digging out the rules on cable
detect in detail, and fixing them in libata so that unlike the old IDE
stack they got them right (and more stuff probes correctly). (And Davem -
those did partly - drive ordering at least get pushed into old IDE too)

The reason it doesn't matter beyond style is this. Libata doesn't mangle
drive and host cable state into one thing. The ap->cbl field reflects the
cable type as measured by the controller. The forty wire decision is made
later on a combination of both controller and drive information, trusting
the controller first because the controller is the correct source if it
knows the information (as per the spec). [1]

Thus all the rubbish you spouted earlier doesn't matter at all. The
cable_detect logic was very carefully added so it didn't break back
compatibility with old drivers or re-order stuff wrongly.

For the other stuf "Talk to the maintainer" to quote yourself. I've
been working on other things for the past couple of years.

Alan
[1] The one specific exception here is the SATA cable setting when a
drive reports that it is SATA. There isn't an obvious way to de-uglify
that aspect of it.
--
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/