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:	Sun, 9 Dec 2007 13:38:12 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	benh@...nel.crashing.org
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

> The code now replaces the content of the resource structures with the
> hard-decoded legacy addresses for any IDE controller in legacy mode,
> just losing whatever was there (the real BAR value).

This is correct behaviour. It checks the port is in legacy mode. If the
port is in legacy mode the BAR value is undefined and in some cases
completely random.

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

> I suspect any platform with such a quirk to turn IDE controllers into
> native mode will now -also- need to put back the BAR values in the
> struct resource, and do so -before- the platform fixup happens, that is
> from a header quirk.

Improbable unless its willing to rely on entirely undefined behaviour.

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. 

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ