[PATCH] ACPICA: enable compilation for embedded Linux systems
by Al Stone
The ACPICA subsystem of the ACPI driver sets up a compilation environment
for itself, adding in multiple typedefs unique to ACPICA that depend on
where ACPICA will be used.
The vast majority of such environments (Linux, QNX, ...) have an environment
defined in the acenv.h header file. When using a Linaro compiler [1]
specifically built to be used in an embedded environment where perhaps a
kernel and an init process are the only things running, there is no
environment defined for ACPICA so the typedefs it needs are not set up
properly, causing compilation to fail unless ACPI is completely disabled.
Since ACPI is enabled in the default config for the kernel, the compilation
failure becomes fairly obvious [2].
Since building _for_ embedded Linux systems is slightly different than
building _in_ a Linux environment, define a new environment header
called acembed.h. Compilers for these systems may not have the normal
defines a compiler for a Linux environment might, but they are very
close. Then, we fix acenv.h so that when we are using GCC without GLIBC,
we select the embedded environment of acembed.h.
[1]
https://releases.linaro.org/components/toolchain/binaries/latest/aarch64-...
[2] This error was originally discovered by Will Deacon
Signed-off-by: Al Stone <ahs3(a)redhat.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: Rafael J. Wysocki <rjw(a)rjwysocki.net>
Cc: Len Brown <lenb(a)kernel.org>
Cc: Robert Moore <robert.moore(a)intel.com>
Cc: Lv Zheng <lv.zheng(a)intel.com>
---
source/include/platform/acembed.h | 57 +++++++++++++++++++++++++++++++++++++++
source/include/platform/acenv.h | 11 ++++++++
2 files changed, 68 insertions(+)
create mode 100644 source/include/platform/acembed.h
diff --git a/source/include/platform/acembed.h b/source/include/platform/acembed.h
new file mode 100644
index 0000000..e741f8d
--- /dev/null
+++ b/source/include/platform/acembed.h
@@ -0,0 +1,57 @@
+/******************************************************************************
+ *
+ * Name: acembed.h - OS specific defines, etc. for embedded Linux systems
+ *
+ *****************************************************************************/
+
+/*
+ * Copyright (C) 2017, Red Hat, Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions, and the following disclaimer,
+ * without modification.
+ * 2. Redistributions in binary form must reproduce at minimum a disclaimer
+ * substantially similar to the "NO WARRANTY" disclaimer below
+ * ("Disclaimer") and any redistribution must be conditioned upon
+ * including a substantially similar Disclaimer requirement for further
+ * binary redistribution.
+ * 3. Neither the names of the above-listed copyright holders nor the names
+ * of any contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * NO WARRANTY
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
+ * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGES.
+ */
+
+#ifndef __ACEMBED_H__
+#define __ACEMBED_H__
+
+#if !defined(_LINUX)
+#define _LINUX
+#endif
+
+#if !defined(__linux__)
+#define __linux__
+#endif
+
+#include <acpi/platform/aclinux.h>
+
+#endif /* __ACEMBED_H__ */
diff --git a/source/include/platform/acenv.h b/source/include/platform/acenv.h
index 5bec576..b300afa 100644
--- a/source/include/platform/acenv.h
+++ b/source/include/platform/acenv.h
@@ -343,6 +343,17 @@
#elif defined(_AED_EFI) || defined(_GNU_EFI) || defined(_EDK2_EFI)
#include "acefi.h"
+/*
+ * There are systems that run just a minimal Linux kernel; they have
+ * no user space and often extremely pared down configurations -- e.g.,
+ * a small embedded Linux system in a light bulb or other IoT device.
+ * In those cases, we're mostly a Linux system, but the compilers used
+ * may not be aware of that, so create an evironment specific to their
+ * needs.
+ */
+#elif defined(__GNUC__) && !defined(__INTEL_COMPILER) && !defined(__GLIBC__)
+#include <acpi/platform/acembed.h>
+
#else
/* Unknown environment */
--
2.9.3
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
5 years, 2 months
Re: [Devel] [PATCH] ACPICA: use designated initializers
by Zheng, Lv
Hi,
> From: keescook(a)google.com [mailto:keescook@google.com] On Behalf Of Kees Cook
> Subject: Re: [PATCH] ACPICA: use designated initializers
>
> On Sun, Dec 18, 2016 at 10:06 PM, Zheng, Lv <lv.zheng(a)intel.com> wrote:
> > Hi,
> >
> >> From: Kees Cook [mailto:keescook@chromium.org]
> >> Subject: [PATCH] ACPICA: use designated initializers
> >>
> >> Prepare to mark sensitive kernel structures for randomization by making
> >> sure they're using designated initializers. These were identified during
> >> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> >> extracted from grsecurity.
> >
> > This commit is not suitable for ACPICA upstream.
> > It's not portable. Please drop.
>
> What compilers are building this that do not support designated
> initializers? Also, couldn't this be made into a macro so it could be
> supported in either case?
It's MSVC.
In ACPICA upstream, it supports Intel compiler, GCC and MSVC.
>
> #ifdef __GNUC__
> # define ACPI_SLEEP_FUNCTIONS(legacy, extended) { \
> .legacy_function = legacy, \
> .extended_function = extended, \
> }
> #else
> # define ACPI_SLEEP_FUNCTIONS(legacy, extended) { legacy, extended }
> #endif
>
> ...
>
> static struct acpi_sleep_functions acpi_sleep_dispatch[] = {
> ACPI_SLEEP_FUNCTIONS(
> ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
> acpi_hw_extended_sleep),
> ...
There are many such cases in ACPICA, and I couldn't see the benefit to introduce such mechanism to such a software whose purposes contain portability.
Unless you can invent a mechanism that can be utilized by all such cases.
Then you should put it into acgcc.h and implement a replaceable in acmsvc.h.
After that, you surely need to do a cleanup in the entire ACPICA code base using this new mechanism.
Thanks
Lv
>
>
> -Kees
>
> >
> > Thanks
> > Lv
> >
> >>
> >> Signed-off-by: Kees Cook <keescook(a)chromium.org>
> >> ---
> >> drivers/acpi/acpica/hwxfsleep.c | 11 ++++++-----
> >> 1 file changed, 6 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/acpi/acpica/hwxfsleep.c b/drivers/acpi/acpica/hwxfsleep.c
> >> index f76e0eab32b8..25cd5c66e102 100644
> >> --- a/drivers/acpi/acpica/hwxfsleep.c
> >> +++ b/drivers/acpi/acpica/hwxfsleep.c
> >> @@ -70,11 +70,12 @@ static acpi_status acpi_hw_sleep_dispatch(u8 sleep_state, u32 function_id);
> >> /* Legacy functions are optional, based upon ACPI_REDUCED_HARDWARE */
> >>
> >> static struct acpi_sleep_functions acpi_sleep_dispatch[] = {
> >> - {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
> >> - acpi_hw_extended_sleep},
> >> - {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
> >> - acpi_hw_extended_wake_prep},
> >> - {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake), acpi_hw_extended_wake}
> >> + { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
> >> + .extended_function = acpi_hw_extended_sleep },
> >> + { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
> >> + .extended_function = acpi_hw_extended_wake_prep },
> >> + { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake),
> >> + .extended_function = acpi_hw_extended_wake }
> >> };
> >>
> >> /*
> >> --
> >> 2.7.4
> >>
> >>
> >> --
> >> Kees Cook
> >> Nexus Security
>
>
>
> --
> Kees Cook
> Pixel Security
5 years, 2 months
Re: [Devel] I2C operation region battery problem
by Zheng, Lv
You can open a bugtracker on Bugzilla.kernel.org, assigned to ACPI category.
Or if you have already root caused the issue to ACPICA (AFAIK, there was one related to i2c opregion root caused to ACPICA), you can open a bugtracker on bugs.acpica.org.
Thanks
Lv
> From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Nicole
> F?rber
> Subject: I2C operation region battery problem
>
> Hi,
> I have an issue with ACPI operation region I2C support in order to
> access battery information on a Thinkpad Tablet 10. I have analyzed the
> problem to some extend but am not able to find a solution.
>
> Where should I report my analysis to, this list? Another list? A bugtracker?
>
> Cheers
> nicole
>
> --
> Sapere aude!
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
5 years, 3 months
Sorry for my last two postings
by David Renz
I know that this can hardly be an excuse, but I must admit that I wrote my
last to mails to the mailing list after not having slept for a quite long
time - It seems that I had submitted the same ACPI code to malwr.com, and
since I performed various kinds of testing, I'm actually not sure whether
this code was from my systems or much rather code, which had been infected
for testing reasons. I ask for your apologies, especially towards Mr.
Moore, since my tone of voice was certainly not appropriate.
I am not going to submit any posting like this again, since I don't want to
make a foolish impression on any of you, who certainly know much more about
the ACPI standard than I do.
Kind regards and sorry once more
5 years, 3 months
Manipulated ACPI code, follow-up: Disassmbled tables / How the code's exection compromised Linux systems
by David Renz
As promised in my previous posting, I uploaded the extracted and
disassembled ACPI code:
https://www.dropbox.com/s/x5wtjs9kvsbpqql/acpi.zip?dl=0
[password is "acpitables"]
There are also a two other interesting files in the archive:
1) dmesg.out
[...]
[ 0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576
[ 0.000000] Using GB pages for direct mapping
[ 0.000000] BRK [0x023df000, 0x023dffff] PGTABLE
[ 0.000000] BRK [0x023e0000, 0x023e0fff] PGTABLE
[ 0.000000] BRK [0x023e1000, 0x023e1fff] PGTABLE
[ 0.000000] BRK [0x023e2000, 0x023e2fff] PGTABLE
[ 0.000000] BRK [0x023e3000, 0x023e3fff] PGTABLE
[ 0.000000] BRK [0x023e4000, 0x023e4fff] PGTABLE
[ 0.000000] RAMDISK: [mem 0x36a94000-0x37541fff]
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x00000000000F0580 000024 (v02 ALASKA)
[ 0.000000] ACPI: XSDT 0x00000000DE7C4088 000094 (v01 ALASKA A M I
01072009 AMI 00010013)
[ 0.000000] ACPI: FACP 0x00000000DE7D6BF8 00010C (v05 ALASKA A M I
01072009 AMI 00010013)
[ 0.000000] ACPI: DSDT 0x00000000DE7C41B8 012A3C (v02 ALASKA A M I
00000023 INTL 20120711)
[ 0.000000] ACPI: FACS 0x00000000DE7FAF80 000040
[ 0.000000] ACPI: APIC 0x00000000DE7D6D08 000072 (v03 ALASKA A M I
01072009 AMI 00010013)
[ 0.000000] ACPI: FPDT 0x00000000DE7D6D80 000044 (v01 ALASKA A M I
01072009 AMI 00010013)
[ 0.000000] ACPI: FIDT 0x00000000DE7D6DC8 00009C (v01 ALASKA A M I
01072009 AMI 00010013)
[ 0.000000] ACPI: ASF! 0x00000000DE7D6E68 0000A5 (v32 INTEL HCG
00000001 TFSM 000F4240)
[ 0.000000] ACPI: SSDT 0x00000000DE7D6F10 000C7D (v02 Ther_R Ther_Rvp
00001000 INTL 20120711)
[ 0.000000] ACPI: SSDT 0x00000000DE7D7B90 000539 (v02 PmRef Cpu0Ist
00003000 INTL 20051117)
[ 0.000000] ACPI: SSDT 0x00000000DE7D80D0 000B74 (v02 CpuRef CpuSsdt
00003000 INTL 20051117)
[ 0.000000] ACPI: MCFG 0x00000000DE7D8C48 00003C (v01 ALASKA A M I
01072009 MSFT 00000097)
[ 0.000000] ACPI: HPET 0x00000000DE7D8C88 000038 (v01 ALASKA A M I
01072009 AMI. 00000005)
[ 0.000000] ACPI: SSDT 0x00000000DE7D8CC0 00036D (v01 SataRe SataTabl
00001000 INTL 20120711)
[ 0.000000] ACPI: SSDT 0x00000000DE7D9030 005835 (v02 SaSsdt SaSsdt
00003000 INTL 20120711)
[ 0.000000] ACPI: UEFI 0x00000000DE7DE868 000042 (v01 ALASKA A M I
01072009 00000000)
[ 0.000000] ACPI: DMAR 0x00000000DE7DE8B0 000080 (v01 INTEL BDW
00000001 INTL 00000001)
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] No NUMA configuration found
[ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000031effffff]
[...]
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.000000] ACPI: IRQ0 used by override.
[ 0.000000] ACPI: IRQ9 used by override.
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
[ 0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]
[ 0.000000] PM: Registered nosave memory: [mem 0x0009d000-0x0009dfff]
[ 0.000000] PM: Registered nosave memory: [mem 0x0009e000-0x0009ffff]
[ 0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000dffff]
[ 0.000000] PM: Registered nosave memory: [mem 0x000e0000-0x000fffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xd8a8e000-0xd8a94fff]
[ 0.000000] PM: Registered nosave memory: [mem 0xd8ee3000-0xd94f3fff]
[ 0.000000] PM: Registered nosave memory: [mem 0xde24a000-0xde2b3fff]
[ 0.000000] PM: Registered nosave memory: [mem 0xde3c0000-0xde7fafff]
[ 0.000000] PM: Registered nosave memory: [mem 0xde7fb000-0xdeffefff]
[ 0.000000] PM: Registered nosave memory: [mem 0xdf000000-0xf7ffffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xf8000000-0xfbffffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfc000000-0xfebfffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfec00000-0xfec00fff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfec01000-0xfecfffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfed00000-0xfed03fff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfed04000-0xfed1bfff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfed1c000-0xfed1ffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfed20000-0xfedfffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfee00000-0xfee00fff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfee01000-0xfeffffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xff000000-0xffffffff]
[ 0.000000] e820: [mem 0xdf000000-0xf7ffffff] available for PCI devices
[ 0.000000] Booting paravirtualized kernel on bare hardware
[...]
[ 0.184185] ACPI: Added _OSI(Module Device)
[ 0.184187] ACPI: Added _OSI(Processor Device)
[ 0.184188] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.184189] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.187744] ACPI: Executed 6 blocks of module-level executable AML code
[ 0.191619] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[ 0.192467] ACPI: Dynamic OEM Table Load:
[ 0.192471] ACPI: SSDT 0xFFFF88031EF0A000 0003D3 (v02 PmRef Cpu0Cst
00003001 INTL 20051117)
[ 0.193110] ACPI: Dynamic OEM Table Load:
[ 0.193113] ACPI: SSDT 0xFFFF88017FCA3800 0005AA (v02 PmRef ApIst
00003000 INTL 20051117)
[ 0.193810] ACPI: Dynamic OEM Table Load:
[ 0.193812] ACPI: SSDT 0xFFFF88031EEEAA00 000119 (v02 PmRef ApCst
00003000 INTL 20051117)
[ 0.194910] ACPI: Interpreter enabled
[ 0.194930] ACPI: (supports S0 S3 S4 S5)
[ 0.194930] ACPI: Using IOAPIC for interrupt routing
[ 0.194953] PCI: Using host bridge windows from ACPI; if necessary, use
"pci=nocrs" and report a bug
[...]
[ 0.204595] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM
ClockPM Segments MSI]
[ 0.204826] acpi PNP0A08:00: _OSC: platform does not support
[PCIeHotplug PME]
[ 0.204975] acpi PNP0A08:00: _OSC: OS now controls [AER PCIeCapability]
[ 0.204976] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using
BIOS configuration
[ 0.205250] acpi PNP0A08:00: host bridge window expanded to [mem
0xe0000000-0xfeafffff window]; [mem 0xfe101000-0xfe113fff window] ignored
[ 0.205417] PCI host bridge to bus 0000:00
[ 0.205418] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
[ 0.205420] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
[ 0.205421] pci_bus 0000:00: root bus resource [mem
0x000a0000-0x000bffff window]
[ 0.205422] pci_bus 0000:00: root bus resource [mem
0x000d0000-0x000d3fff window]
[ 0.205423] pci_bus 0000:00: root bus resource [mem
0x000d4000-0x000d7fff window]
[ 0.205423] pci_bus 0000:00: root bus resource [mem
0x000d8000-0x000dbfff window]
[ 0.205424] pci_bus 0000:00: root bus resource [mem
0x000dc000-0x000dffff window]
[ 0.205425] pci_bus 0000:00: root bus resource [mem
0x000e0000-0x000e3fff window]
[ 0.205426] pci_bus 0000:00: root bus resource [mem
0x000e4000-0x000e7fff window]
[ 0.205427] pci_bus 0000:00: root bus resource [mem
0xe0000000-0xfeafffff window]
[ 0.205428] pci_bus 0000:00: root bus resource [bus 00-3e]
[ 0.205434] pci 0000:00:00.0: [8086:0c00] type 00 class 0x060000
[ 0.205506] pci 0000:00:01.0: [8086:0c01] type 01 class 0x060400
[ 0.205531] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[ 0.205610] pci 0000:00:01.0: System wakeup disabled by ACPI
[ 0.205657] pci 0000:00:14.0: [8086:8cb1] type 00 class 0x0c0330
[ 0.205679] pci 0000:00:14.0: reg 0x10: [mem 0xf7f00000-0xf7f0ffff 64bit]
[ 0.205723] pci 0000:00:14.0: PME# supported from D3hot D3cold
[ 0.205768] pci 0000:00:14.0: System wakeup disabled by ACPI
[ 0.205798] pci 0000:00:16.0: [8086:8cba] type 00 class 0x078000
[ 0.205821] pci 0000:00:16.0: reg 0x10: [mem 0xf7f19000-0xf7f1900f 64bit]
[ 0.205868] pci 0000:00:16.0: PME# supported from D0 D3hot D3cold
[ 0.205970] pci 0000:00:1a.0: [8086:8cad] type 00 class 0x0c0320
[ 0.205994] pci 0000:00:1a.0: reg 0x10: [mem 0xf7f17000-0xf7f173ff]
[ 0.206058] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold
[ 0.206105] pci 0000:00:1a.0: System wakeup disabled by ACPI
[ 0.206135] pci 0000:00:1b.0: [8086:8ca0] type 00 class 0x040300
[ 0.206156] pci 0000:00:1b.0: reg 0x10: [mem 0xf7f10000-0xf7f13fff 64bit]
[ 0.206207] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[ 0.206274] pci 0000:00:1b.0: System wakeup disabled by ACPI
[ 0.206303] pci 0000:00:1c.0: [8086:8c90] type 01 class 0x060400
[ 0.206365] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[ 0.206449] pci 0000:00:1c.0: System wakeup disabled by ACPI
[ 0.206480] pci 0000:00:1c.5: [8086:8c9a] type 01 class 0x060400
[ 0.206534] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold
[ 0.206616] pci 0000:00:1c.5: System wakeup disabled by ACPI
[ 0.206645] pci 0000:00:1c.6: [8086:244e] type 01 class 0x060401
[ 0.206699] pci 0000:00:1c.6: PME# supported from D0 D3hot D3cold
[ 0.206781] pci 0000:00:1c.6: System wakeup disabled by ACPI
[ 0.206812] pci 0000:00:1d.0: [8086:8ca6] type 00 class 0x0c0320
[ 0.206836] pci 0000:00:1d.0: reg 0x10: [mem 0xf7f16000-0xf7f163ff]
[ 0.206899] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold
[ 0.206946] pci 0000:00:1d.0: System wakeup disabled by ACPI
[ 0.206977] pci 0000:00:1f.0: [8086:8cc4] type 00 class 0x060100
[ 0.207121] pci 0000:00:1f.2: [8086:8c82] type 00 class 0x010601
[ 0.207139] pci 0000:00:1f.2: reg 0x10: [io 0xf070-0xf077]
[ 0.207145] pci 0000:00:1f.2: reg 0x14: [io 0xf060-0xf063]
[ 0.207151] pci 0000:00:1f.2: reg 0x18: [io 0xf050-0xf057]
[ 0.207157] pci 0000:00:1f.2: reg 0x1c: [io 0xf040-0xf043]
[ 0.207163] pci 0000:00:1f.2: reg 0x20: [io 0xf020-0xf03f]
[ 0.207169] pci 0000:00:1f.2: reg 0x24: [mem 0xf7f15000-0xf7f157ff]
[ 0.207192] pci 0000:00:1f.2: PME# supported from D3hot
[ 0.207251] pci 0000:00:1f.3: [8086:8ca2] type 00 class 0x0c0500
[ 0.207264] pci 0000:00:1f.3: reg 0x10: [mem 0xf7f14000-0xf7f140ff 64bit]
[ 0.207281] pci 0000:00:1f.3: reg 0x20: [io 0xf000-0xf01f]
[ 0.207380] pci 0000:01:00.0: [1002:6899] type 00 class 0x030000
[ 0.207398] pci 0000:01:00.0: reg 0x10: [mem 0xe0000000-0xefffffff 64bit
pref]
[ 0.207405] pci 0000:01:00.0: reg 0x18: [mem 0xf7e20000-0xf7e3ffff 64bit]
[ 0.207410] pci 0000:01:00.0: reg 0x20: [io 0xe000-0xe0ff]
[ 0.207420] pci 0000:01:00.0: reg 0x30: [mem 0xf7e00000-0xf7e1ffff pref]
[ 0.207440] pci 0000:01:00.0: supports D1 D2
[ 0.207455] pci 0000:01:00.0: System wakeup disabled by ACPI
[ 0.207482] pci 0000:01:00.1: [1002:aa50] type 00 class 0x040300
[ 0.207499] pci 0000:01:00.1: reg 0x10: [mem 0xf7e40000-0xf7e43fff 64bit]
[ 0.207539] pci 0000:01:00.1: supports D1 D2
[ 0.215970] pci 0000:00:01.0: PCI bridge to [bus 01]
[ 0.215972] pci 0000:00:01.0: bridge window [io 0xe000-0xefff]
[ 0.215974] pci 0000:00:01.0: bridge window [mem 0xf7e00000-0xf7efffff]
[ 0.215976] pci 0000:00:01.0: bridge window [mem 0xe0000000-0xefffffff
64bit pref]
[ 0.216047] acpiphp: Slot [1] registered
[ 0.216051] pci 0000:00:1c.0: PCI bridge to [bus 02]
[ 0.216131] pci 0000:03:00.0: [10ec:8168] type 00 class 0x020000
[ 0.216167] pci 0000:03:00.0: reg 0x10: [io 0xd000-0xd0ff]
[ 0.216193] pci 0000:03:00.0: reg 0x18: [mem 0xf7d00000-0xf7d00fff 64bit]
[ 0.216210] pci 0000:03:00.0: reg 0x20: [mem 0xf0000000-0xf0003fff 64bit
pref]
[ 0.216277] pci 0000:03:00.0: supports D1 D2
[ 0.216278] pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.216345] pci 0000:03:00.0: System wakeup disabled by ACPI
[ 0.227978] pci 0000:00:1c.5: PCI bridge to [bus 03]
[ 0.227981] pci 0000:00:1c.5: bridge window [io 0xd000-0xdfff]
[ 0.227983] pci 0000:00:1c.5: bridge window [mem 0xf7d00000-0xf7dfffff]
[ 0.227988] pci 0000:00:1c.5: bridge window [mem 0xf0000000-0xf00fffff
64bit pref]
[ 0.228065] pci 0000:04:00.0: [1b21:1080] type 01 class 0x060400
[ 0.228187] pci 0000:04:00.0: supports D1 D2
[ 0.228188] pci 0000:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.228242] pci 0000:04:00.0: System wakeup disabled by ACPI
[ 0.235977] pci 0000:00:1c.6: PCI bridge to [bus 04-05] (subtractive
decode)
[ 0.235985] pci 0000:00:1c.6: bridge window [io 0x0000-0x0cf7 window]
(subtractive decode)
[ 0.235986] pci 0000:00:1c.6: bridge window [io 0x0d00-0xffff window]
(subtractive decode)
[ 0.235987] pci 0000:00:1c.6: bridge window [mem 0x000a0000-0x000bffff
window] (subtractive decode)
[ 0.235988] pci 0000:00:1c.6: bridge window [mem 0x000d0000-0x000d3fff
window] (subtractive decode)
[ 0.235989] pci 0000:00:1c.6: bridge window [mem 0x000d4000-0x000d7fff
window] (subtractive decode)
[ 0.235990] pci 0000:00:1c.6: bridge window [mem 0x000d8000-0x000dbfff
window] (subtractive decode)
[ 0.235991] pci 0000:00:1c.6: bridge window [mem 0x000dc000-0x000dffff
window] (subtractive decode)
[ 0.235991] pci 0000:00:1c.6: bridge window [mem 0x000e0000-0x000e3fff
window] (subtractive decode)
[ 0.235992] pci 0000:00:1c.6: bridge window [mem 0x000e4000-0x000e7fff
window] (subtractive decode)
[ 0.235993] pci 0000:00:1c.6: bridge window [mem 0xe0000000-0xfeafffff
window] (subtractive decode)
[ 0.236102] pci 0000:04:00.0: PCI bridge to [bus 05]
[ 0.236974] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 *11 12 14
15)
[ 0.237027] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 *10 11 12 14
15)
[ 0.237078] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 *10 11 12 14
15)
[ 0.237128] ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 10 11 12 14
15)
[ 0.237179] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 11 12 14
15) *0, disabled.
[ 0.237230] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14
15) *0, disabled.
[ 0.237280] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 *11 12 14
15)
[ 0.237330] ACPI: PCI Interrupt Link [LNKH] (IRQs *3 4 5 6 10 11 12 14
15)
[ 0.237590] ACPI: Enabled 6 GPEs in block 00 to 3F
[ 0.237666] vgaarb: setting as boot device: PCI:0000:01:00.0
[ 0.237668] vgaarb: device added:
PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
[ 0.237668] vgaarb: loaded
[ 0.237669] vgaarb: bridge control possible 0000:01:00.0
[ 0.237729] PCI: Using ACPI for IRQ routing
2) Error output while disassembling the ACPI tables using iasl:
[...]
linux-7x3r:~/acpi # iasl -d ssdt1.dat
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20140214-64
Copyright (c) 2000 - 2014 Intel Corporation
Loading Acpi table from file ssdt1.dat - Length 00003197 (000C7D)
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
Parsing completed
ACPI Error: External method arg count mismatch _SB_.PCI0.LPCB.H_EC.ECWT:
Current 4, attempted 1 (20140214/dmextern-798)
ACPI Error: External method arg count mismatch _SB_.PCI0.LPCB.H_EC.ECWT:
Current 4, attempted 1 (20140214/dmextern-798)
ACPI Error: External method arg count mismatch AC1F: Current 0, attempted 3
(20140214/dmextern-798)
ACPI Error: External method arg count mismatch _SB_.PCI0.LPCB.H_EC.ECWT:
Current 4, attempted 1 (20140214/dmextern-798)
ACPI Error: External method arg count mismatch _SB_.PCI0.LPCB.H_EC.ECWT:
Current 4, attempted 1 (20140214/dmextern-798)
ACPI Error: External method arg count mismatch _SB_.PCI0.LPCB.H_EC.ECWT:
Current 4, attempted 1 (20140214/dmextern-798)
ACPI Error: External method arg count mismatch _SB_.PCI0.LPCB.H_EC.ECWT:
Current 4, attempted 1 (20140214/dmextern-798)
ACPI Error: External method arg count mismatch _SB_.PCI0.LPCB.H_EC.ECWT:
Current 4, attempted 1 (20140214/dmextern-798)
ACPI Error: External method arg count mismatch _SB_.PCI0.LPCB.H_EC.ECWT:
Current 4, attempted 1 (20140214/dmextern-798)
Found 4 external control methods, reparsing with new information
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
Parsing completed
Disassembly completed
ASL Output: ssdt1.dsl - 19756 bytes
[...]
linux-7x3r:~/acpi # iasl -d ssdt5.dat
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20140214-64
Copyright (c) 2000 - 2014 Intel Corporation
Loading Acpi table from file ssdt5.dat - Length 00022581 (005835)
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
Parsing completed
ACPI Error: External method arg count mismatch _SB_.PCI0.PEG0.PEGP.SGPO:
Current 5, attempted 2 (20140214/dmextern-798)
ACPI Error: External method arg count mismatch _SB_.PCI0.PEG0.PEGP.SGPO:
Current 5, attempted 7 (20140214/dmextern-798)
ACPI Error: External method arg count mismatch _SB_.PCI0.PEG0.PEGP.SGPO:
Current 5, attempted 6 (20140214/dmextern-798)
ACPI Error: External method arg count mismatch _SB_.PCI0.PEG0.PEGP.SGPO:
Current 5, attempted 2 (20140214/dmextern-798)
Found 4 external control methods, reparsing with new information
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
Well, I'm really curious what the ACPI developing experts have to say on
this.
Kind regards
5 years, 3 months
Executation of manipulated ACPI code results in compromising any OS
by David Renz
Hello,
maybe some of you can still remember me, since I posted in this mailing
list previously - The relevant postings are:
1)
https://lists.acpica.org/pipermail/devel/2016-August/000945.html
2)
https://lists.acpica.org/pipermail/devel/2015-November/000847.html
At that time I extracted the ACPI code from my Lenovo G710 notebook using
the Windows tool "Read&Write Everything", which I then submitted to
malwr.com. On that site the ACPI code gets executed on a virtualized Cuckoo
Sandbox, afterwards one can see in every detail which numberous effects
this execution resulted in:
https://malwr.com/analysis/ODkxOThjOTk1MDAzNGE4M2JhOWNhNzk1ZTJjM2IyYWQ/
I assume that I'm talking with people who have a decent understanding of
IT-related things, so it almost feels like an insult to me that I have to
exaplain the results of this thorough analysis:
1) "Summery" --> "Files" shows which files are deployed after the ACPI got
executed. Just do some googling on some of these files and draw your own
conclusions.
2) "Summary" --> "Registry Keys" shows (among other things) how an Inprox
server is set up, how security policy changes are made for obvious reasons
and other measurements for carrying through illegitimate data
transfer/enabling remote access. To give only two examples: "
Interface\{85CB6900-4D95-11CF-960C-0080C7F4EE85}\ProxyStubClsid32",
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\6EA7B711503001246845051536B6A26B".
The latter one enables remote access, you might want to have a screenshot
at these hidden registry entries found by GMER:
http://pasteboard.co/N6dOjItFG.png
This misterious user "S-5-18" doesn't appear there, but he appears at
another system log (I can take a screenshot if this as well if required).
3) The section "Summery" --> "Mutexes" telling which mutexes were created
after the ACPI code's execution hopefully don't need any further
explanation.
The extracted ACPI code from my Lenovo G710 can be downloaded from malwr.com
after registering there for free, if anyone would like to check this by
himself.
Now for me (at the present point of time) it's really interesting to read
what Mr. Robert Moore, Senior ACPI developer at Intel, had to say regarding
all this:
https://lists.acpica.org/pipermail/devel/2015-November/000847.html
> I just remembered something about Lenovo machines using one of the ACPI
> tables to install “unwanted software”. If you delete the files, they just
> keep coming back."
[...]
> I don’t think they know what they are talking about. [referring to
malwr.com - anyone who would like to visit their site may feel free to
judge whether these people know what they are talking about (well, what
they are testing in a very sophisticated manner to be concrete)]
[...]
> I don’t know all of the windows internals, but what exactly makes you
> think that this stuff is related to ACPI?
Well, let me think... Maybe it could be related to ACPI, because all what
malwr.com did was to have the extracted ACPI code be executed in a
sandboxed environment to show which modifications this leads to (which
means total a compromise of a Windows system)?
[...]
> I just remembered something about Lenovo machines using one of the ACPI
> tables to install “unwanted software”. If you delete the files, they just
> keep coming back.
Ok, so this time I extracted the ACPI code from a completely different
system (a desktop PC based on an MSI Z97 PC Mate mainboard) - And guess
what? The results are EXACTLY the same:
https://malwr.com/analysis/MGJiYjFlZmExYWY3NGYwZGE0YmIzNWU5YTdmNDc2YTY/
>From my personal point of view I can't understand at all why Mr. Moore
wrote these comments full of 'non-competent statements' ("what exactly
makes you think that this stuff is related to ACPI?")?
The download links from my previous postings are dead now, but I will soon
uploaded the disassembled ACPI code, share the link and also describe how
the exection of this code compromised any Linux system as well.
Kind regards
5 years, 3 months
[RFC PATCH 0/7] ACPICA: Tables: Cleanup table sanity checks
by Lv Zheng
Originally AML table sanity check is only done for Load opcode, as
acpi_tb_compare_tables() is only invoked in
acpi_tb_install_standard_table(). While LoadTable opcode cannot be covered
as it directly invokes acpi_tb_load_table() without invoking
acpi_tb_install_standard_table(). Furthermore, standard table load also
cannot be covered as acpi_ns_load_table() is invoked instead of
acpi_tb_install_standard_table() and acpi_tb_load_table().
So it becomes a problem if a duplicate table is in RSDT/XSDT, there is no
such check implemented for static load tables and LoadTable opcode.
This patchset combines code paths (in return reduces some redundant code
blocks and enhances checks/locks) so that duplicate table detection can be
applied to all cases.
Lv Zheng (7):
ACPICA: Tables: Cleanup table handler invokers
ACPICA: Tables: Add sanity check for load_table opcode
ACPICA: Tables: Add sanity check for table install
ACPICA: Tables: Fix an unwanted exception for table reloading
ACPICA: Tables: Enable acpi_ut_is_aml_table() for all ACPICA modules
ACPICA: Tables: Add sanity check for static table load
ACPICA: Tables: Change table comparison using table header for static
load tables
drivers/acpi/acpica/actables.h | 7 +-
drivers/acpi/acpica/acutils.h | 4 +-
drivers/acpi/acpica/exconfig.c | 2 +-
drivers/acpi/acpica/nsload.c | 18 ---
drivers/acpi/acpica/tbdata.c | 288 ++++++++++++++++++++++++++++++++++++-----
drivers/acpi/acpica/tbinstal.c | 197 ++++++----------------------
drivers/acpi/acpica/tbxfload.c | 46 +------
drivers/acpi/acpica/utmisc.c | 27 ++--
include/acpi/actbl.h | 1 +
9 files changed, 325 insertions(+), 265 deletions(-)
--
2.7.4
5 years, 3 months
Re: [Devel] [RFC PATCH 0/7] ACPICA: Tables: Cleanup table sanity checks
by Zheng, Lv
Hi,
> From: Hans de Goede [mailto:hdegoede@redhat.com]
> Subject: Re: [RFC PATCH 0/7] ACPICA: Tables: Cleanup table sanity checks
>
> Hi,
>
> On 15-03-17 07:36, Lv Zheng wrote:
> > Originally AML table sanity check is only done for Load opcode, as
> > acpi_tb_compare_tables() is only invoked in
> > acpi_tb_install_standard_table(). While LoadTable opcode cannot be covered
> > as it directly invokes acpi_tb_load_table() without invoking
> > acpi_tb_install_standard_table(). Furthermore, standard table load also
> > cannot be covered as acpi_ns_load_table() is invoked instead of
> > acpi_tb_install_standard_table() and acpi_tb_load_table().
> >
> > So it becomes a problem if a duplicate table is in RSDT/XSDT, there is no
> > such check implemented for static load tables and LoadTable opcode.
> >
> > This patchset combines code paths (in return reduces some redundant code
> > blocks and enhances checks/locks) so that duplicate table detection can be
> > applied to all cases.
>
> I can confirm that this series fixes the errors I was seeing on my
> GPD win machine.
Ok, thanks for the test and the report.
> Note as explained in my reply to Robert I believe that
> the last patch from the series can be dropped:
>
> "On 15-03-17 04:05, Moore, Robert wrote:
> > And I would suppose a refinement would be:
> >
> > Compare headers
> > If headers match, compare entire tables.
>
> The existing memcmp already does that since the header is in the
> front, and memcmp will stop on the first difference, so there
> is no need to change anything."
>
> As Robert mentions we really a should compare the entire table
> if the checksums match since an 8 bit checksum is really weak and
> if we want to do that a simple memcmp will suffice as that will
> already exit directly if the checksum mismatches as the checksum
> is before the actual data.
Maybe the suggestion is made on the previous fact.
The previous design prevents such duplicate tables from being
installed. It surely is able to prevent same table from being
installed twice.
Under the previous design, we should do the duplicate table
detection in acpi_tb_verify_temp_table() which is exact the API used
before the table is installed to the global table list.
But there is a special logic for table install:
Linux can only use limited slots to map ACPI tables.
Thus most of the time, we can only map the table header.
The series now follows your idea, split sanity checks into 2 levels:
1. for table install, only check "address" and "memory types"
2. for table load, check "table content" to detect duplicate tables
And since the table load doesn't have similar restriction, we seem
to be able to map the whole table to compare.
And I noticed comments in acpi_tb_compare_tables(). It looks like
comparing the Whole table rather than comparing the table header is
a design decision made several years ago due to some reasons.
As such:
1. With new design, we are able to compare the whole table
2. Comparing whole table rather than comparing table header looks
like a determined design choice
I made it the last patch and a separate one so that we can drop
it at any time.
Thanks and best regards
Lv
>
>
>
> >
> > Lv Zheng (7):
> > ACPICA: Tables: Cleanup table handler invokers
> > ACPICA: Tables: Add sanity check for load_table opcode
> > ACPICA: Tables: Add sanity check for table install
> > ACPICA: Tables: Fix an unwanted exception for table reloading
> > ACPICA: Tables: Enable acpi_ut_is_aml_table() for all ACPICA modules
> > ACPICA: Tables: Add sanity check for static table load
> > ACPICA: Tables: Change table comparison using table header for static
> > load tables
> >
> > drivers/acpi/acpica/actables.h | 7 +-
> > drivers/acpi/acpica/acutils.h | 4 +-
> > drivers/acpi/acpica/exconfig.c | 2 +-
> > drivers/acpi/acpica/nsload.c | 18 ---
> > drivers/acpi/acpica/tbdata.c | 288 ++++++++++++++++++++++++++++++++++++-----
> > drivers/acpi/acpica/tbinstal.c | 197 ++++++----------------------
> > drivers/acpi/acpica/tbxfload.c | 46 +------
> > drivers/acpi/acpica/utmisc.c | 27 ++--
> > include/acpi/actbl.h | 1 +
> > 9 files changed, 325 insertions(+), 265 deletions(-)
> >
5 years, 3 months
Re: [Devel] [PATCH] ACPICA: Log Exceptions and Errors as warning while loading extra tables
by Zheng, Lv
Hi, Hans
> From: Hans de Goede [mailto:hdegoede@redhat.com]
> Subject: Re: [PATCH] ACPICA: Log Exceptions and Errors as warning while loading extra tables
>
> Hi,
>
> On 14-03-17 09:15, Zheng, Lv wrote:
> > Hi, Hans
> >
> >> From: Hans de Goede [mailto:hdegoede@redhat.com]
> >> Subject: Re: [PATCH] ACPICA: Log Exceptions and Errors as warning while loading extra tables
> >>
> >> Hi,
> >>
> >> On 13-03-17 10:52, Zheng, Lv wrote:
> >>> Hi, Hans
> >>>
> >>> For log level issue, is this fix useful for you?
> >>> https://github.com/acpica/acpica/pull/121/commits/a505d3942
> >>
> >> That fixes reloading already loaded tables, the problem I'm
> >> getting errors about its loading a different table with identical
> >> contents.
> >>
> >> I will look into your suggestion to do something similar to
> >> AcpiTbInstallStandardTable using AcpiTbCompareTables for the
> >> SSDT tables. I will send a new patch when I can make some time
> >> to look into this.
> >
> > I just completed a prototype here:
> > https://github.com/acpica/acpica/pull/121
> >
> > I guess the original "duplicate table check" couldn't cover static SSDTs.
> > Actually the duplicate table check should be a sanity check of table load.
> > And for table install, we should have a different sanity check like:
> > https://github.com/acpica/acpica/pull/121/commits/6e825cae5e5
> > I'm not sure if this is what you want.
>
> This checks for having 2 table_descriptors pointing to the same table
> (address in memory). But in my case there are 2 identical copies of
> the table at 2 different addresses in memory, so this won't work.
>
> After looking at this a bit myself, I think fixing this is actually
> quite easy (now that you've pointed me to acpi_tb_install_standard_table()
>
> I've come up with the attached patch to fix this. I will give this a test
> spin and then submit it officially (assuming it works).
In the pull request, there are 4 fixes:
1. add table install sanity check by detecting duplicates with table address and table type.
2. extend table load sanity check to LoadTable opcode.
3. extend table load sanity check to static loaded SSDTs - I think this should be able to cover your case.
4. if install/load sanity checks detect duplicate tables, they return AE_ALREADY_EXISTS and the error is silently discarded.
That's the whole story for the pull request.
I think you only checked one of them.
Thanks and best regards
Lv
5 years, 3 months
Re: [Devel] [PATCH v2] ACPICA: Detect duplicate SSDT tables
by Zheng, Lv
Hi, Hans
> From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Hans de
> Goede
> Subject: [PATCH v2] ACPICA: Detect duplicate SSDT tables
>
> Some machines have the exact (byte for byte) same SSDT tables multiple
> times in the root_table_list. Detect this and silently skip the duplicates
> rather then printing a scary looking set of errors.
The problems are:
1. ACPICA messes up table install sanity check and table load sanity check.
For table install check, we only need to check address and table type (physical address or virtual address).
For table load check, we may do byte for byte comparison.
2. ACPICA only implements table load sanity check for Load opcode, it doesn't cover LoadTable opcode and static loaded tables.
So this really needs not only the following change, but a slight bigger one.
Thanks and best regards
Lv
>
> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
> ---
> Changes in v2:
> -Use existing acpi_tb_compare_tables helper
> ---
> drivers/acpi/acpica/actables.h | 2 ++
> drivers/acpi/acpica/tbinstal.c | 6 +-----
> drivers/acpi/acpica/tbxfload.c | 27 ++++++++++++++++++++++++++-
> 3 files changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
> index c8da453..d50437c 100644
> --- a/drivers/acpi/acpica/actables.h
> +++ b/drivers/acpi/acpica/actables.h
> @@ -99,6 +99,8 @@ acpi_tb_find_table(char *signature,
> /*
> * tbinstal - Table removal and deletion
> */
> +u8 acpi_tb_compare_tables(struct acpi_table_desc *table_desc, u32 table_index);
> +
> acpi_status acpi_tb_resize_root_table_list(void);
>
> acpi_status acpi_tb_validate_table(struct acpi_table_desc *table_desc);
> diff --git a/drivers/acpi/acpica/tbinstal.c b/drivers/acpi/acpica/tbinstal.c
> index 4620f3c..1431bfa 100644
> --- a/drivers/acpi/acpica/tbinstal.c
> +++ b/drivers/acpi/acpica/tbinstal.c
> @@ -48,10 +48,6 @@
> #define _COMPONENT ACPI_TABLES
> ACPI_MODULE_NAME("tbinstal")
>
> -/* Local prototypes */
> -static u8
> -acpi_tb_compare_tables(struct acpi_table_desc *table_desc, u32 table_index);
> -
> /*******************************************************************************
> *
> * FUNCTION: acpi_tb_compare_tables
> @@ -66,7 +62,7 @@ acpi_tb_compare_tables(struct acpi_table_desc *table_desc, u32 table_index);
> *
> ******************************************************************************/
>
> -static u8
> +u8
> acpi_tb_compare_tables(struct acpi_table_desc *table_desc, u32 table_index)
> {
> acpi_status status = AE_OK;
> diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
> index b71ce3b..2f718b0 100644
> --- a/drivers/acpi/acpica/tbxfload.c
> +++ b/drivers/acpi/acpica/tbxfload.c
> @@ -125,6 +125,30 @@ ACPI_EXPORT_SYMBOL_INIT(acpi_load_tables)
>
> /*******************************************************************************
> *
> + * FUNCTION: acpi_tb_find_duplicate_ssdt
> + *
> + * PARAMETERS: table - validated acpi_table_desc of table to check
> + * index - index of table to find a duplicate of
> + *
> + * RETURN: TRUE if a duplicate is found, FALSE if not
> + *
> + * DESCRIPTION: Private helper function for acpi_tb_load_namespace to
> + * avoid trying to load duplicate ssdt tables
> + *
> + ******************************************************************************/
> +static u8 acpi_tb_find_duplicate_ssdt(struct acpi_table_desc *table, u32 index)
> +{
> + u32 i;
> +
> + for (i = 0; i < index; ++i)
> + if (acpi_tb_compare_tables(table, i))
> + return TRUE;
> +
> + return FALSE;
> +}
> +
> +/*******************************************************************************
> + *
> * FUNCTION: acpi_tb_load_namespace
> *
> * PARAMETERS: None
> @@ -212,7 +236,8 @@ acpi_status acpi_tb_load_namespace(void)
> ACPI_SIG_PSDT)
> && !ACPI_COMPARE_NAME(table->signature.ascii,
> ACPI_SIG_OSDT))
> - || ACPI_FAILURE(acpi_tb_validate_table(table))) {
> + || ACPI_FAILURE(acpi_tb_validate_table(table))
> + || acpi_tb_find_duplicate_ssdt(table, i)) {
> continue;
> }
>
> --
> 2.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
5 years, 3 months
