On Wed, Dec 2, 2015 at 5:42 PM, Zheng, Lv <lv.zheng@xxxxxxxxx> wrote: > 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 > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
