On Thu, Oct 05, 2017 at 05:51:56PM +0200, Pali Rohár wrote: > On Thursday 05 October 2017 17:42:14 Greg KH wrote: > > > > > --- /dev/null > > > > > +++ b/include/uapi/linux/wmi.h > > > > > @@ -0,0 +1,10 @@ > > > > > +#ifndef _UAPI_LINUX_WMI_H > > > > > +#define _UAPI_LINUX_WMI_H > > > > > + > > > > > +#define WMI_IOC 'W' > > > > > +#define WMI_IO(instance) _IO(WMI_IOC, instance) > > > > > +#define WMI_IOR(instance) _IOR(WMI_IOC, instance, void*) > > > > > +#define WMI_IOW(instance) _IOW(WMI_IOC, instance, void*) > > > > > +#define WMI_IOWR(instance) _IOWR(WMI_IOC, instance, void*) > > > > > > > > Ugh, void *, this is going to be "fun"... > > > > > > > > My comments on just how fun is left for the actual driver that attempted > > > > to implement these... > > > > > > > > > > So until in kernel MOF parsing is available you can't predict the format of > > > what an individual ACPI method will expect for its input. Even when the in > > > kernel MOF parsing is made available the data types may be complex structures. > > > > > > I have no idea what MOF is, what "parsing" is involved, or how in the > > world ACPI got involved here... > > > > good luck! > > > > greg k-h > > Hi Greg! Simple description: In ACPI is stored binary MOF buffer which > describe format (function name, parameters, sizeof and type of > parameters, etc) for all those calls. > > Basically it is what should be used for checking if userspace pass > correct "buffer" via ioctl to WMI. > > But that binary MOF is undocumented, invented by Microsoft... and > present in every one ACPI BIOS notebook (which uses WMI). It is > de-facto industrial standard, just tools for encoding/decoding it are > only for Microsoft Windows systems. > > I was able to decipher that format and wrote simple userspace parser: > https://github.com/pali/bmfdec > > Funny part is that format is not encrypted, but compressed by DMSDOS > compatible compression algorithm :-) You probably would remember old > FAT16 days with compression... > > Hope that it helps you to understand it. It does, thanks. And as we now understand it (I'm guessing it had to be semi-understood in the older wmi drivers already), validating it properly seems to be the key for creating an interface that we "know" to be safe. thanks, greg k-h
