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]

Date:	Tue, 29 Apr 2008 10:29:44 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Yinghai Lu <yhlu.kernel@...il.com>,
	Gabriel C <nix.or.die@...glemail.com>,
	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"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

Ingo Molnar <mingo@...e.hu> writes:

> * Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
>> 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.
>
> sure, but whatever we do now in the sysfs API space, it will hit distros 
> only in a year, relistically, because Xorg also has to adopt to it. The 
> workaround from Yinghai looks reasonably configurable - if we mess up 
> (say an SMM comes in while we fiddle with the MTRRs) we'll likely get a 
> lockup right then, during bootup, so it wont be hard to realize what 
> went wrong. In that sense it's in fact safer to do it during early init 
> than let the user do it via some script, because the window is smaller, 
> etc.
>
> we still default to the safe mode of course and dont touch MTRRs, but 
> for note the various configuration options that are available to distros 
> and users.

The potential problem isn't while we reprogram the MTRRs, the potential
problem is mapping the SMM area uncachable.  In which case we will
make each SMM interrupt drastically slower.  Which can have all kinds of
unpleasant side effects.

If we really can mess up SMM mode that way we have a really nasty
interaction that is horrible to debug, or recognize.

Further the opportunity for this kind of fixup is small.
Newer AMD systems don't need it as they have an extra
way of specifying memory about 4G as WB.  Systems with just
the MTRRs can only use this when they have right around 4GB
because with more memory there are not enough MTRRs to leave them
non-overlapping and still mark all of memory WB.

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/