From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932408AbdDRT2o (ORCPT ); Tue, 18 Apr 2017 15:28:44 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:35127 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753725AbdDRT2j (ORCPT ); Tue, 18 Apr 2017 15:28:39 -0400 From: Pali =?utf-8?q?Roh=C3=A1r?= To: Darren Hart Subject: Re: RFC: WMI Enhancements Date: Tue, 18 Apr 2017 21:28:36 +0200 User-Agent: KMail/1.13.7 (Linux/3.13.0-116-generic; KDE/4.14.2; x86_64; ; ) Cc: "Rafael J. Wysocki" , Andy Lutomirski , Len Brown , Corentin Chary , Mario Limonciello , Andy Lutomirski , Andy Shevchenko , LKML , platform-driver-x86@vger.kernel.org, "linux-pm@vger.kernel.org" References: <20170412230854.GA11963@fury> <3317007.TCiWpp4m4U@aspire.rjw.lan> <20170418163325.GC25405@fury> In-Reply-To: <20170418163325.GC25405@fury> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3047452.Q8gNyM5XZR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201704182128.36169@pali> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --nextPart3047452.Q8gNyM5XZR Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tuesday 18 April 2017 18:33:25 Darren Hart wrote: > On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote: > > On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote: > > > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote: > > > > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart > > > > wrote: > > > > > On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki > > > > > wrote: > > > > >> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote: > > > > >> > Hi All, > > > > >> >=20 > > > > >> > There are a few parallel efforts involving the Windows > > > > >> > Management Instrumentation (WMI)[1] and dependent/related > > > > >> > drivers. I'd like to have a round of discussion among > > > > >> > those of you that have been involved in this space before > > > > >> > we decide on a direction. > > > > >> >=20 > > > > >> > The WMI support in the kernel today fairly narrowly > > > > >> > supports a handful of systems. Andy L. has a > > > > >> > work-in-progress series [2] which converts wmi into a > > > > >> > platform device and a proper bus, providing devices for > > > > >> > dependent drivers to bind to, and a mechanism for sibling > > > > >> > devices to communicate with each other. I've reviewed the > > > > >> > series and feel like the approach is sound, I plan to > > > > >> > carry this series forward and merge it (with Andy L's > > > > >> > permission). > > > > >> >=20 > > > > >> > Are there any objections to this? > > > > >> >=20 > > > > >> > In Windows, applications interact with WMI more or less > > > > >> > directly. We don't do this in Linux currently, although > > > > >> > it has been discussed in the past [3]. Some vendors will > > > > >> > work around this by performing SMI/SMM, which is > > > > >> > inefficient at best. Exposing WMI methods to userspace > > > > >> > would bring parity to WMI for Linux and Windows. > > > > >> >=20 > > > > >> > There are two principal concerns I'd appreciate your > > > > >> > thoughts on: > > > > >> >=20 > > > > >> > a) As an undiscoverable interface (you need to know the > > > > >> > method signatures ahead of time), universally exposing > > > > >> > every WMI "device" to userspace seems like "a bad idea" > > > > >> > from a security and stability perspective. While access > > > > >> > would certainly be privileged, it seems more prudent to > > > > >> > make this exposure opt-in. We also handle some of this > > > > >> > with kernel drivers and exposing those "devices" to > > > > >> > userspace would enable userspace and the kernel to fight > > > > >> > over control. So - if we expose WMI devices to userspace, > > > > >> > I believe this should be done on a case by case basis, > > > > >> > opting in, and not by default as part of the WMI driver > > > > >> > (although it can provide the mechanism for a sub-driver > > > > >> > to use), and possibly a devmode to do so by default. > > > > >>=20 > > > > >> A couple of loose thoughts here. > > > > >>=20 > > > > >> In principle there could be a "generic default WMI driver" > > > > >> or similar that would "claim" all WMI "devices" that have > > > > >> not been "claimed" by anyone else and would simply expose > > > > >> them to user space somehow (e.g. using a chardev > > > > >> interface). > > > > >>=20 > > > > >> Then, depending on how that thing is implemented, opt-in etc > > > > >> should be possible too. > > > > >=20 > > > > > I think we agree this would be an ideal approach. > > > > >=20 > > > > > As we look into this more, it is becoming clear that the > > > > > necessary functionality is not nicely divided into GUIDs for > > > > > what is necessary in userspace and what is handled in the > > > > > kernel. A single WMI METHOD GUID may be needed by userspace > > > > > for certain functionality, while the kernel drivers may use > > > > > it for something else. > > > > >=20 > > > > > :-( > > > > >=20 > > > > > The input to a WMI method is just a buffer, so it is very > > > > > free form. One approach Mario has mentioned was to audit the > > > > > user space WMI METHOD calls in the kernel platform drivers > > > > > and reject those calls with arguments matching those issued > > > > > by the kernel driver. This is likely to be complex and error > > > > > prone in my opinion. However, I have not yet thought of > > > > > another means to meet the requirement of having disjoint > > > > > feature sets for userspace and kernel space via a mechanism > > > > > that was effectively designed to be used solely from user > > > > > space with vendor defined method signatures. > > > > >=20 > > > > > Next step is to look at just how complex it would be to audit > > > > > the method calls the kernel currently uses. > > > >=20 > > > > I'm wondering whether it's really worth it. We already allow > > > > doing darned near anything using dcdbas. Maybe the world > > > > won't end if we expose a complete-ish ioctl interface to WMI. > >=20 > > I guess the world wouldn't end then (it has not ended for far more > > serious reasons so far after all), but this also doesn't feel > > entirely right. > >=20 > > For one, if something is used inside of the kernel (by drivers > > etc), then allowing user space to use the same thing directly is a > > recipe for unsupportable mess IMO. >=20 > I don't disagree. Unforuntately, the mechanism wasn't designed for > this kind of mixed usage from what I can determine, so it doesn't > lend itself to separation. Yes, and this is reason why abstract generic interface has problems and=20 cannot be really generic. > We could kick out all the WMI drivers and > encourage vendor/platform specific system daemons which read WMI and > injected events and configured LEDs through sysfs, thus eliminating > the user/kernel conflict - but it would only leave us with the > problem of multiple userspace daemons competing for the same WMI > METHODs -- and yeah, nobody's going for that :-D IMO, this will only results in more problems as we already have and does=20 not bring any value. Just anarchy, like in windows world. > > > > Also, dcdbas is, to put it mildly, a bit ridiculous. It seems > > > > to be a seriously awkward sysfs interface that allows you to, > > > > drumroll please, issue outb and inb instructions. It doesn't > > > > even check that it's running on a Dell system. It might be > > > > nice to deprecate it some day in favor of a real interface.=20 > > > > I'd consider a low-level WMI ioctl interface to be a vast > > > > improvement. > > >=20 > > > I've been reluctantly arriving here as well. Given that every WMI > > > interface will be vendor specific, and non-discoverable, it > > > seems unlikely developers will eagerly duplicate kernel > > > functionality in user-space. And if they do, it will affect very > > > few platforms. > > >=20 > > > I still think it makes sense to only expose a WMI interface by > > > default on some matching criteria. It could be DMI related, but > > > I'd like to know if the UID is possible as well (it depends on > > > how vendors use the UID, if consistently, not at all, etc.) > > > Otherwise, the interface would not be enabled unless the user > > > explicitly requests it via a module parameter or similar. > >=20 > > To me, that should be the bare minimum, but I really think that > > mutual exclusion between user space and the kernel needs to be > > ensured somehow when the interface is enabled too. > >=20 > > This looks similar to exposing _DSM functionality for certain > > device to user space where some functions of the _DSM in question > > are already in use by kernel code. In that case I would think > > about an interface with a function granularity (so it would check > > the GUID and the function and possibly the ordering with respect > > to the other functions too before invoking the _DSM on behalf of > > user space). >=20 > This is also what I would consider to be ideal, but the mechanism > doesn't lend itself to that level of granularity. WMI methods are > not guaranteed to be broken up into sufficiently granular > functionality that we can filter based on method ID. We would most > likely end up in the position of having to audit the input buffer of > every WMI call. And still, if write audit filters for every one existing wmi driver in=20 kernel, there still audit filter can say to userspace that current=20 request cannot be accepted and sent to firmware. This would mean that userspace application would not be able to do ANY=20 WMI method call (as e.g. on windows) and so for some vendors it can be=20 useless. And here I'm not sure, how hard would be to write those audit filters=20 for all wmi kernel drivers and if it would be possible without wmi=20 documentation of those vendor apis (which we do not have). Potential vendors can decide based on above fact, that their userspace=20 application rather rmmod wmi kernel driver for particular GUID (which=20 release occupation of wmi device) and their userspace application starts=20 working. And this is I think situation which is bad for kernel and we=20 should prevent it. > For example, we can filter things the ASUS WMI Keyboard Filter > method, but others are less specific, like Device Set, Bios Status, > Device Status, Device Policy, etc. >=20 > What we could do is make that the vendor's problem instead of the > kernel's problem. Consider: >=20 > * wmi.c adds method evaluation wrappers > * add a wmi evaluation mutex > * update *wmi.c drivers to use the new wrappers > * platform drivers (dell-wmi.c, asus-wmi.c, etc.) must explicitly > request wmi.c to export the wmi chardev > * platform drivers must explicitly whitelist each method ID to be > exported - they can automate this in a loop evaluating the wmi block > if they wish * platform drivers *may* register a wmi evaluation > filter which allows them to audit the method id and input buffer to > ensure it doesn't conflict with in-kernel usage (their usage). >=20 > I believe this is a reasonable compromise, and it places the burden > on the platform drivers, and therefor on the vendors (in the best > case) or the individual platform driver maintainers for less > cooperative vendors. This contains any resulting exposure to the > platforms which explicitly request it. =2D-=20 Pali Roh=C3=A1r pali.rohar@gmail.com --nextPart3047452.Q8gNyM5XZR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAlj2aOQACgkQi/DJPQPkQ1KO4QCfdN1s5z1ccbo/HysjcgzvNod5 bNQAoMqFE/Cih8DOs+I7736LiRScp1bI =36Xv -----END PGP SIGNATURE----- --nextPart3047452.Q8gNyM5XZR--