linux-kernel - Re: Intel's response Linux/MTRR/8GB Memory Support / Why doesn't the kernel realize the BIOS has problems and re-map appropriately?

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: <m1ejkrw576.fsf@ebiederm.dsl.xmission.com>
Date:	Mon, 04 Jun 2007 19:38:53 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Yinghai Lu" <yhlu.kernel@...il.com>
Cc:	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	"Justin Piszcz" <jpiszcz@...idpixels.com>,
	"Jesse Barnes" <jbarnes@...tuousgeek.org>,
	"Andi Kleen" <andi@...stfloor.org>, linux-kernel@...r.kernel.org
Subject: Re: Intel's response Linux/MTRR/8GB Memory Support / Why doesn't the kernel realize the BIOS has problems and re-map appropriately?

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

> On 6/4/07, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>>
>> Exactly, and given that this is a fairly easy thing to do, and that
>> occasionally we see systems where this happens (even if their BIOS is
>> later fixed).  It is likely worth it for someone to write up the patch
>> and that compare MTRRs with available memory, and to complain and
>> reserve all memory that MTRRs claim is not write-back.
>>
> that is good.
> Sometime BIOS can not even keep mtrr to the identical between
> different CPU in SMP system.
>
> Or reset mtrr according to e820 table.

Resetting the mtrrs according to match the e820 table is attractive
and it would be even easier to set the MTRR default type to
write-back, and just handle everything else with PAT.

However that would most likely do horrible things to any BIOS going
into SMI mode, and even a more modest scheme with reprogramming
MTRRs would likely have similar problems, where we put something
in the wrong caching mode.

So the only safe thing we can do is not use memory that is not
write-back cached.  That we can positively detect and is a
conservative action so if anything will work that will.

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/