linux-kernel - Re: pci-disable-decode-of-io-memory-during-bar-sizing.patch

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:	Wed, 31 Oct 2007 00:30:38 +0100
From:	Andi Kleen <ak@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Robert Hancock <hancockr@...w.ca>, Greg KH <greg@...ah.com>,
	akpm@...ux-foundation.org, rajesh.shah@...el.com,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: pci-disable-decode-of-io-memory-during-bar-sizing.patch

> Actually, I guess the bad case wasn't "not listed at all", but incorrectly
> listed - so the probing would go to the wrong address, not find any
> devices, and then promptly result in an unusable machine with no hardware
> attached.

iirc they tended to hang for whatever reason when the mcfg
area was accessed, not just not detect anything.

>
> I _think_ (and hope) those machines were never released.

They were :/ The bug flowed from a Intel reference BIOS to lots of
production boards. 

> But even now, on 
> my main machine, I get "MCFG area at f0000000 is not E820-reserved", and

That's a different issue. The spec does not require it to be e820-reserved.
That was just a (bogus) heuristic originally added to handle the early BIOS
bug. Even BIOS where the mcfg is fine do not reserve it there.

There were some patches to check it against ACPI resources (which
was presumably better specification conforming and more importantly
similar to what M$ does). I'm not sure that fixed all problems and
made the e820 check obsolete though.

> Basically, the resource allocation for mmconf has always been broken
> (largely by *design* by Intel!). And by being broken, it has been
> unreliable.

Well the overlapping to MMIO would have been fine as design if BIOS had
gotten it right.  Trying to design things that BIOS can't get it wrong
is probably futile -- the BIOSes would just find more subtle ways to break.
The real problem I guess was that Linux was trying to use it before 
Windows which is usually a bad idea regarding BIOS support at least
in the Desktop/Laptop space. 

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