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, 5 months
Linux getting compromised by the execution of ACPI code
by David Renz
Hello,
I just posted this message on the volatility mailing list, and when
considering that the system obviously got compromised while considering the
ACPI related dmesg output (plus considering that its execution on a Windows
system is responsible for its manipulation, s. malwr.com links), I think it
is safe to assume that the execution of the ACPI code on Linux is
responsible for what shows up in the results of the various tests I
performed.
Since this should be the best place for reaching experts about ACPI code, I
can only repeat what I already said in my forwarded message: It would be
highly interesting to see how exactly the ACPI code's execution interacts
with the kernel in order to compromise the system. Maybe there's someone
who could take a look at the code extracted from my system or give me some
advice on how to perform a debugging which would be able to provide some
further information about this.
Thanks in advance and kind regards
David
---------- Forwarded message ----------
From: David Renz <sun.kisses.horizon(a)gmail.com>
Date: Sun, Jul 31, 2016 at 2:45 PM
Subject: Request for advice on how to proceed with further analysis
To: vol-users(a)volatilesystems.com
Hello,
I recently posted a message, where I asked how to create a profile which
could be used with ArchLinux, but now I just solved this by having
installed Lubuntu 16.04 (4.4.0-31-generic 64-bit), so that I was able to
analyze my system's dumped memory using the pre-built Ubuntu 16.04 image I
found on GitHub (the image I created by myself couldn't be used by
Volatility, although I definitely followed each step precisely).
The checks I performed confirmed my suspicion that my system would be
compromised, as one can see by taking a look at the results I uploaded on
GoogleDrive:
https://drive.google.com/open?id=0B62Y5Qk_rdbWTnNYWlJRWXpsZUE
E.g.:
linux_check_afinfo
Symbol Name Member
Address
------------------------------------------ ------------------------------
------------------
udplite6_seq_afinfo next
0xffffffff81effcc8
udplite6_seq_afinfo stop
0xffffffff81eff808
udplite4_seq_afinfo next
0xffffffff81efeac8
udplite4_seq_afinfo stop
0xffffffff81efbce8
udp4_seq_afinfo start
0xffffffff81efae00
udp4_seq_afinfo stop
0xffffffff81efa3a0
linux_check_inline_kernel
Name Member Hook Type
Hook Address
------------------------------------------------ ---------------- ---------
------------------
udp4_seq_afinfo stop JMP
0x0000000000000000
[A huge number of hooks shown by linux_check_syscall]
Using the netstat plugin shows no result at all (none of the connections
shown by using the normal Linux netstat command). Neither linux_lsmod nor
linux_hidden_modules give any output as well.
I assume that my system is infected by an ACPI rootkit, which is able to
compromise both Linux and Windows systems. After having submitted the
extracted the ACPI tables' code to malwr.com, where it gets executed on a
Windows sandbox, it shows that the system gets manipulated in the following
way:
https://malwr.com/analysis/ODkxOThjOTk1MDAzNGE4M2JhOWNhNzk1ZTJjM2IyYWQ/
It might be interesting that the ACPI code of four different systems being
used by me seems to have been manipulated in the same way, since the
extracted code found on one of the other systems leads to the same result
when submitting it to malwr.com. E.g., the link above shows the result for
the analysis of ACPI code on my AMD 64-bit desktop computer (Asus-M4N68T-M
LE mainboard), while the ACPI code extracted from my Lenovo G710 notebook
leads to the same when executed on a Windows system:
https://malwr.com/analysis/MjZkOGU4Y2ZmMGM5NDQ1Njg5OTc4NTVlOTQ5NThiMmY/
I guess everyone can see that the results show how the Windows system gets
compromised for being able to monitor it and gaining remote access over it,
if you take a look at the file and registry activities (just googling some
of the file names makes that clear).
Since a Linux system running on the same machine gets compromised as well,
it would be reasonable to assume that this also takes place by the ACPI
code's execution. Taking a look at the dmesg output, which I also uploaded
on GoogleDrive, seems to confirm this assumption:
[ 0.225468] ACPI: Added _OSI(Module Device)
[ 0.225470] ACPI: Added _OSI(Processor Device)
[ 0.225471] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.225472] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.227433] ACPI: Executed 1 blocks of module-level executable AML code
[ 0.293448] ACPI: Interpreter enabled
[ 0.293458] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State
[\_S2_] (20150930/hwxface-580)
[ 0.293469] ACPI: (supports S0 S1 S3 S4 S5)
[ 0.293470] ACPI: Using IOAPIC for interrupt routing
[ 0.293491] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem
0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.294509] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in
ACPI motherboard resources
[ 0.294522] PCI: Using host bridge windows from ACPI; if necessary, use
"pci=nocrs" and report a bug
[ 0.298938] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.298943] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM
ClockPM Segments MSI]
[ 0.299051] acpi PNP0A03:00: _OSC: platform does not support
[PCIeHotplug PCIeCapability]
[ 0.299099] acpi PNP0A03:00: _OSC: not requesting control; platform does
not support [PCIeCapability]
[ 0.299101] acpi PNP0A03:00: _OSC: OS requested [PCIeHotplug PME AER
PCIeCapability]
[ 0.299103] acpi PNP0A03:00: _OSC: platform willing to grant [PME AER]
[ 0.299104] acpi PNP0A03:00: _OSC failed (AE_SUPPORT); disabling ASPM
[ 8.647712] ACPI Warning: SystemIO range
0x0000000000000600-0x000000000000063F conflicts with OpRegion
0x0000000000000600-0x00000000000006FF (\_SB_.PCI0.SBRG.ASOC.SMRG)
(20150930/utaddress-254)
The extracted and disassembled ACPI code of my AMD system can be downloaded
from here:
https://drive.google.com/open?id=0B62Y5Qk_rdbWYzhPTHhHM1RxRTg
So I would appreciate it, if anyone would have an idea on how to proceed
with a further analysis. It would be interesting, if one would be able to
see how exactly the ACPI code's execution interacts with the kernel in
order to compromise the system. And of course it would be interesting to
discover where the relevant network traffic gets forwarded to / comes in
from (for remote access), since the checks I already performed showed that
the networking structure got manipulated, so that the usage of Wireshark
etc. won't show anything.
Kind regards and thanks in advance
David
5 years, 5 months
ACPICA version 20160729
by Moore, Robert
29 July 2016. Summary of changes for version 20160729:
This release is available at https://acpica.org/downloads
1) ACPICA kernel-resident subsystem:
Implemented basic UEFI support for the various ACPICA tools. This includes:
1) An OSL to implement the various AcpiOs* interfaces on UEFI.
2) Support to obtain the ACPI tables on UEFI.
3) Local implementation of required C library functions not available on UEFI.
4) A front-end (main) function for the tools for UEFI-related initialization.
The initial deployment of this support is the AcpiDump utility executing as an UEFI application via EDK2 (EDKII, "UEFI Firmware Development Kit"). Current environments supported are Linux/Unix. MSVC generation is not supported at this time. See the generate/efi/README file for build instructions. Lv Zheng.
Future plans include porting the AcpiExec utility to execute natively on the platform with I/O and memory access. This will allow viewing/dump of the platform namespace and native execution of ACPI control methods that access the actual hardware. To fully implement this support, the OSL functions below must be implemented with UEFI interfaces. Any community help in the implementation of these functions would be appreciated:
AcpiOsReadPort
AcpiOsWritePort
AcpiOsReadMemory
AcpiOsWriteMemory
AcpiOsReadPciConfiguration
AcpiOsWritePciConfiguration
Restructured and standardized the C library configuration for ACPICA, resulting in the various configuration options below. This includes a global restructuring of the compiler-dependent and platform-dependent include files. These changes may affect the existing platform-dependent configuration files on some hosts. Lv Zheng.
The current C library configuration options appear below. For any issues, it may be helpful to examine the existing compiler-dependent and platform-dependent files as examples. Lv Zheng.
1) Linux kernel:
ACPI_USE_STANDARD_HEADERS=n in order not to use system-provided C library.
ACPI_USE_SYSTEM_CLIBRARY=y in order not to use ACPICA mini C library.
2) Unix/Windows/BSD applications:
ACPI_USE_STANDARD_HEADERS=y in order to use system-provided C library.
ACPI_USE_SYSTEM_CLIBRARY=y in order not to use ACPICA mini C library.
3) UEFI applications:
ACPI_USE_STANDARD_HEADERS=n in order not to use system-provided C library.
ACPI_USE_SYSTEM_CLIBRARY=n in order to use ACPICA mini C library.
4) UEFI applications (EDK2/StdLib):
ACPI_USE_STANDARD_HEADERS=y in order to use EDK2 StdLib C library.
ACPI_USE_SYSTEM_CLIBRARY=y in order to use EDK2 StdLib C library.
AML interpreter: "module-level code" support. Allows for execution of so-called "executable" AML code (math/logical operations, etc.) outside of control methods not just at the module level (top level) but also within any scope declared outside of a control method - Scope{}, Device{}, Processor{}, PowerResource{}, and ThermalZone{}. Lv Zheng.
Simplified the configuration of the "maximum AML loops" global option by adding a global public variable, "AcpiGbl_MaxLoopIterations" which can be modified at runtime.
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: 139.1K Code, 22.9K Data, 162.0K Total
Debug Version: 199.0K Code, 81.8K Data, 280.8K Total
2) iASL Compiler/Disassembler and Tools:
iASL: Add full support for the RASF ACPI table (RAS Features Table). Includes disassembler, data table compiler, and header support.
iASL Expand "module-level code" support. Allows for compilation/disassembly of so-called "executable" AML code (math/logical operations, etc.) outside of control methods not just at the module level (top level) but also within any scope declared outside of a control method - Scope{}, Device{}, Processor{}, PowerResource{}, and ThermalZone{}.
AcpiDump: Added support for dumping all SSDTs on newer versions of Windows. These tables are now easily available -- SSDTs are not available through the registry on older versions.
5 years, 5 months
Re: [Devel] [PATCH] ACPICA: cleanup method properly on error
by Zheng, Lv
Hi, Vegard
> From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi-
> owner(a)vger.kernel.org] On Behalf Of Vegard Nossum
> Subject: [PATCH] ACPICA: cleanup method properly on error
>
> If the call to acpi_ds_init_aml_walk() fails, then we have to undo the
> walk state push done by acpi_ds_create_walk_state(). Otherwise, the new
> walk state (which has just been freed) will remain on the thread's
> walk_state_list and be dereferenced in acpi_ps_parse_aml() when we try
> to get the new state.
[Lv Zheng]
I haven't looked into the detail.
Let me first ask simple questions and present simple concerns in order to move this discussion on.
>
> You can observe this when reading e.g.
>
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:01/status
[Lv Zheng]
Do you mean you have real issues related to this?
If so, could provide the .config and dmesg for us?
>
> Cc: stable(a)vger.kernel.org
> Signed-off-by: Vegard Nossum <vegard.nossum(a)oracle.com>
> ---
> drivers/acpi/acpica/dsmethod.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/acpi/acpica/dsmethod.c
> b/drivers/acpi/acpica/dsmethod.c
> index 47c7b52..44b50a6 100644
> --- a/drivers/acpi/acpica/dsmethod.c
> +++ b/drivers/acpi/acpica/dsmethod.c
> @@ -596,6 +596,8 @@ cleanup:
> /* On error, we must terminate the method properly */
>
> acpi_ds_terminate_control_method(obj_desc, next_walk_state);
> + if (thread)
> + acpi_ds_pop_walk_state(thread);
> acpi_ds_delete_walk_state(next_walk_state);
[Lv Zheng]
It seems, if acpi_ds_create_walk_state() fails, acpi_ds_delete_walk_state() will be invoked.
So they are paired. Fixing this in acpi_ds_delete_walk_state() could help to fix all of them.
Given the fix is useful, why don't you do this in acpi_ds_delete_walk_state()?
Thanks and best regards
-Lv
5 years, 5 months
AcpiOsAllocate with zero argument
by Rudolf Marek
Hi all,
I could not find in the "ACPICA Overview and Programmer Reference" any clues
what to do if someone calls AcpiOsAllocate() with size of zero. I checked the
Linux implementation and it just calls kmalloc() which after bit of googling
seems to return non-NULL for this case. I also tried to walk through the ACPICA
sources and it seems to me that at least on some places it looks like that it
could be called with 0 (num_gpe * sizeof(something))
I also tried to look to the "osdeps" of what the UEFI or unix stub do, but they
simply pass it on. I could not find what UEFI does with zero, I only know
that malloc can either return NULL (and success) or return also non-null pointer.
What is the correct way to handle the zero size allocations? Return non-NULL ?
Thanks
Rudolf
5 years, 5 months
Re: [Devel] [PATCH] ACPICA: cleanup method properly on error
by Moore, Robert
We'll look at this.
Thanks.
> -----Original Message-----
> From: Vegard Nossum [mailto:vegard.nossum@oracle.com]
> Sent: Friday, July 22, 2016 8:35 AM
> To: Moore, Robert <robert.moore(a)intel.com>; Zheng, Lv
> <lv.zheng(a)intel.com>; Wysocki, Rafael J <rafael.j.wysocki(a)intel.com>
> Cc: linux-acpi(a)vger.kernel.org; devel(a)acpica.org; linux-
> kernel(a)vger.kernel.org; Vegard Nossum <vegard.nossum(a)oracle.com>;
> stable(a)vger.kernel.org
> Subject: [PATCH] ACPICA: cleanup method properly on error
>
> If the call to acpi_ds_init_aml_walk() fails, then we have to undo the
> walk state push done by acpi_ds_create_walk_state(). Otherwise, the new
> walk state (which has just been freed) will remain on the thread's
> walk_state_list and be dereferenced in acpi_ps_parse_aml() when we try
> to get the new state.
>
> You can observe this when reading e.g.
>
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:01/status
>
> Cc: stable(a)vger.kernel.org
> Signed-off-by: Vegard Nossum <vegard.nossum(a)oracle.com>
> ---
> drivers/acpi/acpica/dsmethod.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/acpi/acpica/dsmethod.c
> b/drivers/acpi/acpica/dsmethod.c index 47c7b52..44b50a6 100644
> --- a/drivers/acpi/acpica/dsmethod.c
> +++ b/drivers/acpi/acpica/dsmethod.c
> @@ -596,6 +596,8 @@ cleanup:
> /* On error, we must terminate the method properly */
>
> acpi_ds_terminate_control_method(obj_desc, next_walk_state);
> + if (thread)
> + acpi_ds_pop_walk_state(thread);
> acpi_ds_delete_walk_state(next_walk_state);
>
> return_ACPI_STATUS(status);
> --
> 1.9.1
5 years, 6 months
[RFC DSD v2] How to Use the ACPI _DSD Device Properties UUIDs
by Al Stone
In the three documents that follow, we lay out a process for defining
the use cases of device properties returned by the ACPI _DSD (Device
Specific Data) object in Data Structures associated with the Device
Properties UUID [0] and the Hierarchical Properties Extension UUID [1].
The term "_DSD device properties" below refers to the data formats
associated with those two UUIDs only. All other UUIDs used with _DSD
are outside the scope of what is described here.
The goal of these documents is to: (1) make clear to OS vendors which of
the use cases of _DSD device properties need to be supported; (2) be
clear on what those use cases should mean to the OS; and, (3) have all
OSs use the same definitions for those use cases.
The first document describes basic context and essential terminology for
the process of submitting a use case for the _DSD device properties to a
central location so that it can be reviewed and tracked.
The next document describes a database for storing the use cases of _DSD
device properties that have been reviewed and agreed upon. The idea is
to make this database publicly available so that OS developers and
firmware creators can easily see what is already defined, what is in
use, and what is not defined.
The final document provides a formal language for describing the use
cases of _DSD device properties. The goal is to make it relatively easy
to define new use cases of the _DSD device properties, by stating
clearly what those definitions must look like. This also makes building
automated tools easier, allowing us to keep the process simpler, permit
validation of the content, assist with documentation, and perform basic
record keeping.
A copy of the ChangeLog is also attached so that you can see what the
primary changes were for this second version.
Why should you care?
If you write ACPI firmware, you may need to provide a _DSD object; if
you decide to create your own UUID, you will need to clearly document
the content returned by your _DSD UUID so that an OS can use it
properly. However, if you need to use _DSD device properties, the
documents here are intended to make it clear what needs to be done so
that use cases are documented and consistent for all OSs.
If you work with OS drivers using ACPI, you may need to consult one of
the use cases of the _DSD device properties. What these documents lay
out is a standard mechanism for describing these use cases, independent
of OS, with a uniform way to determine what is available, and what their
values are. Ideally, there would be no need to reverse engineer, or
worse, guess at, the device properties available for a specific device.
Finally, we hope to arrive at a time when OS changes requiring use cases
in the _DSD device properties do not get accepted unless they have been
registered and documented as described here. We want to get to the
point where use cases of _DSD device properties are unambiguous, well
documented, visible to all who need them, and usable across any number
of OSs.
If you have any comments, improvements or suggestions, let us know. We
believe the basic content is sound, but more eyes are always better. We
would also like to have this process up and running by August; it has
been postponed far too long as it is.
Comment here, or if you would rather, you can find the documents on
github and suggest patches there:
https://github.com/ahs3/dsd/tree/master/documentation
Thanks.
Contributors:
Al Stone <ahs3(a)redhat.com>
Charles Garcia-Tobin <charles.garcia-tobin(a)arm.com>
Darren Hart <darren.hart(a)intel.com>
David Woodhouse <david.woodhouse(a)intel.com>
Mark Doran <mark.doran(a)intel.com>
Rafael Wysocki <rafael.j.wysocki(a)intel.com>
Robert Gough <robert.gough(a)intel.com>
(...my apologies if anyone has not been mentioned...)
References:
[0]
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-...
[1]
http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-...
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
5 years, 6 months
FreeBSD _KERNEL Build
by Zheng, Lv
Hi, Jung-uk Kim
I have a pull request here to correct EFI builds of ACPICA tools:
https://github.com/acpica/acpica/pull/154
The original branch is here:
https://github.com/zetalog/acpica
acpica-efi2 branch.
Especially, in this pull request,
I've moved <stdarg.h> to acgcc.h.
And moved ACPI_USE_SYSTEM_CLIBRARY/ACPI_USE_STANDARD_HEADERS
Definitions to the very first lines of the platform specific files.
(in order to:
1. allow EFI builds to define both via Makefiles
2. allow Clib header inclusions to be protected in the following style for -nostdinc targets:
#ifdef ACPI_USE_STANDARD_HEADER
#include <unistd.h>
#endif
However I didn't do anything to the BSD headers.
It seems some of them using <machine/stdarg.h> instead of <stdarg.h>.
I guess they are the same file so nothing will be broken, but I'm not sure.
Could you help to confirm if the will break BSD builds?
Especially _KERNEL builds.
Thanks in advance.
Best regards
-Lv
5 years, 6 months
Re: [Devel] [PATCH 3/6] ACPICA: make use of new strtolower() function
by Moore, Robert
> -----Original Message-----
> From: Markus Mayer [mailto:markus.mayer@broadcom.com]
> Sent: Thursday, June 30, 2016 9:13 PM
> To: Moore, Robert
> Cc: Zheng, Lv; Wysocki, Rafael J; Len Brown; linux-acpi(a)vger.kernel.org;
> devel(a)acpica.org; linux-kernel(a)vger.kernel.org; Box, David E
> Subject: Re: [PATCH 3/6] ACPICA: make use of new strtolower() function
>
> On 30 June 2016 at 19:59, Moore, Robert <robert.moore(a)intel.com> wrote:
> > This is linux-specific code, ACPICA is os-independent. So we cannot
> > accept such patch.
>
> Understood. I wasn't aware that this was shared code.
Ok. Glad to take fixes and optimizations, however.
Bob
>
> > From: Markus Mayer [mailto:markus.mayer@broadcom.com]
> > Sent: Thursday, June 30, 2016 7:50 PM
> > To: Moore, Robert
> > Cc: Zheng, Lv; Wysocki, Rafael J; Len Brown;
> > linux-acpi(a)vger.kernel.org; devel(a)acpica.org;
> > linux-kernel(a)vger.kernel.org; Box, David E
> > Subject: Re: [PATCH 3/6] ACPICA: make use of new strtolower() function
> >
> > On Thursday, 30 June 2016, Moore, Robert <robert.moore(a)intel.com> wrote:
> >
> > Where is "strtolower" implemented?
> >
> > First patch of the series:
> >
> > https://lkml.org/lkml/2016/6/30/733
> >
> >> -----Original Message-----
> >> From: Markus Mayer [mailto:mmayer@broadcom.com]
> >> Sent: Thursday, June 30, 2016 4:50 PM
> >> To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; Len Brown
> >> Cc: Markus Mayer; linux-acpi(a)vger.kernel.org; devel(a)acpica.org;
> >> linux- kernel(a)vger.kernel.org
> >> Subject: [PATCH 3/6] ACPICA: make use of new strtolower() function
> >>
> >> Call strtolower() rather than walking the string explicitly to
> >> convert it to lowercase.
> >>
> >> Signed-off-by: Markus Mayer <mmayer(a)broadcom.com>
> >> ---
> >>
> >> *** Please note that there don't seem to be any callers of
> >> acpi_ut_strlwr().
> >> *** It may be possible to remove the function altogether.
> >>
> >> drivers/acpi/acpica/utnonansi.c | 13 +------------
> >> 1 file changed, 1 insertion(+), 12 deletions(-)
> >>
> >> diff --git a/drivers/acpi/acpica/utnonansi.c
> >> b/drivers/acpi/acpica/utnonansi.c index 3465fe2..b6e11dc 100644
> >> --- a/drivers/acpi/acpica/utnonansi.c
> >> +++ b/drivers/acpi/acpica/utnonansi.c
> >> @@ -64,19 +64,8 @@ ACPI_MODULE_NAME("utnonansi")
> >>
> >> *********************************************************************
> >> *****
> >> ****/
> >> void acpi_ut_strlwr(char *src_string) {
> >> - char *string;
> >> -
> >> ACPI_FUNCTION_ENTRY();
> >> -
> >> - if (!src_string) {
> >> - return;
> >> - }
> >> -
> >> - /* Walk entire string, lowercasing the letters */
> >> -
> >> - for (string = src_string; *string; string++) {
> >> - *string = (char)tolower((int)*string);
> >> - }
> >> + strtolower(src_string);
> >> }
> >>
> >>
> >> /********************************************************************
> >> *****
> >> ******
> >> --
> >> 2.7.4
5 years, 6 months
Re: [Devel] [PATCH 3/6] ACPICA: make use of new strtolower() function
by Moore, Robert
This is linux-specific code, ACPICA is os-independent. So we cannot accept such patch.
From: Markus Mayer [mailto:markus.mayer@broadcom.com]
Sent: Thursday, June 30, 2016 7:50 PM
To: Moore, Robert
Cc: Zheng, Lv; Wysocki, Rafael J; Len Brown; linux-acpi(a)vger.kernel.org; devel(a)acpica.org; linux-kernel(a)vger.kernel.org; Box, David E
Subject: Re: [PATCH 3/6] ACPICA: make use of new strtolower() function
On Thursday, 30 June 2016, Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore@intel.com>> wrote:
Where is "strtolower" implemented?
First patch of the series:
https://lkml.org/lkml/2016/6/30/733
> -----Original Message-----
> From: Markus Mayer [mailto:mmayer@broadcom.com<javascript:;>]
> Sent: Thursday, June 30, 2016 4:50 PM
> To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; Len Brown
> Cc: Markus Mayer; linux-acpi(a)vger.kernel.org<javascript:;>; devel(a)acpica.org<javascript:;>; linux-
> kernel(a)vger.kernel.org<javascript:;>
> Subject: [PATCH 3/6] ACPICA: make use of new strtolower() function
>
> Call strtolower() rather than walking the string explicitly to convert it
> to lowercase.
>
> Signed-off-by: Markus Mayer <mmayer(a)broadcom.com<javascript:;>>
> ---
>
> *** Please note that there don't seem to be any callers of
> acpi_ut_strlwr().
> *** It may be possible to remove the function altogether.
>
> drivers/acpi/acpica/utnonansi.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/acpi/acpica/utnonansi.c
> b/drivers/acpi/acpica/utnonansi.c index 3465fe2..b6e11dc 100644
> --- a/drivers/acpi/acpica/utnonansi.c
> +++ b/drivers/acpi/acpica/utnonansi.c
> @@ -64,19 +64,8 @@ ACPI_MODULE_NAME("utnonansi")
>
> **************************************************************************
> ****/
> void acpi_ut_strlwr(char *src_string)
> {
> - char *string;
> -
> ACPI_FUNCTION_ENTRY();
> -
> - if (!src_string) {
> - return;
> - }
> -
> - /* Walk entire string, lowercasing the letters */
> -
> - for (string = src_string; *string; string++) {
> - *string = (char)tolower((int)*string);
> - }
> + strtolower(src_string);
> }
>
>
> /*************************************************************************
> ******
> --
> 2.7.4
5 years, 6 months
