linux-kernel - [PATCH] ACPI: Adjust the return value of

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

Message-Id: <1426150247-18309-1-git-send-email-matthew.garrett@nebula.com>
Date:	Wed, 11 Mar 2015 22:50:47 -1000
From:	Matthew Garrett <matthew.garrett@...ula.com>
To:	linux-acpi@...r.kernel.org
Cc:	rjw@...ysocki.net, lenb@...nel.org, linux-kernel@...r.kernel.org,
	Matthew Garrett <matthew.garrett@...ula.com>,
	Matthew Garrett <mjg59@...f.ucam.org>
Subject: [PATCH] ACPI: Adjust the return value of _REV on x86

The ACPI spec describes _REV as:

"This predefined object evaluates to the revision of the ACPI Specification
 that the specified \_OS implements"

We've been assuming that this should increment as ACPICA gains support for
new versions of the spec. Unfortunately, Windows always reports "2" for this
value and vendors are now using this as a means to tell whether a system is
running Windows or Linux. From an HP Envy 15:

If (LOr (LEqual (_REV, 0x03), LEqual (_REV, 0x05)))

>From a Dell XPS 13:

If ((_REV == 0x05))

In both cases, the systems then alter hardware initialisation paths and
device capability reporting. As written, this makes no sense - ACPI
maintains backwards compatibility, so the appropriate test would be >=
rather than ==. On closer examination, the HP code uses the same
initialisation paths as would be used if the system responded to
_OSI("Linux"), and as such the evidence is overwhelmingly that vendors are
using this to alter system behaviour when Linux is detected.

Since we aim to be compatible with Windows, this tends to break things. The
ideal solution would be to wait for an _OSI() query matching Windows and
then change behaviour, but Windows responds to _REV with 2 even before that
and so vendors might simply change the order of queries in order to continue
IDing Linux. The easiest thing for us to do is just to change the value on
X86 and leave a comment describing why everything is so awful.

Signed-off-by: Matthew Garrett <mjg59@...f.ucam.org>
---
 include/acpi/acconfig.h | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h
index 03aacfb..cebb8a7 100644
--- a/include/acpi/acconfig.h
+++ b/include/acpi/acconfig.h
@@ -112,9 +112,19 @@
  *
  *****************************************************************************/

-/* Version of ACPI supported */
-
+/*
+ * Version of ACPI supported. This is a sad story. Windows reports a _REV of
+ * 2 regardless of the spec version implemented. Some vendors are using _REV
+ * as a way to distinguish between Windows and Linux, and are breaking systems
+ * in the process. We can't guarantee that they'll call _OSI before checking
+ * _REV, so hardcode this to 2 on x86 systems right now and leave it at the
+ * appropriate spec value for everybody else.
+ */
+#ifdef CONFIG_X86
+#define ACPI_CA_SUPPORT_LEVEL           2
+#else
 #define ACPI_CA_SUPPORT_LEVEL           5
+#endif

 /* Maximum count for a semaphore object */

-- 
2.1.0

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