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: <Pine.LNX.4.64.0610051600440.3952@g5.osdl.org>
Date:	Thu, 5 Oct 2006 16:07:46 -0700 (PDT)
From:	Linus Torvalds <torvalds@...l.org>
To:	Andi Kleen <ak@...e.de>
cc:	Jeff Garzik <jeff@...zik.org>, discuss@...-64.org,
	linux-kernel@...r.kernel.org
Subject: Re: [discuss] Re: Please pull x86-64 bug fixes

On Fri, 6 Oct 2006, Andi Kleen wrote:
> 
> > In other words, right now we have
> > 
> > 	int pci_read_config_byte(struct pci_dev *dev, int where, u8 *val)
> > 
> > and maybe we will simply have to add a totally new function like
> > 
> > 	int pci_read_mmio_config_byte(struct pci_dev *dev, int where, u8 *val)
> > 
> > for drivers that literally _require_ the mmio accesses for one reason or 
> > another.
> 
> That's easy to decide: if (where >= 256) mmconfig is required. 
> 
> I'm just afraid it probably won't help if the MCFG is totally broken and
> points to some other devices (like on the Intel boards). Then these drivers will 
> just hang and all of Alan's warning  messages won't help with that.

Sure. I'd actually prefer a separate interface partly for that reason, and 
partly also because I think the whole "pci_read_config_xxx()" interface 
has always been horrible.

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.

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.

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

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