Hi, Andy Sorry for the delay of reply. > From: Andy Lutomirski [mailto:luto@xxxxxxxxxx] > Sent: Thursday, December 3, 2015 9:29 AM > > On Wed, Dec 2, 2015 at 5:26 PM, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > On Thu, Dec 3, 2015 at 2:22 AM, Andy Lutomirski <luto@xxxxxxxxxx> wrote: > >> On Wed, Dec 2, 2015 at 5:13 PM, Rafael J. Wysocki <rafael@xxxxxxxxxx> > wrote: > >>> Hi, > >>> > >>> On Thu, Dec 3, 2015 at 1:37 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> > 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 ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
