On Thu, Oct 05, 2017 at 07:03:24PM +0000, Mario.Limonciello@xxxxxxxx wrote: > > -----Original Message----- > > From: Greg KH [mailto:greg@xxxxxxxxx] > > Sent: Thursday, October 5, 2017 1:47 PM > > To: Darren Hart <dvhart@xxxxxxxxxxxxx> > > Cc: Pali Rohár <pali.rohar@xxxxxxxxx>; Limonciello, Mario > > <Mario_Limonciello@xxxxxxxx>; andy.shevchenko@xxxxxxxxx; linux- > > kernel@xxxxxxxxxxxxxxx; platform-driver-x86@xxxxxxxxxxxxxxx; luto@xxxxxxxxxx; > > quasisec@xxxxxxxxxx; rjw@xxxxxxxxxxxxx; mjg59@xxxxxxxxxx; hch@xxxxxx > > Subject: Re: [PATCH v4 12/14] platform/x86: wmi: create character devices when > > requested by drivers > > > > On Thu, Oct 05, 2017 at 10:39:25AM -0700, Darren Hart wrote: > > > > 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. > > > > > > > > > > We don't use the MOF data in any of the existing wmi drivers, because > > > they are all oddities which map to kernel managed subsystems (hotkeys, > > > LED control, RF Kill switches) rather than what WMI (Windows > > > Manageability Interface) was designed for. The intent of these patches > > > to enable that management aspect of the platform. > > > > > > This is the biggest hurdle for WMI support. > > > > > > WMI was designed to bypass the OS, and is used in consumer devices > > > intended to run Windows. This leads to an interface that is very vendor > > > specific and not consistently broken up into nice functional blocks. > > > > > > Vendors would like to use this interface in Linux as it is being used in > > > Windows. Specifically, they want to be able to have a generic system in > > > the kernel which allows the WMI mechanism to be used by userspace, > > > without the need to patch the kernel for every platform. > > > > And how _exactly_ is this interface exposed in Windows? Is it ad-hoc > > with custom kernel drivers written by each vendor? Or does the OS > > provide a "sane" interface for it? > > On Windows it's a driver-less solution. Vendors don't do anything other > than provide the MOF (which describes how the data passed to ASL looks). How do they "provide it"? > When Windows boots up, _WDG is parsed, Who parses it, the Windows kernel? > the binary MOF is loaded into the WMI repository. Who does the loading? Where does the "WMI repository" live? > The MOF describes how named objects map to GUIDs which map to ASL. So this all lives in kernelspace? > From Powershell or from any application that uses WMI as admin you can > look up the root namespace and see all objects. And what is the interface that powershell uses to get that information from the kerenel? > You can pass calls back > and forth. There's all sorts of examples of it here: > https://msdn.microsoft.com/en-us/library/windows/hardware/dn614028(v=vs.85).aspx > > Windows doesn't validate the data when it's passed to ASL and back. How do you know? Who does the "passing"? The Windows kernel is just a blind pipe? If so, then what does the mappings? > It just knows what it looks like, size of the buffer and relays the information. relays from/to what? > It's up to firmware to block the crazy stuff that you can put in a buffer. So userspace can pass any blob it wants to the firmware through this interface and the kernel does not parse anything? How is that "protected"? > > Again, I like my TPM to work, and I don't want a random rootkit exploit > > to be able to destroy it :) > > I'd like to however point out you can't kill your TPM from this interface. On _your_ platform, can you guarantee it on any other platform? :) And I strongly doubt your BIOS would stand up to a good fuzzer, almost no firmware can. Heck, the kernel even has issues, we've been fixing them for years... thanks, greg k-h
