linux-kernel - Re: [PATCH] x86: mtrr: don't modify RdDram/WrDram bits of fixed 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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Mar 2009 14:29:02 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Andreas Herrmann <andreas.herrmann3@....com>
Cc:	Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	trenn@...e.de
Subject: Re: [PATCH] x86: mtrr: don't modify RdDram/WrDram bits of fixed
 MTRRs

On Thu, 2009-03-12 at 12:41 +0100, Andreas Herrmann wrote:
> On Thu, Mar 12, 2009 at 01:01:26AM -0700, Yinghai Lu wrote:
> > On Wed, Mar 11, 2009 at 8:00 AM, Andreas Herrmann
> > <andreas.herrmann3@....com> wrote:
> > > BIOS is expected to clear the SYSCFG[MtrrFixDramModEn] on AMD CPUs after
> > > fixed MTRRs are configured.
> > >
> > > Some BIOSes do not clear SYSCFG[MtrrFixDramModEn] on BP (and on APs).
> > >
> > > This can lead to obfuscation in Linux when this bit is not cleared on
> > > BP but cleared on APs. A consequence of this is that the saved
> > > fixed-MTRR state (from BP) differs from the fixed-MTRRs of APs --
> > > because RdDram/WrDram bits are read as zero when
> > > SYSCFG[MtrrFixDramModEn] is cleared -- and Linux tries to sync
> > > fixed-MTRR state from BP to AP. This implies that Linux sets
> > > SYSCFG[MtrrFixDramEn] and activates those bits.
> > >
> > > More important is that (some) systems change these bits in SMM when
> > > ACPI is enabled. Hence it is racy if Linux modifies RdMem/WrMem bits,
> > > too.
> > >
> > > I suggest not to touch RdDram/WrDram bits of fixed-MTRRs and
> > > SYSCFG[MtrrFixDramEn] and to clear SYSCFG[MtrrFixDramModEn] as
> > > suggested by AMD K8, and AMD family 10h/11h BKDGs.
> > > BIOS is expected to do this anyway. This should avoid that
> > > Linux and SMM tread on each other's toes ...
> > >
> > 
> > wonder if you could add one dmi check to tell the user that bios is
> > buggy, ask vendor fixed BIOS
> > and skip fixed mtrr sync.
> 
> There seem to be several systems affected that do not hide
> RdMem/WrMem bits from OS. 
> 
>  (Causing Suspend/resume problem:)
> - Acer Ferrari 1000
> - Acer Ferrari 5000


What problem?
Hang second resume???

I have an acer 5720G that hangs on second resume - bios doesn't pass
control to linux at all. First resume works fine.


Best regards,
	Maxim Levitsky



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