linux-kernel - Re: [patch 02/11] PAT x86: Map only usable memory in x86

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: <20080114164324.GH15542@elte.hu>
Date:	Mon, 14 Jan 2008 17:43:24 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
Cc:	Andi Kleen <andi@...stfloor.org>, ebiederm@...ssion.com,
	rdreier@...co.com, torvalds@...ux-foundation.org, gregkh@...e.de,
	airlied@...net.ie, davej@...hat.com, tglx@...utronix.de,
	linux-kernel@...r.kernel.org,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [patch 02/11] PAT x86: Map only usable memory in x86_64
	identity map and kernel text


* Pallipadi, Venkatesh <venkatesh.pallipadi@...el.com> wrote:

> Also, relying on MTRR, is like giving more importance to BIOS writer 
> than required :-). I think the best way to deal with MTRR is just to 
> not touch it. Leave it as it is and do not try to assume that they are 
> correct, as frequently they will not be.

i'd suggest the following strategy on PAT-capable CPUs:

 - do not try to write MTRRs. Ever.

 - _read_ the current MTRR settings (including the default MTRR) and 
   check them against the e820 map. I can see two basic types of 
   mismatches:

     - RAM area marked fine in e820 but marked UC by MTRR: this 
       currently results in a slow system. (NOTE: UC- would be fine and 
       overridable by PAT, hence it's not a conflict we should detect.)

     - mmio area marked cacheable in the MTRR (results in broken system)

   then emit a warning and exclude all such areas from any further Linux 
   use. I.e. if it's RAM then clip it from our memory map. If it's mmio 
   area then try to exclude it from BAR sizing/positioning.

   this way we'll only have two sorts of physical pages put into 
   pagetables by Linux:

     1) RAM page, marked cacheable by MTRR
     2) RAM page, marked as UC- by MTRR
     2) mmio page, marked as UC- by MTRR

 - then we'd use PAT for all these patches to differentiate their 
   caching properties. We mark RAM pages as cacheable, and we mark mmio 
   pages as WC or UC.

I.e. try to be as conservative and always have a deterministic exit 
strategy towards a 100% working system, even if BIOS writers messed up 
the MTRR defaults. _Worst-case_ we boot up with somewhat less RAM or 
with a somewhat smaller mmio area. (but there will be warnings in the 
dmesg about that so users can complain about the BIOS.) We should never 
ever allow the wrong BIOS MTRR defaults to impact Linux's correctness.

hm?

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