linux-kernel - Re: [discuss] Re: Please pull x86-64 bug fixes

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]

Message-ID: <452596F9.3010107@garzik.org>
Date:	Thu, 05 Oct 2006 19:36:25 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Linus Torvalds <torvalds@...l.org>
CC:	Andi Kleen <ak@...e.de>, discuss@...-64.org,
	linux-kernel@...r.kernel.org
Subject: Re: [discuss] Re: Please pull x86-64 bug fixes

Linus Torvalds wrote:
> If we had the
> 
> 	void __iomem *cfg = mmiocfg_remap(dev);
> 
> interface, we could (fairly easily) blacklist known-bad motherboards if we 
> needed to, and also, it would allow drivers to check whether mmiocfg is 
> available. It's possible that some drivers might want it if it exists, but 
> it wouldn't necessarily be somethign that they _require_, so they could 
> gracefully handle the case of getting a NULL config space handle back.
> 
> For example, for some devices, maybe they'd lose some error handling 
> capability, but they'd still be able to work otherwise.

Ugh.  Large PCI config space is going to be the norm real soon.  That 
will just nasty up drivers.


> We _can_ do the same thing with checking the error return value from 
> "pci_read_config_xxxx()", and use the "use different access method if the 
> index is >= 256", but I have to say, that just makes my gag reflex 
> trigger. Having the same function just silently do two different things 
> depending on the offset just sounds like a recipe for disaster.

Agreed.


> I dunno. I'm not likely to care _that_ deeply about this all, but I do 
> think that machines that hang on device discovery is just about the worst 
> possible thing, so I'd much rather have ten machines that can't use their 
> very rare devices without some explicit kernel command line than have even 
> _one_ machine that just hangs because MMIOCFG is buggered.
> 
> (And we should probably have the "pci=mmiocfg" kernel command line entry 
> that forces MMIOCFG regardless of any e820 issues, even for normal 
> accesses).

Agreed.

	Jeff


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