On Wed, Dec 2, 2015 at 5:42 PM, Zheng, Lv [off-list ref] wrote:

Hi, Andy

Sorry for the delay of reply.

quoted

From: Andy Lutomirski [mailto:luto@kernel.org]
Sent: Thursday, December 3, 2015 9:29 AM

On Wed, Dec 2, 2015 at 5:26 PM, Rafael J. Wysocki [off-list ref] wrote:

quoted

On Thu, Dec 3, 2015 at 2:22 AM, Andy Lutomirski [off-list ref] wrote:

quoted

On Wed, Dec 2, 2015 at 5:13 PM, Rafael J. Wysocki [off-list ref]

wrote:

quoted

quoted

quoted

Hi,

On Thu, Dec 3, 2015 at 1:37 AM, Andy Lutomirski [off-list ref]

wrote:

quoted

quoted

quoted

quoted

[resend as plain text]

I want to bundle up an arbitrary ACPI_OBJECT into a copyable stream of
bytes, is there some standard way to do this?

I'm asking because I want to try to upstream something resembling the
rusty old acpi_call module to allow users with debugfs access who are
willing to taint their kernel to evaluate ACPI objects from userspace.
Presumably there would be a user tool to get object info and to
evaluate methods, and we could handle translation to/from strings in
userspace, but I still need some way to shove the data back and forth.

Please don't do that, this is broken as a concept.

User space has no idea whatsoever about when and it what conditions a
given AML can be executed in the first place, so in addition to
tainting the kernel it may just outright break things.

Not to mention the possibility of confusing the kernel's reference
counting and breaking assumptions made by it on the current state of
things based on what AML has been already executed.

This is something that I want as a reader of decompiled DSDTs and a
writer of drivers.  I think we could do it in a way that it doesn't
get used for evil.  For example, make it a module, taint the kernel if
it's loaded and enabled, only expose the interface if an actual *boot*
parameter allow_user_acpi_calls=1 is set, encourage distros to
seriously consider not building the module, disallow it entirely under
secure boot, etc.

I want to use it for things like "hey, it looks like \NEXP might have
a funny value -- let's see what's there without manually figuring out
how to peek at the relevant OpRegion".

So please check the debugger thing.

Lv, can you please help Andy with this?

Ooh, that's really cool!  It looks like acpidbg -b "execute \WHATEVER"
is *exactly* what I want.  Is there a git tree or up-to-date patchset
that works?  It looks like 4.4-rc3 has some but not all of the pieces
needed.

[Lv Zheng]
You can find them here:
https://patchwork.kernel.org/project/linux-acpi/list/
The patches are:
[v3] ACPI / x86: introduce acpi_os_readable() support
[v3,6/6] ACPI / debugger: Add module support for ACPI debugger
[v3,5/6] tools/power/acpi: Add userspace AML interface support
[v3,4/6] ACPI / debugger: Add IO interface to access debugger functionalities
[v3,3/6] ACPICA: Debugger: Fix runtime stub issues of ACPI_DEBUGGER_EXEC using different stub mechanism
[v3,2/6] ACPICA: Debugger: Convert some mechanisms to OSPM specific
[v3,1/6] ACPICA: Debugger: Remove unnecessary status check

It is based on linux-pm/linux-next tree.
I'm going to send an update because to eliminate some recent introduced conflicts.
I'll Cc you when the new version is sent out.

Thanks and best regards
-Lv

I finally had some time to play with the ACPI debugger, and it's
fantastic.  Thanks!

One minor feature request: have you considered adding readline or
libedit support?

--Andy