Re: RFC: WMI Enhancements

[Andy Lutomirski]

On Thu, Apr 13, 2017 at 8:55 AM,  <Mario.Limonciello@xxxxxxxx> wrote:
>
>
>> -----Original Message-----
>> From: Andy Lutomirski [mailto:luto@xxxxxxxxxx]
>> Sent: Thursday, April 13, 2017 10:33 AM
>> To: MichaÅ KÄpieÅ <kernel@xxxxxxxxxx>
>> Cc: Darren Hart <dvhart@xxxxxxxxxxxxx>; Rafael Wysocki <rjw@xxxxxxxxxxxxx>;
>> Len Brown <len.brown@xxxxxxxxx>; Pali RohÃr <pali.rohar@xxxxxxxxx>; Corentin
>> Chary <corentin.chary@xxxxxxxxx>; Limonciello, Mario
>> <Mario_Limonciello@xxxxxxxx>; Andy Lutomirski <luto@xxxxxxxxxx>; Andy
>> Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>; LKML <linux-
>> kernel@xxxxxxxxxxxxxxx>; platform-driver-x86@xxxxxxxxxxxxxxx; linux-
>> pm@xxxxxxxxxxxxxxx
>> Subject: Re: RFC: WMI Enhancements
>>
>> On Thu, Apr 13, 2017 at 12:32 AM, MichaÅ KÄpieÅ <kernel@xxxxxxxxxx> 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.