linux-kernel - Re: MTRR initialization

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: <m1lkb6xxl2.fsf@ebiederm.dsl.xmission.com>
Date:	Sun, 16 Sep 2007 12:40:57 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Yinghai Lu" <yhlu.kernel@...il.com>
Cc:	"Howard Chu" <hyc@...as.com>, "Andi Kleen" <ak@...e.de>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: MTRR initialization

"Yinghai Lu" <yhlu.kernel@...il.com> writes:

> On 9/16/07, Howard Chu <hyc@...as.com> wrote:
>> Yinghai Lu wrote:
>> > On 9/14/07, Howard Chu <hyc@...as.com> wrote:
>> >> Hi, was wondering if anyone else has been tripped up by this... I've got
> 4GB of
>> >> RAM in my Asus A8V Deluxe and memory hole mapping enabled in the BIOS. By
>> >> default, my system boots up with these MTRR settings:
>> >>
>> >> reg00: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
>> >> reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>> >> reg02: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
>> >> reg03: base=0xc0000000 (3072MB), size= 256MB: write-combining, count=1
>
> if rev F before cpu aka Rev E is installed, and 8G RAM installed, it will be
>> >> reg00: base=0x00000000 (   0MB), size=8192MB: write-back, count=1
>> >> reg01: base=0x100000000 (8192MB), size=1024MB: write-back, count=1
>> >> reg02: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
>> >> reg03: base=0xc0000000 (3072MB), size= 256MB: write-combining, count=1
> and you will have problem...
>
> So good way is get the ram top, and hole size...and reset the whole
> set ot var mtrr.
>
> you could refer the code in LinuxBIOS about setting that...
> http://www.openbios.org/viewvc/trunk/LinuxBIOSv2/src/cpu/x86/mtrr/mtrr.c?revision=2616&view=markup
> esp the part about CONFIG_VAR_MTRR_HOLE...
>
> but Andi and Eric said resetting mtrr is not good... when someone from
> intel try to trim the MTRR for intel CPU.

There are a couple issues with changing the MTRR configuration.
- You may not have perfect information on the cpu, the AMD revF is a good
  example.
- Code in SMM mode may actually depend on the current mtrr configuration.
- The BIOS's need to fixed to setup MTRRs properly.

So the sanest approach appears to be.
- In linux only use ram that is mapped by a write-back mtrr.
  This preserves performance and is always safe.
- If you need write-combining set it up in the page tables with PAT.

There is some difficulty there but software can always do those things
safely.

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