linux-kernel - Re: Please revert: PCI: fix IDE legacy mode resources

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:	Mon, 10 Dec 2007 07:03:29 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Ralf Baechle <ralf@...ux-mips.org>,
	Yoichi Yuasa <yoichi_yuasa@...peaks.co.jp>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Subject: Re: Please revert: PCI: fix IDE legacy mode resources

On Sun, 2007-12-09 at 13:38 +0000, Alan Cox wrote:
> > has, I don't know for sure), we have a quirk that puts those
> controller
> > back into native mode. But so far, those quirks didn't change the
> > resources as they were supposed to contain the proper BAR values
> that
> > would, from then, be used.
> 
> Then your quirk is faulty (for the general case). The BAR values are
> undefined at that point, they may not even be writable.

Possibly, however, the fact is that those quirks "just worked" on all HW
where we used them in the past, so while in "theory" they are incorrect,
in practice, this is a regression and thus needs to be fixed.

> Improbable unless its willing to rely on entirely undefined behaviour.

I would argue to you that the whole legacy PCI thing is mostly
"undefined behaviour" from day 1. We rely on what worked in practice for
us, period. It's broken now, this is a regression. I'm not saying we
should revert the change in the generic code, I'm just raising an alarm
here as I doubt we are the only platform to do that (heh, I didn't even
write those quirks in the first place) and some fixing is needed in that
area. I'm totally fine with changing the quirks to do the "right"
though.

> If you kick the device out of legacy mode (itself very very board
> dependant) then you must find a suitable new resource allocation for
> the controller. 

Quite possibly, though as I said in practice, what we did so far
happened to "just work" on pretty much everything we were faced with
(which iirc is basically winbond and VIA controllers, possibly a few
others).

Anyway, I'll scrub around. Again, I'm not saying the approach is wrong
in the generic code.

Ben.

--
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/