linux-kernel - Re: [PATCH] x86_32: trim memory by updating e820 v3

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: <m17ieh4zuo.fsf@frodo.ebiederm.org>
Date:	Mon, 28 Apr 2008 11:07:59 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Yinghai Lu" <yhlu.kernel@...il.com>
Cc:	"Gabriel C" <nix.or.die@...glemail.com>,
	"Andi Kleen" <andi@...stfloor.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Ingo Molnar" <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Jesse Barnes" <jesse.barnes@...el.com>,
	"Mika Fischer" <mika.fischer@...pnet.de>, balajirrao@...il.com
Subject: Re: [PATCH] x86_32: trim memory by updating e820 v3

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

> On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@...glemail.com> wrote:

> another continuous MTRR mapping.
>
> several months ago, we were talking about modifying MTRR. but Eric
> said that is not safe because acpi and smi...

I think it was Andi who spotted that originally, and yes I do think it
is a pretty horrific failure mode.  Reprogramming the MTRRs requires
full knowledge of the hardware and what is going on that we don't
always have.  PAT support has just been merged, and using that only
requires knowledge about the region whose attributes we intend to change.

So lets concentrate on PAT to solve contiguous MTRR region problems.

We can upgrade UC to WC with pat.  As well as demote WB to UC or WC.
So for those regions we know about we should be in good shape.

In a slightly related vein.  Trimming the memory we consider usable by
looking at MTRRs and if a region is not WB not considering it RAM
sounds like a very reasonable work around for one class of BIOS bugs.

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/