ACPICA serialized objects?

ACPICA serialized objects?

[Andy Lutomirski]

[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.

Thanks,
Andy

Re: ACPICA serialized objects?

[Rafael J. Wysocki]

Hi,

On Thu, Dec 3, 2015 at 1:37 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> [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.

Thanks,
Rafael

Re: ACPICA serialized objects?

[Andy Lutomirski]

On Wed, Dec 2, 2015 at 5:13 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> Hi,
>
> On Thu, Dec 3, 2015 at 1:37 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> [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".

We allow ACPI custom methods -- surely this is slightly less awful.
Heck, we have /dev/mem, too.  That's arguably much more dangerous.

--Andy

Re: ACPICA serialized objects?

[Rafael J. Wysocki]

On Thu, Dec 3, 2015 at 2:13 AM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> Hi,
>
> On Thu, Dec 3, 2015 at 1:37 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> [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.

Besides, we're adding an AML debugger to the kernel right now, maybe
it will be sufficient for your use case.

Lv is working on it.

Thanks,
Rafael

Re: ACPICA serialized objects?

[Rafael J. Wysocki]

On Thu, Dec 3, 2015 at 2:22 AM, Andy Lutomirski <luto@kernel.org> wrote:
> On Wed, Dec 2, 2015 at 5:13 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> Hi,
>>
>> On Thu, Dec 3, 2015 at 1:37 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> [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?

Thanks,
Rafael

Re: ACPICA serialized objects?

[Andy Lutomirski]

On Wed, Dec 2, 2015 at 5:26 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Thu, Dec 3, 2015 at 2:22 AM, Andy Lutomirski <luto@kernel.org> wrote:
>> On Wed, Dec 2, 2015 at 5:13 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>>> Hi,
>>>
>>> On Thu, Dec 3, 2015 at 1:37 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>> [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.

--Andy

Re: ACPICA serialized objects?

[Rafael J. Wysocki]

On Thu, Dec 3, 2015 at 2:28 AM, Andy Lutomirski <luto@kernel.org> wrote:
> On Wed, Dec 2, 2015 at 5:26 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> On Thu, Dec 3, 2015 at 2:22 AM, Andy Lutomirski <luto@kernel.org> wrote:
>>> On Wed, Dec 2, 2015 at 5:13 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>>>> Hi,
>>>>
>>>> On Thu, Dec 3, 2015 at 1:37 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>>> [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.

If you go to the ACPI patchwork, there are some patches you can try
from there.  Beyond that, Lv is the person to talk to.

Thanks,
Rafael

RE: ACPICA serialized objects?

[Zheng, Lv]

Hi, Andy

Sorry for the delay of reply.

> 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 <rafael@kernel.org> wrote:
> > On Thu, Dec 3, 2015 at 2:22 AM, Andy Lutomirski <luto@kernel.org> wrote:
> >> On Wed, Dec 2, 2015 at 5:13 PM, Rafael J. Wysocki <rafael@kernel.org>
> wrote:
> >>> Hi,
> >>>
> >>> On Thu, Dec 3, 2015 at 1:37 AM, Andy Lutomirski <luto@amacapital.net>
> wrote:
> >>>> [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

> 
> --Andy

Re: ACPICA serialized objects?

[Andy Lutomirski]

On Wed, Dec 2, 2015 at 5:42 PM, Zheng, Lv <lv.zheng@intel.com> wrote:
> Hi, Andy
>
> Sorry for the delay of reply.
>
>> 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 <rafael@kernel.org> wrote:
>> > On Thu, Dec 3, 2015 at 2:22 AM, Andy Lutomirski <luto@kernel.org> wrote:
>> >> On Wed, Dec 2, 2015 at 5:13 PM, Rafael J. Wysocki <rafael@kernel.org>
>> wrote:
>> >>> Hi,
>> >>>
>> >>> On Thu, Dec 3, 2015 at 1:37 AM, Andy Lutomirski <luto@amacapital.net>
>> wrote:
>> >>>> [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

RE: ACPICA serialized objects?

[Moore, Robert]

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@amacapital.net]
> Sent: Wednesday, January 13, 2016 2:32 PM
> To: Zheng, Lv
> Cc: Andy Lutomirski; Rafael J. Wysocki; Linux ACPI; Moore, Robert
> Subject: Re: ACPICA serialized objects?
> 
> 
> 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?

We actually have "readline" style support in at least acpiexec (which uses
The AML debugger):

/******************************************************************************
 *
 * FUNCTION:    OsEnterLineEditMode, OsExitLineEditMode
 *
 * PARAMETERS:  None
 *
 * RETURN:      None
 *
 * DESCRIPTION: Enter/Exit the raw character input mode for the terminal.
 *
 * Interactive line-editing support for the AML debugger. Used with the
 * common/acgetline module.
 *
 * readline() is not used because of non-portability. It is not available
 * on all systems, and if it is, often the package must be manually installed.
 *
 * Therefore, we use the POSIX tcgetattr/tcsetattr and do the minimal line
 * editing that we need in AcpiOsGetLine.
 *
 * If the POSIX tcgetattr/tcsetattr interfaces are unavailable, these
 * calls will also work:
 *     For OsEnterLineEditMode: system ("stty cbreak -echo")
 *     For OsExitLineEditMode:  system ("stty cooked echo")
 *
 *****************************************************************************/


> 
> --Andy

Re: ACPICA serialized objects?

[Andy Lutomirski]

On Wed, Jan 13, 2016 at 2:49 PM, Moore, Robert <robert.moore@intel.com> wrote:
>
>
>> -----Original Message-----
>> From: Andy Lutomirski [mailto:luto@amacapital.net]
>> Sent: Wednesday, January 13, 2016 2:32 PM
>> To: Zheng, Lv
>> Cc: Andy Lutomirski; Rafael J. Wysocki; Linux ACPI; Moore, Robert
>> Subject: Re: ACPICA serialized objects?
>>
>>
>> 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?
>
> We actually have "readline" style support in at least acpiexec (which uses
> The AML debugger):
>
> /******************************************************************************
>  *
>  * FUNCTION:    OsEnterLineEditMode, OsExitLineEditMode
>  *
>  * PARAMETERS:  None
>  *
>  * RETURN:      None
>  *
>  * DESCRIPTION: Enter/Exit the raw character input mode for the terminal.
>  *
>  * Interactive line-editing support for the AML debugger. Used with the
>  * common/acgetline module.
>  *
>  * readline() is not used because of non-portability. It is not available
>  * on all systems, and if it is, often the package must be manually installed.
>  *
>  * Therefore, we use the POSIX tcgetattr/tcsetattr and do the minimal line
>  * editing that we need in AcpiOsGetLine.
>  *
>  * If the POSIX tcgetattr/tcsetattr interfaces are unavailable, these
>  * calls will also work:
>  *     For OsEnterLineEditMode: system ("stty cbreak -echo")
>  *     For OsExitLineEditMode:  system ("stty cooked echo")
>  *
>  *****************************************************************************/
>

acpiexec can't see into NVS though, I assume, which I imagine prevents
it from being very useful to debug my laptop, which seems to stick all
kinds of interesting things in NVS.

Anyway, could acpidbg do the same thing?

--Andy