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". We allow ACPI custom methods -- surely this is slightly less awful. Heck, we have /dev/mem, too. That's arguably much more dangerous. --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
