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: <m1y76wzaxg.fsf@frodo.ebiederm.org>
Date:	Tue, 29 Apr 2008 13:02:51 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Yinghai Lu" <yhlu.kernel@...il.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>,
	"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

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

> On Tue, Apr 29, 2008 at 12:19 PM, Eric W. Biederman
> <ebiederm@...ssion.com> wrote:
>> "Yinghai Lu" <yhlu.kernel@...il.com> writes:
>>
>>
>> >>  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.
>>  >
>>  > and ACPI area too.
>>
>>  True but at least that one is visible.
>>
>>
>>  > that only try to make the continuous to discrete layout. and still try
>>  > to cover all that is (WBs - UC) directly with WB.
>>  > only thing is that could run out of MTRR..., and mtrr_gran_size is
>>  > used to avoid that.
>>  > then some RAM that is less than mtrr_gran_size could be dumped.
>>  > so mtrr_gran_size could do sth.
>>  > anyway this patch only can meet one end.
>>  > for example Mika Fischer's system doesn't need to trim any RAM in MTRR.
>>  > but for Gabriel's system may need to trim some RAM in MTRR.
>>
>>  Right.  Ram trimming (changing memory from WB to UC) is the potential
>>  problem.
>>
>>  See my other post, in short I think we can address safely address all
>>  of the systems where the only problem is the selection of MTRRs by the
>>  BIOS.
>
> BIOS should provide the selection...

The BIOS will setup which areas should be WB in the mtrrs.
Having in the linux the ability to change from overlapping
mtrrs to discrete mtrrs with BIOS support appears very
practical, useful and always safe.

>>  Then have an option (mtrr_chunk_size) for RAM trimming that is
>>  off by default.
>
> Yes. there is CONFIG option and boot command line to enable it.

However when it is enabled the default chunk size is still 256M.
If we did not apply chunk size processing by default so we
did not transform any regions from WB to UC by default we could
unconditionally enable the code that yields discrete MTRRs.

Then the CONFIG option and the command line option could be made to
apply to the dangerous bits that change areas from WB to UC.  Which
I doubt we will want to have on by default but that can be useful
for people who really want to have X go fast and an uncached SMM
or ACPI area is not a problem. (ACPI we can handle by just copying
the code to a cached area, we can't even discover the SMM area).

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/