linux-kernel - [PATCH 0/4] v2: Fix MTRR suspend support for specific machines (some AMD64, maybe others also)

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

Date:	Fri, 13 Apr 2007 17:35:53 +0200 (CEST)
From:	Bernhard Kaindl <bk@...e.de>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
cc:	Andi Kleen <ak@...e.de>, Dave Jones <davej@...emonkey.org.uk>
Subject: [PATCH 0/4] v2: Fix MTRR suspend support for specific machines (some
 AMD64, maybe others also)

Hi,
   This is an updated repost of http://lkml.org/lkml/2007/4/3/110 whith the
changes which Andrew Morton added in http://lkml.org/lkml/2007/4/8/88 to fix
'make headers_check' applied to the 2nd patch, which he updated.

The oops of Andrew's Viao on s2ram was caused by a merge error which
was caused by me sending the patches diffed against 2.6.20 initially.

It is diffed against 2.6.21-rc6-mm1 to allow Andrew to apply it
without rejects to his tree.

Best Regards,
Bernhard

PS: Short summary of the complese description of the patches:

Summary:

With these patches, s2ram and s2disk are fixed on at least the Acer Ferrari
1000 notebooks and at least s2disk on the Acer Ferrari 5000 notebooks.

The BIOS of these Acer AMD Turion 64 notebooks makes use of fixed-range
IORRs to implement Shadow RAM and direct write-back memory, and it does
this while it transitions the system into ACPI mode, but Linux MTTR code
does not handle situations like this yet, which results in errors which
look like hardware errors. Symptoms vary from from instant resets and
power-offs to SATA link failures.

Short problem description:

These system errors is the of Linux MTRR code being unaware of the AMD
IORRs so far and that the Linux MTRR code so far isn't able to cope with
BIOSes which change the MTRRs of CPUs in SMM, e.g. when it is called by
acpi_enable() to transition the system into ACPI mode. The resulting
combinations of AMD IORR MSR bits and Intel-style MTRR bits is not
allowed and causes undefined and unpredictable behaviour (according
to the AMD manual), the fix needs to (at least) save the MTRRs of
the BSP before suspend to make sure that it does not change the fixed-
range MTRR bits on resume, where, with current code, the errors start.

The intro text of initial posting at http://lkml.org/lkml/2007/4/3/110
contains more detail and an overview over the four patches of the fix.
-
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/