linux-kernel - Re: [PATCH] trim memory not covered by WB MTRRs

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] [day] [month] [year] [list]

Message-ID: <20070620143740.GA17161@one.firstfloor.org>
Date:	Wed, 20 Jun 2007 16:37:40 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Helge Hafting <helge.hafting@...el.hist.no>
Cc:	Jesse Barnes <jesse.barnes@...el.com>,
	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	Justin Piszcz <jpiszcz@...idpixels.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH] trim memory not covered by WB MTRRs

> I assume this cannot be fixed by the simple approach
> of echoing some useful numbers into /proc/mtrr like
> we used to do for video memory? (Before X did this
> automatically?)
> 
> An extra bootscript seems better than loosing memory.

In some cases it probably can, in other cases not because the memory
controller is misconfigured or not the right bits are set 
in the PCI bridges to enable DAC IO or ... or ...

There are also definite limits on how much quirks can do 
to fix this -- Linux is a generic kernel, not a BIOS replacement,
and can never be as intimate with the current setup
as the BIOS is.

It's definitely far safer to not use the memory. You're 
running in a situation never tested or considered by the 
motherboard vendor and everything is possible.

-Andi

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