ACPICA version 20160831 released
by Moore, Robert
31 August 2016. Summary of changes for version 20160831:
This release is available at https://acpica.org/downloads
1) ACPICA kernel-resident subsystem:
Improve support for the so-called "module-level code", which is defined to be math, logical and control AML opcodes that appear outside of any control method. This change improves the support by adding more opcodes that can be executed in the manner. Some other issues have been solved, and the ASL grammar changes to support such code under all scope operators (Device, etc.) are complete. Lv Zheng.
UEFI support: these OSL functions have been implemented. This is an additional step toward supporting the AcpiExec utility natively (with full hardware access) under UEFI. Marcelo Ferreira.
AcpiOsReadPciConfiguration
AcpiOsWritePciConfiguration
Fixed a possible mutex error during control method auto-serialization. Lv Zheng.
Updated support for the Generic Address Structure by fully implementing all GAS fields when a 32-bit address is expanded to a 64-bit GAS. Lv Zheng.
Updated the return value for the internal _OSI method. Instead of 0xFFFFFFFF, the "Ones" value is now returned, which is 0xFFFFFFFFFFFFFFFF for 64-bit ACPI tables. This fixes an incompatibility with other ACPI implementations, and will be reflected and clarified in the next version of the ACPI specification.
Implemented two new table events that can be passed to an ACPICA table handler. These events are used to indicate a table installation or uninstallation. These events are used in addition to existed table load and unload events. Lv Zheng.
Implemented a cleanup for all internal string-to-integer conversions. Consolidate multiple versions of this functionality and limit possible bases to either 10 or 16 to simplify the code. Adds a new file, utstrtoul64.
Cleanup the inclusion order of the various compiler-specific headers. This simplifies build configuration management. The compiler-specific headers are now split out from the host-specific headers. Lv Zheng.
Example Code and Data Size: These are the sizes for the OS-independent acpica.lib produced by the Microsoft Visual C++ 9.0 32-bit compiler. The debug version of the code includes the debug output trace mechanism and has a much larger code and data size.
Current Release:
Non-Debug Version: 140.1K Code, 58.1K Data, 198.1K Total
Debug Version: 200.3K Code, 82.1K Data, 282.4K Total
2) iASL Compiler/Disassembler and Tools:
iASL/AcpiExec: Added a command line option to display the build date/time of the tool (-vd). This can be useful to verify that the correct version of the tools are being used.
AML Debugger: Implemented a new subcommand ("execute predef") to execute all predefined control methods and names within the current namespace. This can be useful for debugging problems with ACPI tables and the ACPI namespace.
5 years, 10 months
Re: [Devel] [PATCH] iasl:iort fix the incorrect MappingOffset value for ITS group
by Zheng, Lv
Hi,
> From: Dennis Chen [mailto:[email protected]]
> Subject: [PATCH] iasl:iort fix the incorrect MappingOffset value for ITS group
>
> According to the IORT spec[1], the *Mapping Offset* field of the
> ITS group node is always 0 since there isn't ID mapping for this kind
> of node. Current iasl codes will assign a wrong value for this field,
> for instance, below is an IORT ITS group node data segment created
> by existing iasl tool:
>
> [031h 0049 1] Type : 00
> [032h 0050 2] Length : 001C
> [034h 0052 1] Revision : 00
> [035h 0053 4] Reserved : 00000000
> [039h 0057 4] Mapping Count : 00000000
> [03Dh 0061 4] Mapping Offset : 0000001C
>
> [041h 0065 4] ItsCount : 00000002
> [045h 0069 4] Identifiers : 00000000
> [049h 0073 4] Identifiers : 00000001
>
> We can see from above that the *Mapping Offset* has been assigned the
> value 0x1C while not 0x0.
What kind of real issue can be caused by this value?
> After applied this patch, the new data segment
> generated will be:
>
> [031h 0049 1] Type : 00
> [032h 0050 2] Length : 001C
> [034h 0052 1] Revision : 00
> [035h 0053 4] Reserved : 00000000
> [039h 0057 4] Mapping Count : 00000000
> [03Dh 0061 4] Mapping Offset : 00000000
>
> [041h 0065 4] ItsCount : 00000002
> [045h 0069 4] Identifiers : 00000000
> [049h 0073 4] Identifiers : 00000001
>
> Notice that the *Mapping Offset* filed has been set the correct value according
> to the spec.
>
> [1]http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_R...
>
> Signed-off-by: Dennis Chen <dennis.chen(a)arm.com>
> Cc: Lv Zheng <lv.zheng(a)intel.com>
> Cc: Robert Moore <robert.moore(a)intel.com>
> ---
> source/compiler/dttable1.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/source/compiler/dttable1.c b/source/compiler/dttable1.c
> index cacd9de..a620dcc 100644
> --- a/source/compiler/dttable1.c
> +++ b/source/compiler/dttable1.c
> @@ -1568,7 +1568,10 @@ DtCompileIort (
>
> /* Compile Array of ID mappings */
>
> - IortNode->MappingOffset = NodeLength;
> + /* For ITS group node, the MappingOffset field is always 0 */
> + if (IortNode->Type != ACPI_IORT_NODE_ITS_GROUP)
> + IortNode->MappingOffset = NodeLength;
> +
You have coding style issues here:
1. No tab in ACPICA upstream, you need to use 4 spaces.
2. For single line comment, you need to put an empty line before/after it.
> IdMappingNumber = 0;
> while (*PFieldList)
> {
IMO, the better fix should be relying on (IdMappingNumber == 0),
Rather than relying on (IortNode->Type != ACPI_IORT_NODE_ITS_GROUP).
Thanks
Lv
5 years, 10 months
[PATCH] AcpiExec: Add in missing TableEvents INSTALL and UNINSTALL
by Colin King
From: Colin Ian King <colin.king(a)canonical.com>
commit ed6a5fbc694f3a27d93014391aa9a6f6fe490461 ("Tables: Add
new table events indicating table installation/uninstallation") added
new table events but the TableEvents array was not updated with
these two new events. Update TableEvents with the new INSTALL
and UNINSTALL event types.
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
---
source/tools/acpiexec/aehandlers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/source/tools/acpiexec/aehandlers.c b/source/tools/acpiexec/aehandlers.c
index f08ffbe..b52e4d8 100644
--- a/source/tools/acpiexec/aehandlers.c
+++ b/source/tools/acpiexec/aehandlers.c
@@ -187,6 +187,8 @@ static char *TableEvents[] =
{
"LOAD",
"UNLOAD",
+ "INSTALL",
+ "UNINSTALL",
"UNKNOWN"
};
#endif /* !ACPI_REDUCED_HARDWARE */
--
2.9.3
5 years, 10 months
Re: [Devel] [PATCH v7 14/15] arm64, acpi, numa: NUMA support based on SRAT and SLIT
by Hanjun Guo
On 2016/8/15 23:35, Catalin Marinas wrote:
> On Tue, May 24, 2016 at 03:35:44PM -0700, David Daney wrote:
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index aee323b..4b13ecd 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -113,4 +113,12 @@ static inline const char *acpi_get_enable_method(int cpu)
>> pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
>> #endif
>>
>> +#ifdef CONFIG_ACPI_NUMA
>> +int arm64_acpi_numa_init(void);
>> +int acpi_numa_get_nid(unsigned int cpu, u64 hwid);
>> +#else
>> +static inline int arm64_acpi_numa_init(void) { return -ENOSYS; }
>> +static inline int acpi_numa_get_nid(unsigned int cpu, u64 hwid) { return NUMA_NO_NODE; }
>> +#endif /* CONFIG_ACPI_NUMA */
>> +
>> #endif /*_ASM_ACPI_H*/
>
> Apparently this doesn't always build since asm/acpi.h is conditionally
> included from linux/acpi.h only when CONFIG_ACPI is enabled. Disabling
> this option on arm64 leads to:
>
> arch/arm64/mm/numa.c: In function ‘arm64_numa_init’:
> arch/arm64/mm/numa.c:395:24: error: ‘arm64_acpi_numa_init’ undeclared (first use in this function)
> if (!acpi_disabled && !numa_init(arm64_acpi_numa_init))
>
> I'll fix it in arch/arm64 by including asm/acpi.h directly as we do in a
> couple of other files:
>
> ------------------8<------------------------------
> From 9a83bf400e0b4ef066b83eeaecdbca909b8491ea Mon Sep 17 00:00:00 2001
> From: Catalin Marinas <catalin.marinas(a)arm.com>
> Date: Mon, 15 Aug 2016 16:33:10 +0100
> Subject: [PATCH] arm64: Fix NUMA build error when !CONFIG_ACPI
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Since asm/acpi.h is only included by linux/acpi.h when CONFIG_ACPI is
> enabled, disabling the latter leads to the following build error on
> arm64:
>
> arch/arm64/mm/numa.c: In function ‘arm64_numa_init’:
> arch/arm64/mm/numa.c:395:24: error: ‘arm64_acpi_numa_init’ undeclared (first use in this function)
> if (!acpi_disabled && !numa_init(arm64_acpi_numa_init))
>
> This patch include the asm/acpi.h explicitly in arch/arm64/mm/numa.c for
> the arm64_acpi_numa_init() definition.
>
> Fixes: d8b47fca8c23 ("arm64, ACPI, NUMA: NUMA support based on SRAT and SLIT")
> Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
> ---
> arch/arm64/mm/numa.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index c7fe3ec70774..5bb15eab6f00 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -23,6 +23,8 @@
> #include <linux/module.h>
> #include <linux/of.h>
>
> +#include <asm/acpi.h>
> +
> struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
> EXPORT_SYMBOL(node_data);
> nodemask_t numa_nodes_parsed __initdata;
Thanks a lot!
Reviewed-by: Hanjun Guo <hanjun.guo(a)linaro.org>
Hanjun
5 years, 10 months
Re: [Devel] [PATCH] ACPICA: Remove unnecessary '\n' in the end of ACPI_INFO output
by Zheng, Lv
> From: Alexander Kuleshov [mailto:[email protected]]
> Subject: [PATCH] ACPICA: Remove unnecessary '\n' in the end of
> ACPI_INFO output
>
> as the ACPI_INFO already prints `\n` in the end itself.
[Lv Zheng]
Looks good.
Acked-by: Lv Zheng <lv.zheng(a)intel.com>
However this patch should go through ACPICA upstream.
Thanks
-Lv
>
> Signed-off-by: Alexander Kuleshov <kuleshovmail(a)gmail.com>
> ---
> drivers/acpi/acpica/tbxfload.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
> index ac71abc..e7119b7 100644
> --- a/drivers/acpi/acpica/tbxfload.c
> +++ b/drivers/acpi/acpica/tbxfload.c
> @@ -240,7 +240,7 @@ acpi_status acpi_tb_load_namespace(void)
> }
>
> if (!tables_failed) {
> - ACPI_INFO(("%u ACPI AML tables successfully acquired and
> loaded\n", tables_loaded));
> + ACPI_INFO(("%u ACPI AML tables successfully acquired and
> loaded", tables_loaded));
> } else {
> ACPI_ERROR((AE_INFO,
> "%u table load failures, %u successful",
> --
> 2.8.0.rc3.1353.gea9bdc0
5 years, 10 months
Strange behavior of ACPI code
by David Renz
Hello,
I addressed this issue before on the ACPI developers' mailing list, where I
observed a strange/suspicious behavior of my system's ACPI code in the case
of a Lenovo G710 notebook. I concluded that this might be explained by the
fact that Lenovo employs ACPI code in order to install harmless crapware on
Windows, but finally I can definitely say that this conclusion can not be
true, since the ACPI code of four different systems I'm using, which I
extracted and submitted to malwr.com, led to the same results in each case.
E. g., this is the result for the ACPI I extracted from an AMD x64 desktop
PC:
https://malwr.com/analysis/ODkxOThjOTk1MDAzNGE4M2JhOWNhNzk1ZTJjM2IyYWQ/
It shows what happens when the ACPI code gets executed on a Windows system,
and if you google some of files which get deployed or take a look at the
registry modifications being made, it should be obvious to everyone that it
compromises the system in order to gain full remote access over it and
forward its' network traffic (which I can also observe in Wireshark).
Recently someone from the Comodo support also confirmed me that my system
is compromised, but even the Comodo software itself seems to have been
gotten manipulated, so the Comodo firewall doesn't block the remote access
(they're investigating about this now).
However, this ACPI not only compromises Windows systems, but also every
Linux and BSD distro I've tested for the purpose of analysis so far. The
files in this Dropbox folder will give you only a first impression of this:
https://www.dropbox.com/sh/x6vf2fqsbqdx0k8/AACdgsdbN_UA4w2XDaob9Maia?dl=0
"modified_files.out" shows a list of files having been modified during the
first 10 minutes after the first boot of a freshly installed system,
dmesg.out shows various ACPI related errors and the netstat output shows
that the UDP and UDP6 ports 50988 and 47815 are open, which shouldn't be
the case normally. (Wireshark gives the same impression of traffic being
forwared like it does on Windows.)
The folder also contains the ACPI code extracted and disassembled using the
IASL code.
Would anyone be able to perform a debugging of this code in order to make
visible what its execution on a Linux system does in detail?
Thanks in advance and kind regards
David
5 years, 11 months
Re: [Devel] acpi: broken suspend to RAM with v4.7-rc1
by Zheng, Lv
Hi, Andrey
> From: Andrey Skvortsov [mailto:[email protected]]
> Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
>
> On 24 Jun, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Andrey Skvortsov [mailto:[email protected]]
> > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
> > >
> > > Hi Lv,
> > >
> > > On 13 Jun, Zheng, Lv wrote:
> > > > > From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi-
> > > > > owner(a)vger.kernel.org] On Behalf Of Rafael J. Wysocki
> > > > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
> > > > >
> > > > > On Saturday, June 11, 2016 01:49:22 PM Andrey Skvortsov wrote:
> > > > > > On 10 Jun, Rafael J. Wysocki wrote:
> > > > > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken
> suspend
> > > to RAM.
> > > > > > > > Laptop doesn't finish suspend to RAM process (disks are off,
> but
> > > > > > > > WiFi and Power LEDs are still on). The only way to get it out of
> > > > > > > > this state, is to turn the power off.
> > > > > > > >
> > > > > > > > I've bisected the issue to commit 66b1ed5aa8dd25
> > > > > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset
> > > support
> > > > > > > > for acpi_hw_write()].
> > > > > > > >
> > > > > > > > If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to
> RAM
> > > > > > > > is working again.
> > > > > > > >
> > > > > > > > The cause of this problem is that after this commit write to
> > > PM1A
> > > > > > > > Control Block (16-bit register) is done using two 8-bit writes.
> > > > > > > > If I force this write to be 16-bit, then all is working as before.
> > > > > > > >
> > > > > > > > To get it working 'access_width' for PM1A Control Block
> needs to
> > > > > > > > be 2 (16-bit), but it's 1 (8-bit).
> > > > [Lv Zheng]
> > > > Could you send me the acpidump of the machine?
> > > Here it is
> > >
> https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpid
> > > ump.bin
> > [Lv Zheng]
> > I've been trying to download it these days but all failed.
> > Could you send an off-list email to me with this attached?
> Strange. I've check now. The link above is working, but I see that
> part of the link above is moved to the next line.
> Anyway I resend you all files off-list.
>
>
> > > > > > > > The root of the problem seems to be not the commit
> > > > > 66b1ed5aa8dd25
> > > > > > > > itself, but the ACPI tables in BIOS where wrong access_width
> > > > > > > > comes from. I fixed problem in FACP table, put it in initrd to
> > > > > > > > override FACP table from BIOS. This fixed the issue, suspend
> to
> > > > > > > > RAM is working now again.
> > > > > > > >
> > > > > > > > But I'm not sure whether is this proper fix for this problem.
> > > > > > > > Is there any place in the kernel, where such ACPI quirks are
> placed?
> > > > [Lv Zheng]
> > > > My question would be:
> > > > Does Windows behave correctly for this table?
> > > Yes, suspend to RAM is working under Windows Vista.
> > > IIRC it worked under Windows XP too.
> > >
> > > > However there is a real case showing that there are real tables need
> us to
> > > correctly support BitWidth/BitOffset.
> > > > Here is the information for you to refer:
> > > >
> http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
> > > >
> > > > > > >
> > > > > > > Well, if the commit in question caused a problem to happen for
> > > you,
> > > > > > > it also might cause similar problems to happen elsewhere.
> > > > > > >
> > > > > > > It looks like we'll need to revert that commit.
> > > > > > Hi,
> > > > > >
> > > > > > or maybe to reset access_width AnyAcc from FACP table only for
> > > PM1A
> > > > > > control register or even for all registers? This will fix the issue too.
> > > > >
> > > > > That's a good idea actually.
> > > > >
> > > > > > diff --git a/drivers/acpi/acpica/tbfadt.c
> > > > > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
> > > > > > --- a/drivers/acpi/acpica/tbfadt.c
> > > > > > +++ b/drivers/acpi/acpica/tbfadt.c
> > > > > > @@ -714,7 +714,14 @@ static void
> > > acpi_tb_setup_fadt_registers(void)
> > > > > > }
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > + /*
> > > > > > + * Reset access_width in the GAS for PM1A control register
> to
> > > > > > + * undefined value. Because in some cases this field contains
> > > > > > + * wrong value.
> > > > > > + */
> > > > > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0;
> > > > >
> > > > > OK, let's see what Bob and Lv think about that.
> > > > [Lv Zheng]
> > > > There is a commit in 4.7-rc2:
> > > >
> > >
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
> > > 7f9bef9d
> > > > Have you tried if the problem still exists in 4.7-rc2?
> > > I've just tried v4.7-rc3. It contains commit 7f9bef9d and the problem
> > > exists there too.
> > [Lv Zheng]
> > IMO, for the time being, you can use quirks.
> > Booting your kernel with the following parameters:
> >
> > acpi=rsdt
> > Or
> > acpi_force_32bit_fadt_addr
> > Or
> > Both
>
> Rafael reverted commit, so I'm ok now.
>
> Actually acpi_force_32bit_fadt_addr will not help here, because it's take
> effect only if address64 != address32. But here these addresses are
> the same, therefore access_width is taken from extended address.
[Lv Zheng]
This sounds strange.
My recent investigation shows that Windows may favor 32bit fadt address.
So we need to get this quirk working.
I filed a bug here, hope you can help me to dig this a bit further:
https://bugzilla.kernel.org/show_bug.cgi?id=151501
Thanks in advance.
Best regards
Lv
>
> http://lxr.free-electrons.com/source/drivers/acpi/acpica/tbfadt.c#L576
>
>
> acpi=rsdt helps. Thanks for the information about this option. I
> missed it, when I read documentation.
>
>
>
> --
> Best regards,
> Andrey Skvortsov
>
5 years, 11 months
Fwd: Linux getting compromised by the execution of ACPI code
by David Renz
By mistake I've sent my reply only to Rudolf Marek instead to the list, as
I just saw, so here is what I wrote as a reply.
Hi,
well, I assumed that, since the compromise of a Windows system running on
the same machine obviously takes place by the execution of the ACPI code,
as one can see by looking at the malwr.com sandbox analysis. It's also
interesting to find ACPI code resulting in the same Windows manipulations
on four different systems being used by me. The ACPI code extracted from my
Lenovo notebook can be downloaded from the malwr.com link, same for the
ACPI code I extracted from my AMD desktop. In the latter case the
disassembled code can also be downloaded from the GoogleDrive link I
provided. Maybe one could observe similarities by comparing the two codes
of those different systems.
I also think that the technology tries a lot to prevent many things, since
the Volatility plugins weren't able to display the loaded kernel modules,
the netstat plugin didn't give any output etc. And I was able to perform
some (!) of the tests on my AMD desktop system, while no test could be
performed on my Lenovo notebook. It's very reasonable to assume that a
highly sophisticated rootkit also includes various mechanisms for
preventing its analysis, but that doesn't rule out the possibility that
those mechanisms might fail, especially when considering that malware based
on firmware manipulation must face many difficulties due to the specifics
of various system's hardware components (and their according firmware).
Now I really don't want to make the impression of being stubborn, but
please consider the following facts:
1) Submitting the extracted firmware of different systems being used by me
to malwr.com, where the ACPI code gets executed, leads to the EXACTLY same
results regarding the files created (which turn out to be part of
malware/trojan software as a quick search for their filenames shows) AND
the same registry activity (a proxy server is being set up etc.). Those
system activities can only have been caused by the submitted ACPI code, I
didn't submit anything else. Submitting ACPI code extracted from
non-compromised systems doesn't show any special activities.
--> It's not an assumption, but an evident fact that those manipulations
took place by the execution of ACPI code.
2) The Linux systems on those systems are compromised as well, as the
Volatility tests obviously demonstrate (kernel hooks, modification of the
network layers/structure so that the network traffic visible to the user is
probably not the whole traffic being sent/received, etc.).
Therefore, thinking logical: Why should a Windows OS on a machine get
compromised by the execution of ACPI code, while a Linux OS on the same
system should be safe in this regard/gets compromised by another way? There
are enough papers out there proving that Linux can definitely be
compromised by the execution of ACPI code.
[By arguing this way I don't want to imply that a compromise could ONLY
take place through the execution of ACPI code - I agree to everything what
Rudolf wrote regarding this aspect. In fact I would assume that a
sophisticated rootkit would operate in a multi-redundant way, e. g. taking
precautions that the system will still get compromised for example by
employing means like mentioned by Rudolf, in case that the user would find
a way to flash the ACPI code (which is not possible by performing a simple
BIOS flash, as I already verified - the ACPI code remains being
unmodified). I merely want to state that the ACPI code's execution seems to
be the starting point of the system getting compromised.]
So I had the idea to find out whether my thoughts are correct or not by
letting a Linux system run in a VM, one time without making them use my
system's ACPI code, and one time with specifying those as arguments, which
is basically possible both for VirtualBox and for QEMU/KVM, so that I could
afterwards compare what took place on each VM guest. However, it was not
possible for me to do so, because both VirtualBox and QEMU/KVM have the
restriction that the size of the total ACPI code is allowed to have a
maximum size of 64kb (I have no idea for which reason this is the case) -
This issue is even addressed on bug reports/issue lists, but it seems like
nobody was able to find a solution or explanation for this so far.
Did anyone on this list test Linux systems' ACPI compatibility etc. by this
VM approach? If so, I'd be really thankful if someone would be able to
perform such a test using my system's ACPI code - Just checking for
differences regarding the creation/modification of files might be
instructive already.
I guess it wouldn't be an easy task to check the whole source of VirtualBox
or QEMU/KWM in order to find a way how to remove this size limitation,
although I'd try doing so, if there shouldn't be any other way to test this.
I dumped my ACPI tables using proc /sys/... this time and uploaded the .bin
files to GoogleDrive:
https://drive.google.com/open?id=0B62Y5Qk_rdbWTVpfVlgwWDFjYWc
I've put the .dsl files disassembled by iasl (which reported quite many
errors) into the folder as well. There was no RSDT table in the /sys/...
directory, and by using acpidump plus acpixtract I wasn't able to obtain
one neither.
Thanks in advance and all the best to everyone
David
Kind regards
David
Am 31.07.2016 15:23 schrieb "Rudolf Marek" <r.marek(a)assembler.cz>:
Hi David,
I checked the ACPI error messages and they are pretty harmless. I don't
think attacker would use the ACPI subsystem to plant the rootkit. I think
the rootkit might be hidden in the system management mode memory which is
inaccessible by the operating system. Therefore I don't think this is good
mailing list to discuss it but I hope no one will complain if I give you
some hints to try:
1) physically exchange a BIOS chip - use some service which will send you a
BIOS chip replacement - they can even pre-load it with a factory BIOS
2) If you can't do that, and if the BIOS is socketed then use some external
programmer to read out the BIOS, then go to the ASUS pages and download the
BIOS as a CAP file. The file usually has 2KB header which you can strip and
then you will get the 8MiB image which you can directly flash. Do not
expect that the backup image will match - BIOS contains some places with a
variables/scratch space so this won't help.
3) Check your malware detection procedure. I don't have the dropbox account
so I can't help much. All distributions have a way to check the integrity
of installed packages, so you can use this mechanism to check if something
has been changed or not. (maybe the binary changed because of the update?)
4) I personally think that if you wold be a victim of such sophisticated
malware which can infect any Linux/BSD then I would also think think that
the malware would for sure prevent you to see the modified files.
Thanks all I can say to this, now go and try to find some other more
appropriate mailing list (sorry no idea here), also I don't think I can
personally help any further
Thanks
Rudolf
5 years, 11 months
Re: [Devel] [PATCH 1/2] ACPICA: adapt buffer length for Field Attrib Raw Process in Ops Region
by Zheng, Lv
Hi,
> From: Benjamin Tissoires [mailto:[email protected]]
> Subject: [PATCH 1/2] ACPICA: adapt buffer length for Field Attrib Raw
> Process in Ops Region
>
> Detected on the Surface 3:
> The MSHW0011 driver uses Field Attrib Raw Process to return information
> for the ACPI Battery. The DSDT declares a parameter of 2 though
> functions like _BST or _BIX require a much bigger out buffer.
>
> It looks like the incoming buffer has the requested size and we can
> work around the issue by using this input size as the output and
> parameters size.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=106231
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
> ---
> drivers/acpi/acpica/exfield.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/acpi/acpica/exfield.c b/drivers/acpi/acpica/exfield.c
> index d7d3ee3..a1bd041 100644
> --- a/drivers/acpi/acpica/exfield.c
> +++ b/drivers/acpi/acpica/exfield.c
> @@ -413,6 +413,17 @@ acpi_ex_write_data_to_field(union
> acpi_operand_object *source_desc,
> * Data[x-1]: (Bytes 2-x of the arbitrary length
> data buffer)
> */
> length += 2;
> +
> + /*
> + * When using Field Attrib Raw Process, it looks like
> + * the parameter access_length can be wrong and
> the
> + * required output buffer can be much bigger.
> + * So just take the incoming buffer length as the
> + * reference.
> + */
> + if (accessor_type ==
> AML_FIELD_ATTRIB_RAW_PROCESS)
> + length = source_desc->buffer.length;
> +
[Lv Zheng]
I think the related code is:
OperationRegion (OR02, GenericSerialBus, Zero, 0x0100)
Field (OR02, BufferAcc, NoLock, Preserve)
{
Connection (BX00),
AccessAs (BufferAcc, AttribRawProcessBytes (0x02)),
BB00, 8
}
Name (SPB0, Buffer (0x80) {})
CreateByteField (SPB0, Zero, STA2)
CreateByteField (SPB0, One, LEN0)
CreateByteField (SPB0, 0x02, CMD0)
CreateByteField (SPB0, 0x03, DAT0)
CreateByteField (SPB0, 0x04, DAT1)
CreateDWordField (SPB0, 0x05, DAT2)
CreateField (SPB0, 0x10, 0x0320, DAT3)
Method (RSPB, 3, NotSerialized)
{
CMD0 = One
LEN0 = 0x08
DAT0 = Arg0
DAT1 = Arg1
DAT2 = Arg2
SPB0 = ^^I2Z1.BB00 = SPB0 /* \_SB_.BAT0.SPB0 */
...
}
And we have confirmed that the iASL disassembly result is correct.
Then this issue is not a parser issue, but looks like an issue either in interpreter or in BIOS as:
1. The following line triggers i2c operation region handlers:
SPB0 = ^^I2Z1.BB00 = SPB0
Where:
SPB0 is sized as 0x80, BB00 is sized as 0x02.
And in spec 19.6.1 AccessAs (Change Field Unit Access), it is said that AttribRawProcessBytes(AccessLength) requires an AccessLength parameter.
However in this case, the length of the output buffer is not correct, much smaller than the container buffer.
So this firstly looks like a BIOS issue. And then needn't be fixed in OS.
2. If this is not a BIOS bug but an interpreter bug, then SPB0 should be a buffer passing to the i2c region handler.
The bug should be something related to "data type conversion".
Please refer to:
19.2.5.4 Implicit Source Operand Conversion
19.2.5.5 Implicit Result Object Conversion
It looks like that we have troubles in either 1st Store or 2nd Store.
If so, it seems we shouldn't fix this issue here. And thus this fix also looks invalid.
IMO (may be wrong), this bug finally may cause dissension among different parties (BIOS, Windows, ACPICA, spec).
However, for the time being, is that possible to work this issue around in the i2c operation region driver?
Thanks and best regards
-Lv
> function = ACPI_WRITE | (accessor_type << 16);
> } else { /* IPMI */
>
> --
> 2.5.5
5 years, 11 months
