linux-kernel - Re: Are these MTRR settings correct?

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: <20091215130957.22047f92@jbarnes-piketon>
Date:	Tue, 15 Dec 2009 13:09:57 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Robert Hancock <hancockrwd@...il.com>
Cc:	Bjorn Helgaas <bjorn.helgaas@...com>,
	Yinghai Lu <yinghai@...nel.org>,
	Tvrtko Ursulin <tvrtko@...ulin.net>,
	Tvrtko Ursulin <tvrtko.ursulin@...hos.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Are these MTRR settings correct?

On Tue, 15 Dec 2009 14:50:44 -0600
Robert Hancock <hancockrwd@...il.com> wrote:
> I wouldn't have a problem with the E820 check being removed, since
> it's not actually reliable by itself anyway. In fact I'm not sure that
> we need any of the reservation checks at all.
> 
> The whole reason we have this junk in there is because early on it was
> thought that a bunch of problems people were seeing with systems not
> working with MMCONFIG turned on were because their MMCONFIG was
> broken, and the reservation checks were there to try to weed this out
> by making sure the MCFG data pointed to a memory area that was marked
> as reserved. Originally it was checking E820 only, which turned out to
> be invalid because the firmware specification only told BIOS people to
> reserve the space in ACPI motherboard resources, not E820.
> 
>  Later on it was discovered that most of the problems were because we
> did all config-space access using MMCONFIG, including the base access,
> and combined with the fact that we don't disable decode on PCI devices
> when sizing memory BARs, the BAR location during sizing would overlap
> the MMCONFIG space and result in the device sucking up the MMCONFIG
> accesses, usually causing a lockup. So it wasn't actually due to any
> broken MMCONFIG motherboards at all. This was solved by using MMCONFIG
> for extended config space access only, so that when we move the BAR
> temporarily during sizing, we're not trying to access the MMCONFIG
> region it overlaps (since BAR sizing requires only base access).
> 
> (Lesson: yes, BIOSes are broken a lot, but you can't jump to
> conclusions.)
> 
> It would be interesting to know if there are any systems where the
> code reports the MCFG area is not reserved in the ACPI motherboard
> resources. I would tend to suspect not, because if it wasn't, Windows
> would potentially assign devices to that memory area on such boards
> and cause things to fail horribly, which presumably isn't happening.
> We might be able to just get rid of all that code.

Yeah, that sounds like an accurate summary.  I'd be in favor of ripping
out the e820 check (it's totally useless and just confusing) and moving
to using mmconfig for everything, not just extended space, provided we
disable decode around our BAR sizing (some bridges needed quirks there
though).

The ACPI resource checks seem harmless; as you say I'd expect every
machine running Windows to already have that part of the firmware
tested with the "Windows boots, ship it" validation.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/