On Thu, Dec 3, 2015 at 2:28 AM, Andy Lutomirski <luto@xxxxxxxxxx> wrote: > 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. 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 -- 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
