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 12:41:21 +0100
From:	Andreas Herrmann <andreas.herrmann3@....com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	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, 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
 (Causing kernel freeze:)
- Asus M51TR-AP003C notebook
- Asus M51Ta notebook
- Asus M3A-H/HDMI mobo

- maybe some more systems

That is why I prefer to have a general solution for this.
(Which is to hide those bits whenever Linux reads or modifies
fixed-MTRR state.)

> instead of covering bios problem quietly.

It's not quietly, an error message will be printed.

Thomas R. suggested to use "KERN_ERR FW_BUG" but I'd prefer to add a
FW_WARN which should be used "for not that clear (e.g. could the
kernel messed up things already?) and medium priority BIOS bugs."

Note that if Linux does not try to sync fixed-MTRRs the affected
systems do not panic. But as a fact Linux is syncing (and needs to)
MTRR values across CPUs due to other buggy BIOSes ...


Regards,
Andreas

-- 
Operating | Advanced Micro Devices GmbH
  System  | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
 Research | Geschäftsführer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
  Center  | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
  (OSRC)  | Registergericht München, HRB Nr. 43632


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