Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1622607 > unrolled thread
| Started by | Darren Hart <dvhart@infradead.org> |
|---|---|
| First post | 2017-04-13 01:10 +0200 |
| Last post | 2017-04-18 23:20 +0200 |
| Articles | 20 on this page of 51 — 10 participants |
Back to article view | Back to linux.kernel
RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 01:10 +0200
Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-13 09:40 +0200
Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 19:00 +0200
RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 22:40 +0200
Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-14 02:00 +0200
RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-14 19:50 +0200
Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-14 20:30 +0200
RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-14 21:10 +0200
Re: RFC: WMI Enhancements Michał Kępień <kernel@kempniu.pl> - 2017-04-13 09:40 +0200
RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 15:50 +0200
Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-13 16:00 +0200
Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 17:40 +0200
RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 18:00 +0200
Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 18:10 +0200
RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 17:50 +0200
Re: RFC: WMI Enhancements Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2017-04-18 12:00 +0200
RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-18 16:10 +0200
Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 17:40 +0200
Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 17:50 +0200
Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 18:20 +0200
Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-13 17:50 +0200
Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 18:00 +0200
RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 19:00 +0200
Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 19:10 +0200
Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 19:50 +0200
RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 20:00 +0200
RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 19:50 +0200
Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-18 10:00 +0200
Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-18 19:00 +0200
Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-18 21:30 +0200
RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 18:00 +0200
Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 19:10 +0200
Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 19:40 +0200
RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 19:50 +0200
Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 18:10 +0200
Re: RFC: WMI Enhancements "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-04-15 01:00 +0200
Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-15 01:10 +0200
Re: RFC: WMI Enhancements Andy Lutomirski <luto@amacapital.net> - 2017-04-18 00:10 +0200
Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-18 01:20 +0200
Re: RFC: WMI Enhancements "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-04-18 15:20 +0200
Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-18 18:40 +0200
Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-18 21:30 +0200
Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-19 00:50 +0200
Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-19 10:00 +0200
RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-19 18:40 +0200
Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-19 19:00 +0200
RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-19 19:30 +0200
Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-20 15:20 +0200
Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-20 22:50 +0200
Re: RFC: WMI Enhancements Christoph Hellwig <hch@infradead.org> - 2017-04-20 16:20 +0200
Re: RFC: WMI Enhancements "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-18 23:20 +0200
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | Pali Rohár <pali.rohar@gmail.com> |
|---|---|
| Date | 2017-04-13 17:50 +0200 |
| Message-ID | <tvPap-4WE-3@gated-at.bofh.it> |
| In reply to | #1623123 |
[Multipart message — attachments visible in raw view] — view raw
On Thursday 13 April 2017 17:32:48 Andy Lutomirski wrote: > On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl> > wrote: > > What we still need, though, is an open source version of > > wmiofck.exe. I am unaware of anything like that existing and > > installing the Windows Driver Kit just to run one command which > > spits out a single *.h file is not something I would describe as > > convenient (been there). > > I haven't tried to see whether they do what's needed, but there's > OpenWBEM and OpenPegasus. > > Anyway, if such a tool exists, it would be handy to expose the binary > MOF data to userspace so the tool could be used to help get WMI > working on new platforms. In this case, when WMI stay in kernel, MOF data could be exported via debugfs? I think there is no need to have them in sysfs stable ABI. As above usage (get WMI working on new platforms) looks like for debugging purpose. -- Pali Rohár pali.rohar@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@kernel.org> |
|---|---|
| Date | 2017-04-13 18:00 +0200 |
| Message-ID | <tvPk5-514-3@gated-at.bofh.it> |
| In reply to | #1623123 |
On Thu, Apr 13, 2017 at 8:55 AM, <Mario.Limonciello@dell.com> wrote: > > >> -----Original Message----- >> From: Andy Lutomirski [mailto:luto@kernel.org] >> Sent: Thursday, April 13, 2017 10:33 AM >> To: Michał Kępień <kernel@kempniu.pl> >> Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki <rjw@rjwysocki.net>; >> Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; Corentin >> Chary <corentin.chary@gmail.com>; Limonciello, Mario >> <Mario_Limonciello@Dell.com>; Andy Lutomirski <luto@kernel.org>; Andy >> Shevchenko <andriy.shevchenko@linux.intel.com>; LKML <linux- >> kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org; linux- >> pm@vger.kernel.org >> Subject: Re: RFC: WMI Enhancements >> >> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl> wrote: >> >> Hi All, >> >> >> >> 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. >> >> >> >> 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). >> >> >> >> Are there any objections to this? >> > >> > Back in January 2016, I sent Andy a few minor comments about this >> > series. A year later, I offered to iron out the remaining issues and >> > resubmit the series in Andy's name when I find the time. Sadly, >> > things have changed a bit for me since that time and it is unlikely >> > that I will be able to deliver, for which I am sorry. >> > >> > However, browsing Andy's branch I see that most issues have been >> > resolved, though I think some of my remarks [1] have either been >> > missed or silently refuted :) >> > >> > Anyway, I also like this approach and I think this series is a >> > valuable cleanup. >> >> Me too :) >> >> >> 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. >> >> >> >> There are two principal concerns I'd appreciate your thoughts on: >> >> >> >> 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. >> >> I agree. I don't want too see gnome-whatever-widget talking directly to WMI and >> confusing the kernel driver for the same thing. > > So there are plenty of other things that can be done by WMI that don't > really make sense to live in the kernel, particularly on what Dell exposes via > WMI. > > If the desire of this group ends up being to not expose WMI by default, > I'd like to at least propose it be exposed for the GUID's Dell is using. Is it just the "call SMBIOS" GUID or are there other things? > > Perhaps as part of changing dell-smbios to use WMI, also extend it's > functionality to userspace. > Could this still result in userspace and the kernel fighting over control of various bits of the system? If so, that's a bit less than ideal.
[toc] | [prev] | [next] | [standalone]
| From | <Mario.Limonciello@dell.com> |
|---|---|
| Date | 2017-04-13 19:00 +0200 |
| Message-ID | <tvQga-5H7-33@gated-at.bofh.it> |
| In reply to | #1623139 |
> -----Original Message----- > From: Andy Lutomirski [mailto:luto@kernel.org] > Sent: Thursday, April 13, 2017 10:58 AM > To: Limonciello, Mario <Mario_Limonciello@Dell.com> > Cc: Andrew Lutomirski <luto@kernel.org>; Michał Kępień <kernel@kempniu.pl>; > Darren Hart <dvhart@infradead.org>; Rafael J. Wysocki <rjw@rjwysocki.net>; Len > Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; Corentin > Chary <corentin.chary@gmail.com>; Andy Shevchenko > <andriy.shevchenko@linux.intel.com>; linux-kernel@vger.kernel.org; platform- > driver-x86@vger.kernel.org; linux-pm@vger.kernel.org > Subject: Re: RFC: WMI Enhancements > > On Thu, Apr 13, 2017 at 8:55 AM, <Mario.Limonciello@dell.com> wrote: > > > > > >> -----Original Message----- > >> From: Andy Lutomirski [mailto:luto@kernel.org] > >> Sent: Thursday, April 13, 2017 10:33 AM > >> To: Michał Kępień <kernel@kempniu.pl> > >> Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki <rjw@rjwysocki.net>; > >> Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; > Corentin > >> Chary <corentin.chary@gmail.com>; Limonciello, Mario > >> <Mario_Limonciello@Dell.com>; Andy Lutomirski <luto@kernel.org>; Andy > >> Shevchenko <andriy.shevchenko@linux.intel.com>; LKML <linux- > >> kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org; linux- > >> pm@vger.kernel.org > >> Subject: Re: RFC: WMI Enhancements > >> > >> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl> wrote: > >> >> Hi All, > >> >> > >> >> 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. > >> >> > >> >> 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). > >> >> > >> >> Are there any objections to this? > >> > > >> > Back in January 2016, I sent Andy a few minor comments about this > >> > series. A year later, I offered to iron out the remaining issues and > >> > resubmit the series in Andy's name when I find the time. Sadly, > >> > things have changed a bit for me since that time and it is unlikely > >> > that I will be able to deliver, for which I am sorry. > >> > > >> > However, browsing Andy's branch I see that most issues have been > >> > resolved, though I think some of my remarks [1] have either been > >> > missed or silently refuted :) > >> > > >> > Anyway, I also like this approach and I think this series is a > >> > valuable cleanup. > >> > >> Me too :) > >> > >> >> 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. > >> >> > >> >> There are two principal concerns I'd appreciate your thoughts on: > >> >> > >> >> 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. > >> > >> I agree. I don't want too see gnome-whatever-widget talking directly to WMI > and > >> confusing the kernel driver for the same thing. > > > > So there are plenty of other things that can be done by WMI that don't > > really make sense to live in the kernel, particularly on what Dell exposes via > > WMI. > > > > If the desire of this group ends up being to not expose WMI by default, > > I'd like to at least propose it be exposed for the GUID's Dell is using. > > Is it just the "call SMBIOS" GUID or are there other things? There are some other things too, but I'll need to discuss with an internal team first to clarify. > > > > > Perhaps as part of changing dell-smbios to use WMI, also extend it's > > functionality to userspace. > > > > Could this still result in userspace and the kernel fighting over > control of various bits of the system? If so, that's a bit less than > ideal. No more than exists today with the dcdbas SMI interface (which only if you manually run userspace tools that manipulate the same data you can do that technically). We're all reasonable folks, if there is an instance of this that comes up we can make changes to userspace to fix it.
[toc] | [prev] | [next] | [standalone]
| From | Darren Hart <dvhart@infradead.org> |
|---|---|
| Date | 2017-04-13 19:10 +0200 |
| Message-ID | <tvQpQ-62k-19@gated-at.bofh.it> |
| In reply to | #1623192 |
On Thu, Apr 13, 2017 at 04:54:25PM +0000, Mario.Limonciello@dell.com wrote: > > -----Original Message----- > > From: Andy Lutomirski [mailto:luto@kernel.org] > > Sent: Thursday, April 13, 2017 10:58 AM > > To: Limonciello, Mario <Mario_Limonciello@Dell.com> > > Cc: Andrew Lutomirski <luto@kernel.org>; Michał Kępień <kernel@kempniu.pl>; > > Darren Hart <dvhart@infradead.org>; Rafael J. Wysocki <rjw@rjwysocki.net>; Len > > Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; Corentin > > Chary <corentin.chary@gmail.com>; Andy Shevchenko > > <andriy.shevchenko@linux.intel.com>; linux-kernel@vger.kernel.org; platform- > > driver-x86@vger.kernel.org; linux-pm@vger.kernel.org > > Subject: Re: RFC: WMI Enhancements > > > > On Thu, Apr 13, 2017 at 8:55 AM, <Mario.Limonciello@dell.com> wrote: > > > > > > > > >> -----Original Message----- > > >> From: Andy Lutomirski [mailto:luto@kernel.org] > > >> Sent: Thursday, April 13, 2017 10:33 AM > > >> To: Michał Kępień <kernel@kempniu.pl> > > >> Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki <rjw@rjwysocki.net>; > > >> Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; > > Corentin > > >> Chary <corentin.chary@gmail.com>; Limonciello, Mario > > >> <Mario_Limonciello@Dell.com>; Andy Lutomirski <luto@kernel.org>; Andy > > >> Shevchenko <andriy.shevchenko@linux.intel.com>; LKML <linux- > > >> kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org; linux- > > >> pm@vger.kernel.org > > >> Subject: Re: RFC: WMI Enhancements > > >> > > >> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl> wrote: > > >> >> Hi All, > > >> >> > > >> >> 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. > > >> >> > > >> >> 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). > > >> >> > > >> >> Are there any objections to this? > > >> > > > >> > Back in January 2016, I sent Andy a few minor comments about this > > >> > series. A year later, I offered to iron out the remaining issues and > > >> > resubmit the series in Andy's name when I find the time. Sadly, > > >> > things have changed a bit for me since that time and it is unlikely > > >> > that I will be able to deliver, for which I am sorry. > > >> > > > >> > However, browsing Andy's branch I see that most issues have been > > >> > resolved, though I think some of my remarks [1] have either been > > >> > missed or silently refuted :) > > >> > > > >> > Anyway, I also like this approach and I think this series is a > > >> > valuable cleanup. > > >> > > >> Me too :) > > >> > > >> >> 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. > > >> >> > > >> >> There are two principal concerns I'd appreciate your thoughts on: > > >> >> > > >> >> 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. > > >> > > >> I agree. I don't want too see gnome-whatever-widget talking directly to WMI > > and > > >> confusing the kernel driver for the same thing. > > > > > > So there are plenty of other things that can be done by WMI that don't > > > really make sense to live in the kernel, particularly on what Dell exposes via > > > WMI. > > > > > > If the desire of this group ends up being to not expose WMI by default, > > > I'd like to at least propose it be exposed for the GUID's Dell is using. > > > > Is it just the "call SMBIOS" GUID or are there other things? > > There are some other things too, but I'll need to discuss with an internal > team first to clarify. > > > > > > > > > Perhaps as part of changing dell-smbios to use WMI, also extend it's > > > functionality to userspace. > > > > > > > Could this still result in userspace and the kernel fighting over > > control of various bits of the system? If so, that's a bit less than > > ideal. > > No more than exists today with the dcdbas SMI interface (which > only if you manually run userspace tools that manipulate the same > data you can do that technically). > > We're all reasonable folks, if there is an instance of this that comes > up we can make changes to userspace to fix it. Right. As Pali pointed out previously, if there is an existing class driver / subsystem which supports this functionality we should use that. I suppose one risk will be one GUID exposing both types of methods. Those which are used by kernel drivers, and those which have no kernel support. Or worse, methods which have multiple behaviors depending on their input arguments. -- Darren Hart VMware Open Source Technology Center
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@kernel.org> |
|---|---|
| Date | 2017-04-13 19:50 +0200 |
| Message-ID | <tvR2y-6iE-27@gated-at.bofh.it> |
| In reply to | #1623200 |
On Thu, Apr 13, 2017 at 10:39 AM, <Mario.Limonciello@dell.com> wrote: >> -----Original Message----- >> From: Darren Hart [mailto:dvhart@infradead.org] >> Sent: Thursday, April 13, 2017 12:06 PM >> To: Limonciello, Mario <Mario_Limonciello@Dell.com> >> Cc: luto@kernel.org; kernel@kempniu.pl; rjw@rjwysocki.net; >> len.brown@intel.com; pali.rohar@gmail.com; corentin.chary@gmail.com; >> andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org; platform- >> driver-x86@vger.kernel.org; linux-pm@vger.kernel.org >> Subject: Re: RFC: WMI Enhancements >> > Well the "most" interesting to me is the SMBIOS calling interface on the > regular Dell GUID (WMBA IIRC). That's what is used to manipulate keyboard > LED timeouts in dell-laptop (although through direct SMI today). > > It's also what is used for other SMBIOS calls like changing random BIOS settings > that shouldn't be generically exposed in sysfs but should be controlled by > manageability tools. > > Example: turning on/off legacy option ROM or changing legacy boot order. > IIUC we basically can't expose the SMI--based interface to this entry point to userspace because of its use of physical addressing. It is reasonably safe to expose the WMI version? (IOW should be expect that it doesn't enable kernel-mode or SMM code execution?) TBH, I've occasionally considered writing a driver to expose SMM code execution on systems with a known reliable exploit :)
[toc] | [prev] | [next] | [standalone]
| From | <Mario.Limonciello@dell.com> |
|---|---|
| Date | 2017-04-13 20:00 +0200 |
| Message-ID | <tvRce-6mR-5@gated-at.bofh.it> |
| In reply to | #1623224 |
> -----Original Message----- > From: Andy Lutomirski [mailto:luto@kernel.org] > Sent: Thursday, April 13, 2017 12:44 PM > To: Limonciello, Mario <Mario_Limonciello@Dell.com> > Cc: Darren Hart <dvhart@infradead.org>; Andrew Lutomirski <luto@kernel.org>; > Michał Kępień <kernel@kempniu.pl>; Rafael J. Wysocki <rjw@rjwysocki.net>; Len > Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; Corentin > Chary <corentin.chary@gmail.com>; Andy Shevchenko > <andriy.shevchenko@linux.intel.com>; linux-kernel@vger.kernel.org; platform- > driver-x86@vger.kernel.org; linux-pm@vger.kernel.org > Subject: Re: RFC: WMI Enhancements > > On Thu, Apr 13, 2017 at 10:39 AM, <Mario.Limonciello@dell.com> wrote: > >> -----Original Message----- > >> From: Darren Hart [mailto:dvhart@infradead.org] > >> Sent: Thursday, April 13, 2017 12:06 PM > >> To: Limonciello, Mario <Mario_Limonciello@Dell.com> > >> Cc: luto@kernel.org; kernel@kempniu.pl; rjw@rjwysocki.net; > >> len.brown@intel.com; pali.rohar@gmail.com; corentin.chary@gmail.com; > >> andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org; platform- > >> driver-x86@vger.kernel.org; linux-pm@vger.kernel.org > >> Subject: Re: RFC: WMI Enhancements > >> > > > Well the "most" interesting to me is the SMBIOS calling interface on the > > regular Dell GUID (WMBA IIRC). That's what is used to manipulate keyboard > > LED timeouts in dell-laptop (although through direct SMI today). > > > > It's also what is used for other SMBIOS calls like changing random BIOS settings > > that shouldn't be generically exposed in sysfs but should be controlled by > > manageability tools. > > > > Example: turning on/off legacy option ROM or changing legacy boot order. > > > > IIUC we basically can't expose the SMI--based interface to this entry > point to userspace because of its use of physical addressing. It is > reasonably safe to expose the WMI version? (IOW should be expect that > it doesn't enable kernel-mode or SMM code execution?) The SMI based entry is already exposed using dcdbas. The WMI version when executing a call that would be run as a SMI will copy the buffer to an area of memory that the BIOS has already been marked reserved to execute the SMI and copy the result out. > > TBH, I've occasionally considered writing a driver to expose SMM code > execution on systems with a known reliable exploit :) On Dell HW? I'm sure our security folks would be very interested in this.
[toc] | [prev] | [next] | [standalone]
| From | <Mario.Limonciello@dell.com> |
|---|---|
| Date | 2017-04-13 19:50 +0200 |
| Message-ID | <tvR2y-6iE-13@gated-at.bofh.it> |
| In reply to | #1623200 |
> -----Original Message----- > From: Darren Hart [mailto:dvhart@infradead.org] > Sent: Thursday, April 13, 2017 12:06 PM > To: Limonciello, Mario <Mario_Limonciello@Dell.com> > Cc: luto@kernel.org; kernel@kempniu.pl; rjw@rjwysocki.net; > len.brown@intel.com; pali.rohar@gmail.com; corentin.chary@gmail.com; > andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org; platform- > driver-x86@vger.kernel.org; linux-pm@vger.kernel.org > Subject: Re: RFC: WMI Enhancements > > On Thu, Apr 13, 2017 at 04:54:25PM +0000, Mario.Limonciello@dell.com wrote: > > > -----Original Message----- > > > From: Andy Lutomirski [mailto:luto@kernel.org] > > > Sent: Thursday, April 13, 2017 10:58 AM > > > To: Limonciello, Mario <Mario_Limonciello@Dell.com> > > > Cc: Andrew Lutomirski <luto@kernel.org>; Michał Kępień > <kernel@kempniu.pl>; > > > Darren Hart <dvhart@infradead.org>; Rafael J. Wysocki <rjw@rjwysocki.net>; > Len > > > Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; Corentin > > > Chary <corentin.chary@gmail.com>; Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com>; linux-kernel@vger.kernel.org; platform- > > > driver-x86@vger.kernel.org; linux-pm@vger.kernel.org > > > Subject: Re: RFC: WMI Enhancements > > > > > > On Thu, Apr 13, 2017 at 8:55 AM, <Mario.Limonciello@dell.com> wrote: > > > > > > > > > > > >> -----Original Message----- > > > >> From: Andy Lutomirski [mailto:luto@kernel.org] > > > >> Sent: Thursday, April 13, 2017 10:33 AM > > > >> To: Michał Kępień <kernel@kempniu.pl> > > > >> Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki > <rjw@rjwysocki.net>; > > > >> Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; > > > Corentin > > > >> Chary <corentin.chary@gmail.com>; Limonciello, Mario > > > >> <Mario_Limonciello@Dell.com>; Andy Lutomirski <luto@kernel.org>; Andy > > > >> Shevchenko <andriy.shevchenko@linux.intel.com>; LKML <linux- > > > >> kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org; linux- > > > >> pm@vger.kernel.org > > > >> Subject: Re: RFC: WMI Enhancements > > > >> > > > >> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl> > wrote: > > > >> >> Hi All, > > > >> >> > > > >> >> 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. > > > >> >> > > > >> >> 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). > > > >> >> > > > >> >> Are there any objections to this? > > > >> > > > > >> > Back in January 2016, I sent Andy a few minor comments about this > > > >> > series. A year later, I offered to iron out the remaining issues and > > > >> > resubmit the series in Andy's name when I find the time. Sadly, > > > >> > things have changed a bit for me since that time and it is unlikely > > > >> > that I will be able to deliver, for which I am sorry. > > > >> > > > > >> > However, browsing Andy's branch I see that most issues have been > > > >> > resolved, though I think some of my remarks [1] have either been > > > >> > missed or silently refuted :) > > > >> > > > > >> > Anyway, I also like this approach and I think this series is a > > > >> > valuable cleanup. > > > >> > > > >> Me too :) > > > >> > > > >> >> 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. > > > >> >> > > > >> >> There are two principal concerns I'd appreciate your thoughts on: > > > >> >> > > > >> >> 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. > > > >> > > > >> I agree. I don't want too see gnome-whatever-widget talking directly to WMI > > > and > > > >> confusing the kernel driver for the same thing. > > > > > > > > So there are plenty of other things that can be done by WMI that don't > > > > really make sense to live in the kernel, particularly on what Dell exposes via > > > > WMI. > > > > > > > > If the desire of this group ends up being to not expose WMI by default, > > > > I'd like to at least propose it be exposed for the GUID's Dell is using. > > > > > > Is it just the "call SMBIOS" GUID or are there other things? > > > > There are some other things too, but I'll need to discuss with an internal > > team first to clarify. > > > > > > > > > > > > > Perhaps as part of changing dell-smbios to use WMI, also extend it's > > > > functionality to userspace. > > > > > > > > > > Could this still result in userspace and the kernel fighting over > > > control of various bits of the system? If so, that's a bit less than > > > ideal. > > > > No more than exists today with the dcdbas SMI interface (which > > only if you manually run userspace tools that manipulate the same > > data you can do that technically). > > > > We're all reasonable folks, if there is an instance of this that comes > > up we can make changes to userspace to fix it. > > Right. As Pali pointed out previously, if there is an existing class driver / > subsystem which supports this functionality we should use that. > > I suppose one risk will be one GUID exposing both types of methods. Those which > are used by kernel drivers, and those which have no kernel support. Or worse, > methods which have multiple behaviors depending on their input arguments. > > -- Well the "most" interesting to me is the SMBIOS calling interface on the regular Dell GUID (WMBA IIRC). That's what is used to manipulate keyboard LED timeouts in dell-laptop (although through direct SMI today). It's also what is used for other SMBIOS calls like changing random BIOS settings that shouldn't be generically exposed in sysfs but should be controlled by manageability tools. Example: turning on/off legacy option ROM or changing legacy boot order.
[toc] | [prev] | [next] | [standalone]
| From | Pali Rohár <pali.rohar@gmail.com> |
|---|---|
| Date | 2017-04-18 10:00 +0200 |
| Message-ID | <txwdj-3uy-7@gated-at.bofh.it> |
| In reply to | #1623225 |
On Thursday 13 April 2017 17:39:56 Mario.Limonciello@dell.com wrote: > > > No more than exists today with the dcdbas SMI interface (which > > > only if you manually run userspace tools that manipulate the same > > > data you can do that technically). > > > > > > We're all reasonable folks, if there is an instance of this that comes > > > up we can make changes to userspace to fix it. > > > > Right. As Pali pointed out previously, if there is an existing class driver / > > subsystem which supports this functionality we should use that. > > > > I suppose one risk will be one GUID exposing both types of methods. Those which > > are used by kernel drivers, and those which have no kernel support. Or worse, > > methods which have multiple behaviors depending on their input arguments. > > > > -- > > Well the "most" interesting to me is the SMBIOS calling interface on the > regular Dell GUID (WMBA IIRC). That's what is used to manipulate keyboard > LED timeouts in dell-laptop (although through direct SMI today). > > It's also what is used for other SMBIOS calls like changing random BIOS settings > that shouldn't be generically exposed in sysfs but should be controlled by > manageability tools. > > Example: turning on/off legacy option ROM or changing legacy boot order. Which basically means that new WMI /dev/ files does not help for Dell. Kernel needs to manipulate with SMBIOS for implementing rfkill, keyboard backlight, display brightness and also needs to receive WMI events for hotkeys. So kernel modules would lock WMI interface for receiving events & sending SMBIOS calls, and userspace would be blocked from usage of this WMI GUID. I do not think that we can solve this problem easily in vendor-neutral interface. There was argument that WMI API was designed to allow userspace applications call firmware functions directly... But we are using WMI in kernel and we should not allow both kernel and userspace to fight on some WMI API. So for Dell we need for sure some Dell specific interface which covers all needed functionality. I'm not sure what everything Dell software needs, so what about specifying current usage of Dell SMBIOS/WMI functions from existing userspace applications and also planned usage in future? Then from this information we can design kernel and userspace API which can fit for Dell usage. About other vendor WMI's functions... I'm not sure, but there is again possibility that rfkill, leds or hotkeys would exists on same WMI GUID as other maintenance functions (which userspace wants), so export would be again blocked by kernel module for rfkill/leds/hotkeys. Therefore I'm not really sure if some /dev/wmi* API would be usefull, and not always blocked by kernel module which implements rfkill support. -- Pali Rohár pali.rohar@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Darren Hart <dvhart@infradead.org> |
|---|---|
| Date | 2017-04-18 19:00 +0200 |
| Message-ID | <txEDV-8uq-23@gated-at.bofh.it> |
| In reply to | #1625110 |
On Tue, Apr 18, 2017 at 09:54:01AM +0200, Pali Rohár wrote: > On Thursday 13 April 2017 17:39:56 Mario.Limonciello@dell.com wrote: > > > > No more than exists today with the dcdbas SMI interface (which > > > > only if you manually run userspace tools that manipulate the same > > > > data you can do that technically). > > > > > > > > We're all reasonable folks, if there is an instance of this that comes > > > > up we can make changes to userspace to fix it. > > > > > > Right. As Pali pointed out previously, if there is an existing class driver / > > > subsystem which supports this functionality we should use that. > > > > > > I suppose one risk will be one GUID exposing both types of methods. Those which > > > are used by kernel drivers, and those which have no kernel support. Or worse, > > > methods which have multiple behaviors depending on their input arguments. > > > > > > -- > > > > Well the "most" interesting to me is the SMBIOS calling interface on the > > regular Dell GUID (WMBA IIRC). That's what is used to manipulate keyboard > > LED timeouts in dell-laptop (although through direct SMI today). > > > > It's also what is used for other SMBIOS calls like changing random BIOS settings > > that shouldn't be generically exposed in sysfs but should be controlled by > > manageability tools. > > > > Example: turning on/off legacy option ROM or changing legacy boot order. > > Which basically means that new WMI /dev/ files does not help for Dell. > > Kernel needs to manipulate with SMBIOS for implementing rfkill, keyboard > backlight, display brightness and also needs to receive WMI events for > hotkeys. So kernel modules would lock WMI interface for receiving events > & sending SMBIOS calls, and userspace would be blocked from usage of > this WMI GUID. This is why we can't rely on a method ID granular filter for which methods are exported to userspace. In my previous reply to Rafael, I suggested platform drivers decide which method IDs are exported, and for platforms with insufficient WMI method ID granularity, we will end up exposing methods we also use in the kernel. The WMI evaluation will need to be centralized and placed under mutual exclusion. The optional wmi evaluation filter would allow for drivers to audit incoming calls from userspace to ensure no conflict. It's not ideal - but I believe it addresses our reality. > > I do not think that we can solve this problem easily in vendor-neutral > interface. There was argument that WMI API was designed to allow > userspace applications call firmware functions directly... But we are > using WMI in kernel and we should not allow both kernel and userspace to > fight on some WMI API. We could drop all the in kernel wmi drivers and rely on userspace daemons per platform.... but I think we all agree that is not where we want this to go. So we'll need to find a compromise. Even then, we'd need to avoid competition for common method IDs across multiple userspace applications. > > So for Dell we need for sure some Dell specific interface which covers > all needed functionality. I'm not sure what everything Dell software > needs, so what about specifying current usage of Dell SMBIOS/WMI > functions from existing userspace applications and also planned usage in > future? Then from this information we can design kernel and userspace > API which can fit for Dell usage. This was my initial response as well. The biggest problem with it is it places Linux imposed restrictions on the WMI mechanism, which will ultimately stifle innovation and/or leave Linux as a second class citizen for systems which rely on WMI for userspace firmware management. > > About other vendor WMI's functions... I'm not sure, but there is again > possibility that rfkill, leds or hotkeys would exists on same WMI GUID > as other maintenance functions (which userspace wants), so export would > be again blocked by kernel module for rfkill/leds/hotkeys. > > Therefore I'm not really sure if some /dev/wmi* API would be usefull, > and not always blocked by kernel module which implements rfkill support. I'd like to also point out that the Linux kernel has a minimal and targeted set of WMI drivers generally aimed at making laptops work as expected through the only mechanism we had access to. To my knowledge, we never sat down to discuss how WMI should be implemented in the Linux ecosystem. That leaves us in the situation we are in today, in which Linux essentially took the most expedient route to making laptops work - which happened to be WMI, but we didn't consider the broader implications of that mechanism or how what we implemented would interact with full set of functionality provided by WMI. So our challenge now is to look at WMI as a whole. How should it be implemented to achieve feature parity. And then consider how the existing drivers fit into that. Please see my proposal in response to Rafael's latest reply. I believe it outlines a reasonable compromise. Thanks, -- Darren Hart VMware Open Source Technology Center
[toc] | [prev] | [next] | [standalone]
| From | Pali Rohár <pali.rohar@gmail.com> |
|---|---|
| Date | 2017-04-18 21:30 +0200 |
| Message-ID | <txGZ3-1zP-13@gated-at.bofh.it> |
| In reply to | #1625464 |
[Multipart message — attachments visible in raw view] — view raw
On Tuesday 18 April 2017 18:56:31 Darren Hart wrote: > On Tue, Apr 18, 2017 at 09:54:01AM +0200, Pali Rohár wrote: > > On Thursday 13 April 2017 17:39:56 Mario.Limonciello@dell.com wrote: > > > > > No more than exists today with the dcdbas SMI interface > > > > > (which only if you manually run userspace tools that > > > > > manipulate the same data you can do that technically). > > > > > > > > > > We're all reasonable folks, if there is an instance of this > > > > > that comes up we can make changes to userspace to fix it. > > > > > > > > Right. As Pali pointed out previously, if there is an existing > > > > class driver / subsystem which supports this functionality we > > > > should use that. > > > > > > > > I suppose one risk will be one GUID exposing both types of > > > > methods. Those which are used by kernel drivers, and those > > > > which have no kernel support. Or worse, methods which have > > > > multiple behaviors depending on their input arguments. > > > > > > > > -- > > > > > > Well the "most" interesting to me is the SMBIOS calling interface > > > on the regular Dell GUID (WMBA IIRC). That's what is used to > > > manipulate keyboard LED timeouts in dell-laptop (although > > > through direct SMI today). > > > > > > It's also what is used for other SMBIOS calls like changing > > > random BIOS settings that shouldn't be generically exposed in > > > sysfs but should be controlled by manageability tools. > > > > > > Example: turning on/off legacy option ROM or changing legacy boot > > > order. > > > > Which basically means that new WMI /dev/ files does not help for > > Dell. > > > > Kernel needs to manipulate with SMBIOS for implementing rfkill, > > keyboard backlight, display brightness and also needs to receive > > WMI events for hotkeys. So kernel modules would lock WMI interface > > for receiving events & sending SMBIOS calls, and userspace would > > be blocked from usage of this WMI GUID. > > This is why we can't rely on a method ID granular filter for which > methods are exported to userspace. In my previous reply to Rafael, I > suggested platform drivers decide which method IDs are exported, and > for platforms with insufficient WMI method ID granularity, we will > end up exposing methods we also use in the kernel. The WMI > evaluation will need to be centralized and placed under mutual > exclusion. The optional wmi evaluation filter would allow for > drivers to audit incoming calls from userspace to ensure no > conflict. > > It's not ideal - but I believe it addresses our reality. Ok. > > I do not think that we can solve this problem easily in > > vendor-neutral interface. There was argument that WMI API was > > designed to allow userspace applications call firmware functions > > directly... But we are using WMI in kernel and we should not allow > > both kernel and userspace to fight on some WMI API. > > We could drop all the in kernel wmi drivers and rely on userspace > daemons per platform.... but I think we all agree that is not where > we want this to go. So we'll need to find a compromise. Even then, > we'd need to avoid competition for common method IDs across multiple > userspace applications. I think this is step backward. Current wmi drivers in kernel which implements class devices should stay in kernel -- independently of fact if they are provided by WMI API, ACPI API or direct HW access. > > So for Dell we need for sure some Dell specific interface which > > covers all needed functionality. I'm not sure what everything Dell > > software needs, so what about specifying current usage of Dell > > SMBIOS/WMI functions from existing userspace applications and also > > planned usage in future? Then from this information we can design > > kernel and userspace API which can fit for Dell usage. > > This was my initial response as well. The biggest problem with it is > it places Linux imposed restrictions on the WMI mechanism, which > will ultimately stifle innovation and/or leave Linux as a second > class citizen for systems which rely on WMI for userspace firmware > management. Maybe... I agree that having WMI API for userspace application could be useful, but it should not be at cost of loosing current kernel drivers or kernel functionality provided by current kernel wmi drivers. The question is, who is interested in full WMI access from userspace? And who already requested it in past? I'm just asking if we are not going to work on something in which nobody is interested... Yes, we know from Mario that Dell is interested in WMI access from userspace. But is there other vendor? At least I do not know, so this is reason why I suggested to rather create API specially for Dell which will fully fit for both userspace Dell applications and also kernel dell wmi drivers to minimize conflicts. I'm sure that specific API/ABI designed for concrete usage (here in Dell) would be easier and also better in resolving conflicts and fighting between kernel & userspace as some fully generic API/ABI which needs to be designed for everything and everybody. What worry me is that there will be kernel wmi drivers which due to conflicts in locking/usage would not be able to allow userspace to access WMI. Or if their implemented filter would not fullfit for vendor userspace application (for some reasons), and vendor userspace application starts blocking kernel wmi modules. This would mean that user would be in position where must decide if he wants: stable kernel driver for controlling rfkill/led and receive hotkey presses OR userspace application which can control charging, setting special BIOS settings/etc/... And if laptop vendors do not want to coordinate work with kernel upstream, this situation can really happen. > > About other vendor WMI's functions... I'm not sure, but there is > > again possibility that rfkill, leds or hotkeys would exists on > > same WMI GUID as other maintenance functions (which userspace > > wants), so export would be again blocked by kernel module for > > rfkill/leds/hotkeys. > > > > Therefore I'm not really sure if some /dev/wmi* API would be > > usefull, and not always blocked by kernel module which implements > > rfkill support. > > I'd like to also point out that the Linux kernel has a minimal and > targeted set of WMI drivers generally aimed at making laptops work > as expected through the only mechanism we had access to. Yes, that is truth for obvious reason. > To my > knowledge, we never sat down to discuss how WMI should be > implemented in the Linux ecosystem. That leaves us in the situation > we are in today, in which Linux essentially took the most expedient > route to making laptops work - which happened to be WMI, but we > didn't consider the broader implications of that mechanism or how > what we implemented would interact with full set of functionality > provided by WMI. I did not know about any discussion too. > So our challenge now is to look at WMI as a whole. How should it be > implemented to achieve feature parity. And then consider how the > existing drivers fit into that. Please see my proposal in response > to Rafael's latest reply. I believe it outlines a reasonable > compromise. Ok, I will write there other notes. -- Pali Rohár pali.rohar@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | <Mario.Limonciello@dell.com> |
|---|---|
| Date | 2017-04-13 18:00 +0200 |
| Message-ID | <tvPk5-514-5@gated-at.bofh.it> |
| In reply to | #1623123 |
> -----Original Message----- > From: Andy Lutomirski [mailto:luto@kernel.org] > Sent: Thursday, April 13, 2017 10:33 AM > To: Michał Kępień <kernel@kempniu.pl> > Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki <rjw@rjwysocki.net>; > Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; Corentin > Chary <corentin.chary@gmail.com>; Limonciello, Mario > <Mario_Limonciello@Dell.com>; Andy Lutomirski <luto@kernel.org>; Andy > Shevchenko <andriy.shevchenko@linux.intel.com>; LKML <linux- > kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org; linux- > pm@vger.kernel.org > Subject: Re: RFC: WMI Enhancements > > On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl> wrote: > >> Hi All, > >> > >> 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. > >> > >> 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). > >> > >> Are there any objections to this? > > > > Back in January 2016, I sent Andy a few minor comments about this > > series. A year later, I offered to iron out the remaining issues and > > resubmit the series in Andy's name when I find the time. Sadly, > > things have changed a bit for me since that time and it is unlikely > > that I will be able to deliver, for which I am sorry. > > > > However, browsing Andy's branch I see that most issues have been > > resolved, though I think some of my remarks [1] have either been > > missed or silently refuted :) > > > > Anyway, I also like this approach and I think this series is a > > valuable cleanup. > > Me too :) > > >> 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. > >> > >> There are two principal concerns I'd appreciate your thoughts on: > >> > >> 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. > > I agree. I don't want too see gnome-whatever-widget talking directly to WMI and > confusing the kernel driver for the same thing. So there are plenty of other things that can be done by WMI that don't really make sense to live in the kernel, particularly on what Dell exposes via WMI. If the desire of this group ends up being to not expose WMI by default, I'd like to at least propose it be exposed for the GUID's Dell is using. Perhaps as part of changing dell-smbios to use WMI, also extend it's functionality to userspace. > > >> Secondarily, Andy L created a simple driver to expose the MOF buffer > >> [2] to userspace which could be consumed by a userspace tool to > >> create sources for an interface to the exposed WMI methods. > > > > +1 for the idea, it makes figuring out what the firmware actually > > exposes through WMI a bit easier. After skimming through the driver's > > code, I would only recommend to review the included headers > > (linux/input/sparse-keymap.h, linux/dmi.h and acpi/video.h all seem > > redundant to me). > > > > What we still need, though, is an open source version of wmiofck.exe. > > I am unaware of anything like that existing and installing the Windows > > Driver Kit just to run one command which spits out a single *.h file > > is not something I would describe as convenient (been there). > > I haven't tried to see whether they do what's needed, but there's OpenWBEM and > OpenPegasus. > > Anyway, if such a tool exists, it would be handy to expose the binary MOF data to > userspace so the tool could be used to help get WMI working on new platforms.
[toc] | [prev] | [next] | [standalone]
| From | Darren Hart <dvhart@infradead.org> |
|---|---|
| Date | 2017-04-13 19:10 +0200 |
| Message-ID | <tvQpQ-62k-1@gated-at.bofh.it> |
| In reply to | #1623144 |
On Thu, Apr 13, 2017 at 03:55:01PM +0000, Mario.Limonciello@dell.com wrote: > > > > -----Original Message----- > > From: Andy Lutomirski [mailto:luto@kernel.org] > > Sent: Thursday, April 13, 2017 10:33 AM > > To: Michał Kępień <kernel@kempniu.pl> > > Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki <rjw@rjwysocki.net>; > > Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; Corentin > > Chary <corentin.chary@gmail.com>; Limonciello, Mario > > <Mario_Limonciello@Dell.com>; Andy Lutomirski <luto@kernel.org>; Andy > > Shevchenko <andriy.shevchenko@linux.intel.com>; LKML <linux- > > kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org; linux- > > pm@vger.kernel.org > > Subject: Re: RFC: WMI Enhancements > > > > On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl> wrote: > > >> Hi All, > > >> > > >> 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. > > >> > > >> 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). > > >> > > >> Are there any objections to this? > > > > > > Back in January 2016, I sent Andy a few minor comments about this > > > series. A year later, I offered to iron out the remaining issues and > > > resubmit the series in Andy's name when I find the time. Sadly, > > > things have changed a bit for me since that time and it is unlikely > > > that I will be able to deliver, for which I am sorry. > > > > > > However, browsing Andy's branch I see that most issues have been > > > resolved, though I think some of my remarks [1] have either been > > > missed or silently refuted :) > > > > > > Anyway, I also like this approach and I think this series is a > > > valuable cleanup. > > > > Me too :) > > > > >> 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. > > >> > > >> There are two principal concerns I'd appreciate your thoughts on: > > >> > > >> 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. > > > > I agree. I don't want too see gnome-whatever-widget talking directly to WMI and > > confusing the kernel driver for the same thing. > > So there are plenty of other things that can be done by WMI that don't > really make sense to live in the kernel, particularly on what Dell exposes via > WMI. > > If the desire of this group ends up being to not expose WMI by default, > I'd like to at least propose it be exposed for the GUID's Dell is using. > What I'm thinking is an explicit list of GUIDs within the drivers which are to be exposed to user space. The rationale being: * GUIDs which are managed by kernel drivers (LEDs, hotkeys, etc.) should not be exposed to userspace. * Management GUIDs should not change frequently * Management GUIDs are a trivial add, equivalent to adding a DEVICE ID to an existing driver. This means minimal review time to get upstream, and the ability to include in stable backports as needed. I haven't confirmed this with Greg KH, but I think I can make the case, especially after Andy L's WMI-as-a-bus patches. > Perhaps as part of changing dell-smbios to use WMI, also extend it's > functionality to userspace. That would be consistent with the above in my opinion. -- Darren Hart VMware Open Source Technology Center
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@kernel.org> |
|---|---|
| Date | 2017-04-13 19:40 +0200 |
| Message-ID | <tvQSS-6ep-43@gated-at.bofh.it> |
| In reply to | #1623193 |
On Thu, Apr 13, 2017 at 10:02 AM, Darren Hart <dvhart@infradead.org> wrote: > On Thu, Apr 13, 2017 at 03:55:01PM +0000, Mario.Limonciello@dell.com wrote: >> >> >> > -----Original Message----- >> > From: Andy Lutomirski [mailto:luto@kernel.org] >> > Sent: Thursday, April 13, 2017 10:33 AM >> > To: Michał Kępień <kernel@kempniu.pl> >> > Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki <rjw@rjwysocki.net>; >> > Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; Corentin >> > Chary <corentin.chary@gmail.com>; Limonciello, Mario >> > <Mario_Limonciello@Dell.com>; Andy Lutomirski <luto@kernel.org>; Andy >> > Shevchenko <andriy.shevchenko@linux.intel.com>; LKML <linux- >> > kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org; linux- >> > pm@vger.kernel.org >> > Subject: Re: RFC: WMI Enhancements >> > >> > On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl> wrote: >> > >> Hi All, >> > >> >> > >> 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. >> > >> >> > >> 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). >> > >> >> > >> Are there any objections to this? >> > > >> > > Back in January 2016, I sent Andy a few minor comments about this >> > > series. A year later, I offered to iron out the remaining issues and >> > > resubmit the series in Andy's name when I find the time. Sadly, >> > > things have changed a bit for me since that time and it is unlikely >> > > that I will be able to deliver, for which I am sorry. >> > > >> > > However, browsing Andy's branch I see that most issues have been >> > > resolved, though I think some of my remarks [1] have either been >> > > missed or silently refuted :) >> > > >> > > Anyway, I also like this approach and I think this series is a >> > > valuable cleanup. >> > >> > Me too :) >> > >> > >> 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. >> > >> >> > >> There are two principal concerns I'd appreciate your thoughts on: >> > >> >> > >> 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. >> > >> > I agree. I don't want too see gnome-whatever-widget talking directly to WMI and >> > confusing the kernel driver for the same thing. >> >> So there are plenty of other things that can be done by WMI that don't >> really make sense to live in the kernel, particularly on what Dell exposes via >> WMI. >> >> If the desire of this group ends up being to not expose WMI by default, >> I'd like to at least propose it be exposed for the GUID's Dell is using. >> > > What I'm thinking is an explicit list of GUIDs within the drivers which are to > be exposed to user space. The rationale being: > > * GUIDs which are managed by kernel drivers (LEDs, hotkeys, etc.) should not be > exposed to userspace. > > * Management GUIDs should not change frequently > > * Management GUIDs are a trivial add, equivalent to adding a DEVICE ID to an > existing driver. This means minimal review time to get upstream, and the > ability to include in stable backports as needed. I haven't confirmed > this with Greg KH, but I think I can make the case, especially after > Andy L's WMI-as-a-bus patches. Would this be a class driver that would expose a chardev for each bound GUID? I agree that this makes a lot more sense than trying to shoehorn it into sysfs. Especially since we'd want closing the chardev to disable any "expensive" collections that have been enabled by ioctl on that chardev. Exposing Dell's smbios entry point through this type of device seems reasonable to me. If we go this route, then I think that exposing the MOF through sysfs would make sense -- after all, someone might actually want to parse the thing for production purposes. On a sort-of-on-topic note, there's one platform feature that we complete fail to handle in the kernel that might be nice to add before it gets kludged into lots of userspace code: battery charge controls. Thinkpads expose charge thresholds using abominable interfaces, but I think they've all been reverse-engineered. Dell probably has them, and I bet that Mario would consider telling us how to use them if we asked nicely. It might be nice to expose these generically through sysfs somewhere. I'm guilty myself: https://github.com/amluto/tp_charge
[toc] | [prev] | [next] | [standalone]
| From | <Mario.Limonciello@dell.com> |
|---|---|
| Date | 2017-04-13 19:50 +0200 |
| Message-ID | <tvR2y-6iE-23@gated-at.bofh.it> |
| In reply to | #1623219 |
> -----Original Message----- > From: Andy Lutomirski [mailto:luto@kernel.org] > Sent: Thursday, April 13, 2017 12:33 PM > To: Darren Hart <dvhart@infradead.org> > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; Andrew Lutomirski > <luto@kernel.org>; Michał Kępień <kernel@kempniu.pl>; Rafael J. Wysocki > <rjw@rjwysocki.net>; Len Brown <len.brown@intel.com>; Pali Rohár > <pali.rohar@gmail.com>; Corentin Chary <corentin.chary@gmail.com>; Andy > Shevchenko <andriy.shevchenko@linux.intel.com>; linux-kernel@vger.kernel.org; > platform-driver-x86@vger.kernel.org; linux-pm@vger.kernel.org > Subject: Re: RFC: WMI Enhancements > > On Thu, Apr 13, 2017 at 10:02 AM, Darren Hart <dvhart@infradead.org> wrote: > > On Thu, Apr 13, 2017 at 03:55:01PM +0000, Mario.Limonciello@dell.com wrote: > >> > >> > >> > -----Original Message----- > >> > From: Andy Lutomirski [mailto:luto@kernel.org] > >> > Sent: Thursday, April 13, 2017 10:33 AM > >> > To: Michał Kępień <kernel@kempniu.pl> > >> > Cc: Darren Hart <dvhart@infradead.org>; Rafael Wysocki > <rjw@rjwysocki.net>; > >> > Len Brown <len.brown@intel.com>; Pali Rohár <pali.rohar@gmail.com>; > Corentin > >> > Chary <corentin.chary@gmail.com>; Limonciello, Mario > >> > <Mario_Limonciello@Dell.com>; Andy Lutomirski <luto@kernel.org>; Andy > >> > Shevchenko <andriy.shevchenko@linux.intel.com>; LKML <linux- > >> > kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org; linux- > >> > pm@vger.kernel.org > >> > Subject: Re: RFC: WMI Enhancements > >> > > >> > On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl> > wrote: > >> > >> Hi All, > >> > >> > >> > >> 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. > >> > >> > >> > >> 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). > >> > >> > >> > >> Are there any objections to this? > >> > > > >> > > Back in January 2016, I sent Andy a few minor comments about this > >> > > series. A year later, I offered to iron out the remaining issues and > >> > > resubmit the series in Andy's name when I find the time. Sadly, > >> > > things have changed a bit for me since that time and it is unlikely > >> > > that I will be able to deliver, for which I am sorry. > >> > > > >> > > However, browsing Andy's branch I see that most issues have been > >> > > resolved, though I think some of my remarks [1] have either been > >> > > missed or silently refuted :) > >> > > > >> > > Anyway, I also like this approach and I think this series is a > >> > > valuable cleanup. > >> > > >> > Me too :) > >> > > >> > >> 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. > >> > >> > >> > >> There are two principal concerns I'd appreciate your thoughts on: > >> > >> > >> > >> 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. > >> > > >> > I agree. I don't want too see gnome-whatever-widget talking directly to WMI > and > >> > confusing the kernel driver for the same thing. > >> > >> So there are plenty of other things that can be done by WMI that don't > >> really make sense to live in the kernel, particularly on what Dell exposes via > >> WMI. > >> > >> If the desire of this group ends up being to not expose WMI by default, > >> I'd like to at least propose it be exposed for the GUID's Dell is using. > >> > > > > What I'm thinking is an explicit list of GUIDs within the drivers which are to > > be exposed to user space. The rationale being: > > > > * GUIDs which are managed by kernel drivers (LEDs, hotkeys, etc.) should not be > > exposed to userspace. > > > > * Management GUIDs should not change frequently > > > > * Management GUIDs are a trivial add, equivalent to adding a DEVICE ID to an > > existing driver. This means minimal review time to get upstream, and the > > ability to include in stable backports as needed. I haven't confirmed > > this with Greg KH, but I think I can make the case, especially after > > Andy L's WMI-as-a-bus patches. > > Would this be a class driver that would expose a chardev for each > bound GUID? I agree that this makes a lot more sense than trying to > shoehorn it into sysfs. Especially since we'd want closing the > chardev to disable any "expensive" collections that have been enabled > by ioctl on that chardev. Exposing Dell's smbios entry point through > this type of device seems reasonable to me. > > If we go this route, then I think that exposing the MOF through sysfs > would make sense -- after all, someone might actually want to parse > the thing for production purposes. I agree. > > On a sort-of-on-topic note, there's one platform feature that we > complete fail to handle in the kernel that might be nice to add before > it gets kludged into lots of userspace code: battery charge controls. > Thinkpads expose charge thresholds using abominable interfaces, but I > think they've all been reverse-engineered. Dell probably has them, > and I bet that Mario would consider telling us how to use them if we > asked nicely. It might be nice to expose these generically through > sysfs somewhere. > Sure. They're part of the token interface. https://github.com/dell/libsmbios/blob/master/doc/token_list.csv#L834
[toc] | [prev] | [next] | [standalone]
| From | Darren Hart <dvhart@infradead.org> |
|---|---|
| Date | 2017-04-13 18:10 +0200 |
| Message-ID | <tvPtL-5kd-9@gated-at.bofh.it> |
| In reply to | #1623123 |
On Thu, Apr 13, 2017 at 08:32:48AM -0700, Andy Lutomirski wrote: > On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl> wrote: > >> Hi All, > >> > >> 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. > >> > >> 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). > >> > >> Are there any objections to this? > > > > Back in January 2016, I sent Andy a few minor comments about this > > series. A year later, I offered to iron out the remaining issues and > > resubmit the series in Andy's name when I find the time. Sadly, things > > have changed a bit for me since that time and it is unlikely that I will > > be able to deliver, for which I am sorry. > > > > However, browsing Andy's branch I see that most issues have been > > resolved, though I think some of my remarks [1] have either been missed > > or silently refuted :) > > > > Anyway, I also like this approach and I think this series is a valuable > > cleanup. > > Me too :) > > >> 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. > >> > >> There are two principal concerns I'd appreciate your thoughts on: > >> > >> 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. > > I agree. I don't want too see gnome-whatever-widget talking directly > to WMI and confusing the kernel driver for the same thing. > > >> Secondarily, Andy L created a simple driver to expose the MOF buffer [2] to > >> userspace which could be consumed by a userspace tool to create sources for an > >> interface to the exposed WMI methods. > > > > +1 for the idea, it makes figuring out what the firmware actually > > exposes through WMI a bit easier. After skimming through the driver's > > code, I would only recommend to review the included headers > > (linux/input/sparse-keymap.h, linux/dmi.h and acpi/video.h all seem > > redundant to me). > > > > What we still need, though, is an open source version of wmiofck.exe. I > > am unaware of anything like that existing and installing the Windows > > Driver Kit just to run one command which spits out a single *.h file is > > not something I would describe as convenient (been there). > > I haven't tried to see whether they do what's needed, but there's > OpenWBEM and OpenPegasus. > > Anyway, if such a tool exists, it would be handy to expose the binary > MOF data to userspace so the tool could be used to help get WMI > working on new platforms. > Looking into what exists and what it might take to write a new tool is on my todo list as a second priority to sorting out the WMI userspace mechanism issue. Thanks for the pointers. -- Darren Hart VMware Open Source Technology Center
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2017-04-15 01:00 +0200 |
| Message-ID | <twim6-71X-9@gated-at.bofh.it> |
| In reply to | #1622607 |
On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote: > Hi All, > > 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. > > 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). > > Are there any objections to this? > > 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. > > There are two principal concerns I'd appreciate your thoughts on: > > 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. A couple of loose thoughts here. 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). Then, depending on how that thing is implemented, opt-in etc should be possible too. Thanks, Rafael
[toc] | [prev] | [next] | [standalone]
| From | Darren Hart <dvhart@infradead.org> |
|---|---|
| Date | 2017-04-15 01:10 +0200 |
| Message-ID | <twivL-7km-7@gated-at.bofh.it> |
| In reply to | #1623945 |
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, > > > > 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. > > > > 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). > > > > Are there any objections to this? > > > > 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. > > > > There are two principal concerns I'd appreciate your thoughts on: > > > > 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. > > A couple of loose thoughts here. > > 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). > > Then, depending on how that thing is implemented, opt-in etc should be possible > too. > I think we agree this would be an ideal approach. 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. :-( 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. Next step is to look at just how complex it would be to audit the method calls the kernel currently uses. -- Darren Hart VMware Open Source Technology Center
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2017-04-18 00:10 +0200 |
| Message-ID | <txn0l-6jY-9@gated-at.bofh.it> |
| In reply to | #1623951 |
On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart <dvhart@infradead.org> 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, >> > >> > 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. >> > >> > 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). >> > >> > Are there any objections to this? >> > >> > 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. >> > >> > There are two principal concerns I'd appreciate your thoughts on: >> > >> > 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. >> >> A couple of loose thoughts here. >> >> 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). >> >> Then, depending on how that thing is implemented, opt-in etc should be possible >> too. >> > > I think we agree this would be an ideal approach. > > 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. > > :-( > > 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. > > Next step is to look at just how complex it would be to audit the method calls > the kernel currently uses. 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. 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. I'd consider a low-level WMI ioctl interface to be a vast improvement.
[toc] | [prev] | [next] | [standalone]
| From | Darren Hart <dvhart@infradead.org> |
|---|---|
| Date | 2017-04-18 01:20 +0200 |
| Message-ID | <txo65-6Xu-1@gated-at.bofh.it> |
| In reply to | #1624884 |
On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote: > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart <dvhart@infradead.org> 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, > >> > > >> > 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. > >> > > >> > 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). > >> > > >> > Are there any objections to this? > >> > > >> > 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. > >> > > >> > There are two principal concerns I'd appreciate your thoughts on: > >> > > >> > 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. > >> > >> A couple of loose thoughts here. > >> > >> 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). > >> > >> Then, depending on how that thing is implemented, opt-in etc should be possible > >> too. > >> > > > > I think we agree this would be an ideal approach. > > > > 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. > > > > :-( > > > > 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. > > > > Next step is to look at just how complex it would be to audit the method calls > > the kernel currently uses. > > 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. > > 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. I'd consider a low-level WMI ioctl > interface to be a vast improvement. > 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. 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. -- Darren Hart VMware Open Source Technology Center
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2017-04-18 15:20 +0200 |
| Message-ID | <txBcZ-6Cr-5@gated-at.bofh.it> |
| In reply to | #1624905 |
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 <dvhart@infradead.org> 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, > > >> > > > >> > 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. > > >> > > > >> > 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). > > >> > > > >> > Are there any objections to this? > > >> > > > >> > 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. > > >> > > > >> > There are two principal concerns I'd appreciate your thoughts on: > > >> > > > >> > 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. > > >> > > >> A couple of loose thoughts here. > > >> > > >> 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). > > >> > > >> Then, depending on how that thing is implemented, opt-in etc should be possible > > >> too. > > >> > > > > > > I think we agree this would be an ideal approach. > > > > > > 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. > > > > > > :-( > > > > > > 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. > > > > > > Next step is to look at just how complex it would be to audit the method calls > > > the kernel currently uses. > > > > 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. 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. 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. > > 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. I'd consider a low-level WMI ioctl > > interface to be a vast improvement. > > > > 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. > > 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. 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. 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). Thanks, Rafael
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | linux.kernel
csiph-web