Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1661977 > unrolled thread

Re: WMI and Kernel:User interface

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: WMI and Kernel:User interface Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-06-09 08:50 +0200
    Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-06-10 02:50 +0200
      Re: WMI and Kernel:User interface Pali Rohár <pali.rohar@gmail.com> - 2017-06-10 12:40 +0200
        Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-06-12 19:10 +0200
          Re: WMI and Kernel:User interface Pali Rohár <pali.rohar@gmail.com> - 2017-06-13 00:20 +0200
            Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-06-13 03:30 +0200
              Re: WMI and Kernel:User interface Christoph Hellwig <hch@infradead.org> - 2017-06-13 09:10 +0200
                Re: WMI and Kernel:User interface Pali Rohár <pali.rohar@gmail.com> - 2017-06-13 14:10 +0200
                  Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-06-13 17:50 +0200
                    Re: WMI and Kernel:User interface Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-06-13 18:10 +0200
                      Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-06-13 18:30 +0200
                Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-06-13 17:40 +0200
                  Re: WMI and Kernel:User interface Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-06-13 18:00 +0200
                    Re: WMI and Kernel:User interface Andy Lutomirski <luto@kernel.org> - 2017-06-13 18:00 +0200
                      RE: WMI and Kernel:User interface <Mario.Limonciello@dell.com> - 2017-06-13 18:20 +0200
                        Re: WMI and Kernel:User interface Greg KH <gregkh@linuxfoundation.org> - 2017-06-13 19:00 +0200
                          Re: WMI and Kernel:User interface Pali Rohár <pali.rohar@gmail.com> - 2017-06-13 19:50 +0200
                      Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-06-13 18:50 +0200
                    Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-06-13 18:30 +0200
                      Re: WMI and Kernel:User interface Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-06-13 19:00 +0200
                        Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-06-13 19:10 +0200
                          Re: WMI and Kernel:User interface Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-06-14 06:40 +0200
                  Re: WMI and Kernel:User interface Pali Rohár <pali.rohar@gmail.com> - 2017-06-13 19:20 +0200
                    Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-06-13 19:50 +0200
                      Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-06-13 20:10 +0200
                      Re: WMI and Kernel:User interface Pali Rohár <pali.rohar@gmail.com> - 2017-06-13 20:10 +0200
                      Re: WMI and Kernel:User interface Bernd Petrovitsch <bernd@petrovitsch.priv.at> - 2017-06-14 02:30 +0200
              Re: WMI and Kernel:User interface Pali Rohár <pali.rohar@gmail.com> - 2017-06-13 15:00 +0200
                Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-06-13 18:10 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1665026

On Tue, Jun 13, 2017 at 06:52:47PM +0200, Greg Kroah-Hartman wrote:
> > As a concrete example, Dell has specifically made the request that we
> > work on a solution that doesn't require them to come back to the kernel
> > community each time they add a WMI GUID to their BIOS. They would like
> > to see those GUIDs automatically exposed.
> 
> What do you mean exactly by "exposed"?  What do they do with these?  Why

By exposed I meant: the chardev for the WMI GUID is created

The idea being the kernel maps WMI GUIDs to chardevs and shepherds the
userspace calls through to the ACPI method evaluation and back. But the
kernel wmi driver doesn't, in general, have specific knowledge of the
methods or input and output formats.

The existing drivers being the exception to "specific knowledge", and
the cause of all this filter/proxy discussion. I think we have enough
that we can put together an initial patch series, and then discuss it
there.

> isn't the Dell pre-install team sending patches for this like the
> Windows preinstall team is doing for their hacked-to-hell copy of
> Windows?  :)
> 
> Do you have an example patch of something that was needed to get a Dell
> laptop working for a new device id that didn't work this way?

Per Mario's comment, it sounds like they are and it does work this way.
It takes 8 weeks, and they don't see a reason to go through this for WMI
GUIDs.

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1665399

On Tue, Jun 13, 2017 at 10:07:19AM -0700, Darren Hart wrote:
> On Tue, Jun 13, 2017 at 06:52:47PM +0200, Greg Kroah-Hartman wrote:
> > > As a concrete example, Dell has specifically made the request that we
> > > work on a solution that doesn't require them to come back to the kernel
> > > community each time they add a WMI GUID to their BIOS. They would like
> > > to see those GUIDs automatically exposed.
> > 
> > What do you mean exactly by "exposed"?  What do they do with these?  Why
> 
> By exposed I meant: the chardev for the WMI GUID is created
> 
> The idea being the kernel maps WMI GUIDs to chardevs and shepherds the
> userspace calls through to the ACPI method evaluation and back. But the
> kernel wmi driver doesn't, in general, have specific knowledge of the
> methods or input and output formats.

Hah, and those people who insist on "secure boot" are going to allow
userspace access to ACPI methods like this?  Well, I guess as Windows
does it, it must be ok...

I'll shut up now and just wait for patches :)

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1665037

[Multipart message — attachments visible in raw view] — view raw

On Tuesday 13 June 2017 17:38:57 Darren Hart wrote:
> I'll mention this again I suspect in this thread, but rather than a
> "WMI filter" we can implement a "WMI proxy". If a kernel driver
> needs to own certain WMI calls for LED or Radio management, for
> example, all such calls can be proxied through that driver. It can
> do the necessary work to update its own state, and still perform the
> requested funtion, transparent to the userspace caller. This should
> accommodate the addition of new drivers and features to kernel
> drivers, without precluding the development of userspace management
> or platform daemons.

Such WMI proxy implemented in every WMI driver has one design problem:

There would be two different kernel APIs to configure some firmware 
settings. E.g. if particular WMI method implements turning on/off radio 
devices, then functionality would be exported to userspace via:

1) standard kernel rfkill interface which is device/driver/firmware 
neutral (and any rfkill application can control it)

2) platform/firmware specific WMI method via newly standard /dev/wmi* 
interface -- and only vendor specific application could do that and it 
would work only for this one specific WMI GUID device

I do not like idea to have two kernel <--> userspace interfaces to 
control one thing, plus one interface would be platform dependent.

In my opinion any management application which want to control radio 
switches should use option 1) rfkill interface.

And I do not see reason for exporting same duplicate, but platform 
dependent interface from kernel to userspace.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1665063

On Tue, Jun 13, 2017 at 07:16:11PM +0200, Pali Rohár wrote:
> On Tuesday 13 June 2017 17:38:57 Darren Hart wrote:
> > I'll mention this again I suspect in this thread, but rather than a
> > "WMI filter" we can implement a "WMI proxy". If a kernel driver
> > needs to own certain WMI calls for LED or Radio management, for
> > example, all such calls can be proxied through that driver. It can
> > do the necessary work to update its own state, and still perform the
> > requested funtion, transparent to the userspace caller. This should
> > accommodate the addition of new drivers and features to kernel
> > drivers, without precluding the development of userspace management
> > or platform daemons.
> 
> Such WMI proxy implemented in every WMI driver has one design problem:
> 
> There would be two different kernel APIs to configure some firmware 
> settings. E.g. if particular WMI method implements turning on/off radio 
> devices, then functionality would be exported to userspace via:
> 
> 1) standard kernel rfkill interface which is device/driver/firmware 
> neutral (and any rfkill application can control it)
> 
> 2) platform/firmware specific WMI method via newly standard /dev/wmi* 
> interface -- and only vendor specific application could do that and it 
> would work only for this one specific WMI GUID device

Yes, platform specific control is what WMI is for.

> I do not like idea to have two kernel <--> userspace interfaces to 
> control one thing, plus one interface would be platform dependent.
> 
> In my opinion any management application which want to control radio 
> switches should use option 1) rfkill interface.

Agreed, they should.

> And I do not see reason for exporting same duplicate, but platform 
> dependent interface from kernel to userspace.
> 

So this question boils down to: do we export WMI to userspace or not?

The WMI GUIDs and methods will not be divided across convenient Linux
subsystem boundaries allowing us to pick and choose what we export. If
we export WMI to userspace, we will be providing another means of
access. Sometimes, this may cause conflict, and the answer may just be
"don't do that".

There are plenty of other examples of things you can do to screw up the
state of your system if you have the right permissions for which the
answer is "don't do that". Consider MEM(4), SETPCI(8), ... /dev/sda ...
for example.

So we can either export them and possibly offer some means of proxying
where necessary, or we can not export them.

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1665089

On Tue, Jun 13, 2017 at 08:00:30PM +0200, Pali Rohár wrote:
> 
> I just tried to show that proposed proxy has above problem and looks 
> like anti-pattern for linux kernel. As this should be evaluated when 
> going to accept or reject it.

OK, I think at this point we need to follow Greg's advice and get some
code out there for review. I don't think we're going to make more
progress in pre-code discussions.

Thanks for all the time and effort everyone has put into the discussion.

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1665093

[Multipart message — attachments visible in raw view] — view raw

On Tuesday 13 June 2017 19:40:27 Darren Hart wrote:
> On Tue, Jun 13, 2017 at 07:16:11PM +0200, Pali Rohár wrote:
> > On Tuesday 13 June 2017 17:38:57 Darren Hart wrote:
> > > I'll mention this again I suspect in this thread, but rather than
> > > a "WMI filter" we can implement a "WMI proxy". If a kernel
> > > driver needs to own certain WMI calls for LED or Radio
> > > management, for example, all such calls can be proxied through
> > > that driver. It can do the necessary work to update its own
> > > state, and still perform the requested funtion, transparent to
> > > the userspace caller. This should accommodate the addition of
> > > new drivers and features to kernel drivers, without precluding
> > > the development of userspace management or platform daemons.
> > 
> > Such WMI proxy implemented in every WMI driver has one design
> > problem:
> > 
> > There would be two different kernel APIs to configure some firmware
> > settings. E.g. if particular WMI method implements turning on/off
> > radio devices, then functionality would be exported to userspace
> > via:
> > 
> > 1) standard kernel rfkill interface which is device/driver/firmware
> > neutral (and any rfkill application can control it)
> > 
> > 2) platform/firmware specific WMI method via newly standard
> > /dev/wmi* interface -- and only vendor specific application could
> > do that and it would work only for this one specific WMI GUID
> > device
> 
> Yes, platform specific control is what WMI is for.
> 
> > I do not like idea to have two kernel <--> userspace interfaces to
> > control one thing, plus one interface would be platform dependent.
> > 
> > In my opinion any management application which want to control
> > radio switches should use option 1) rfkill interface.
> 
> Agreed, they should.
> 
> > And I do not see reason for exporting same duplicate, but platform
> > dependent interface from kernel to userspace.
> 
> So this question boils down to: do we export WMI to userspace or not?
> 
> The WMI GUIDs and methods will not be divided across convenient Linux
> subsystem boundaries allowing us to pick and choose what we export.
> If we export WMI to userspace, we will be providing another means of
> access. Sometimes, this may cause conflict, and the answer may just
> be "don't do that".
> 
> There are plenty of other examples of things you can do to screw up
> the state of your system if you have the right permissions for which
> the answer is "don't do that". Consider MEM(4), SETPCI(8), ...
> /dev/sda ... for example.

I know. There is also iopl(3). But this nor above examples are not tools 
for such activity. (Yes, there is e.g. lspci which can be switched to 
use iopl(3), but also it is not for normal usage.)

But on the other hand proposed WMI API designed are for such usage and 
developers are directly motivated to use it.

> So we can either export them and possibly offer some means of
> proxying where necessary, or we can not export them.

I just tried to show that proposed proxy has above problem and looks 
like anti-pattern for linux kernel. As this should be evaluated when 
going to accept or reject it.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1665317

On Tue, 2017-06-13 at 10:40 -0700, Darren Hart wrote:
[...]
> There are plenty of other examples of things you can do to screw up the
> state of your system if you have the right permissions for which the
> answer is "don't do that". Consider MEM(4), SETPCI(8), ... /dev/sda ...
> for example.

So what is the problem?!
And that pretty much answers it for the Unix world IMHO (FWIW) ...

And there is *a lot* more of that if you are root.
WTF - that actually is the job definition of root/administrator/
supervisor/... to be able to fix (almost) everything and that implies
practically the rights to be able to do everything.

MfG,
	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at

[toc] | [prev] | [next] | [standalone]

#1664825

On Monday 12 June 2017 18:24:35 Darren Hart wrote:
> > One thing is design of some system, another thing is real usage. We know 
> > that WMI is used for reporting events when some keys are pressed (e.g. 
> > Fn keys) or used for enabling/disabling of radio devices or controlling 
> > keyboard/LID backlight. All those parts are in Linux world handled by 
> > kernel (not userspace) and therefore WMI needs to be handled in Linux 
> > kernel.
> 
> These are examples of the subsystems I was referring to below. We can already
> assign LED triggers for some things. However, when the WMI method is
> specifically used as the mechanism for toggling the LED... yes, you make a good
> point.

I wanted to show that there are WMI methods doing functionality which is
handled by Linux kernel. And therefore it must be implemented in kernel.

If function of that WMI method is in Windows world handled by userspace,
it does not mean that in Linux we need to create way how to handle such
thing in userspace -- argument "WMI was designed to access firmware
functions from userspace" is not relevant in such Linux scenario.

> Ideally, we would provide a generic way for users/OEMs/vendors to successfully
> support and maintain their own platforms, ideally with as little kernel changes
> as possible. If we can get closer to that than we are today with this WMI work,
> I think that is worth the effort.

If OEM vendors are uncooperative, why should be ever create some
interface to call WMI methods? That looks like "we are going to cook
something, we do not know who will eat it nor how it should taste".

I know only Mario from Dell and their need to call SMBIOS functions
exported by one WMI GUID. Why no other OEM vendor entered into this
discussion?

> > > Arguably, implementing platform support with WMI through Linux kernel
> > > modules slows platform support as it is hindered by the barrier to
> > > entry and the kernel's release process - while a generic WMI
> > 
> > But we can say mainline kernel has better code quality as some random 
> > closed source 3rd vendor application.
> 
> While I think we work pretty hard at writing quality code, the code analysis
> studies I'm aware of (such as those being developed by the SIL2Linux MP project
> for the use of the Linux kernel in safety critical systems) support this
> statement for the most core code of the Linux kernel, the stuff that
> everything needs. This doesn't hold true of all parts of the kernel, however,
> with lower use drivers showing some of the highest bug rates of all subsystems
> (along with certain filesystems).

Even if there are bugs, GPLv2 license of kernel allows anybody to fix
them.

EULA of 3rd vendor closed userspace application not only disallow it,
but also make it impossible (due to missing public sources).

> > Userspace applications, and if we are talking about WMI, would be 
> > probably 3rd party vendor closed-source binaries compiled for one or two 
> > specific Linux distributions. For me it is just "random userspace 
> > application" which I do not thing that would be preinstalled or part of 
> > Linux distributions, like it is for coreutils or X Server today.
> 
> That is certainly not the outcome we'd be aiming for.

Keep in mind that switching WMI to userspace for new features would mean
need to install that software to make "new feature" work correctly. And
user would be needed to install it from vendor after installation of
system or distributions starts to packs ton of vendor closed source
software... No I think having need for such blobs is really way to the
hell for Linux world.

> > > > Question about API:
> > > > 
> > > > Are we going to export low-level ACPI methods? Or are we going to
> > > > implement BMOF parser in kernel and export high-level
> > > > class/function API to userspace with validation of input
> > > > parameters in kernel (to prevent passing garbage from userspace to
> > > > ACPI-WMI) like it is on Windows?
> > > 
> > > What we have discussed to date is exposing each WMI device as a
> > > character device. Userspace would select the method and pass a
> > > buffer formatted per the information provided by a userspace BMOF
> > > parser. This is consistent with the design goals of WMI, per the
> > > documentation. Specifically, that the mapping driver does not have
> > > any specific knowledge about the WMI GUIDs or methods.
> > 
> > Ok.
> > 
> 
> As to the "OK fine, but what are we actually going to do..." bit...
> 
> In order to support broad enabling, we should avoid Whitelists which would
> require we add new GUIDs to the kernel as fast as vendors can add them.

Based on fact that whitelisting is trivial to manage and easy to
implement, I do not think that avoiding whitelisting it a good idea.

> If we require filtering, it should be along the lines of an ACCEPT/DENY filter,
> which only denies specific accesses. Drivers which match a WMI GUID can register
> a filter callback, returning true or false (accept or deny). This would allow
> for the creation of management tools in cooperation with the existing
> drivers, without precluding the development of userspace platform-daemons which
> could handle all aspects of the WMI interface (if they conflict with an existing
> driver, they would need to run without that driver, which would avoid loading
> the WMI filter).

Yes, agree. And if filtering for current WMI kernel driver is hard (or
impossible), then such filter implemented in WMI driver would DENY any
call from userspace.

> Possible concerns, as before, we run the risk of a new driver being written, or
> a new feature being added to an existing driver, that needs to add a filter
> which would then deny userspace accesses previously allowed. It becomes a first
> to support the platform race.

With whitelisting the risk is lower. And we can mark userspace interface
as experimental for now and make part of interface that kernel can block
arbitrary userspace request.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1664983

On Tue, Jun 13, 2017 at 02:51:07PM +0200, Pali Rohár wrote:
> If function of that WMI method is in Windows world handled by userspace,
> it does not mean that in Linux we need to create way how to handle such
> thing in userspace -- argument "WMI was designed to access firmware
> functions from userspace" is not relevant in such Linux scenario.

We're looping now :-) We disagree on this point. That's OK, I think I
see a solution that will address both sides coming.

> > Ideally, we would provide a generic way for users/OEMs/vendors to successfully
> > support and maintain their own platforms, ideally with as little kernel changes
> > as possible. If we can get closer to that than we are today with this WMI work,
> > I think that is worth the effort.
> 
> If OEM vendors are uncooperative, why should be ever create some
> interface to call WMI methods? That looks like "we are going to cook

This line of thinking just leads to a stalemate in my opinion.

> something, we do not know who will eat it nor how it should taste".
> 
> I know only Mario from Dell and their need to call SMBIOS functions
> exported by one WMI GUID. Why no other OEM vendor entered into this
> discussion?

I'm really happy to see the level of interaction from Dell we are
seeing.  They're doing the right thing, engaging the kernel development
community in an open environment, at the right conferences, etc. That's
enough for me to engage and work on solving a problem with them.

> 
> Even if there are bugs, GPLv2 license of kernel allows anybody to fix
> them.
> 
> EULA of 3rd vendor closed userspace application not only disallow it,
> but also make it impossible (due to missing public sources).

You're conflating issues by assuming that any user of the WMI userspace
interface will be proprietary. Sure, some will, just as some kernel
modules are binary, but that argument can be applied to any interface.

> 
> > > Userspace applications, and if we are talking about WMI, would be 
> > > probably 3rd party vendor closed-source binaries compiled for one or two 
> > > specific Linux distributions. For me it is just "random userspace 
> > > application" which I do not thing that would be preinstalled or part of 
> > > Linux distributions, like it is for coreutils or X Server today.
> > 
> > That is certainly not the outcome we'd be aiming for.
> 
> Keep in mind that switching WMI to userspace for new features would mean
> need to install that software to make "new feature" work correctly. And
> user would be needed to install it from vendor after installation of
> system or distributions starts to packs ton of vendor closed source
> software... No I think having need for such blobs is really way to the
> hell for Linux world.

Again, you're assuming that if it isn't in the kernel it will be poor
quality, binary only, and distro dependent. Even if a vendor did attempt
something like that, there is nothing preventing interested users from
creating an open source solution that would be distro agnostic. And,
with the wmi method proxy concept, we could still just do it in the
kernel.

> > 
> > As to the "OK fine, but what are we actually going to do..." bit...
> > 
> > In order to support broad enabling, we should avoid Whitelists which would
> > require we add new GUIDs to the kernel as fast as vendors can add them.
> 
> Based on fact that whitelisting is trivial to manage and easy to
> implement, I do not think that avoiding whitelisting it a good idea.

As above, it isn't just the technical complexity, which is obviously
trivial, it's the timeline. It's possible dynamic IDs may address this.
I believe the proxy method also addresses the underlying concerns.

I don't see a compelling enough reason to manage GUID whitelists.

> 
> > If we require filtering, it should be along the lines of an ACCEPT/DENY filter,
> > which only denies specific accesses. Drivers which match a WMI GUID can register
> > a filter callback, returning true or false (accept or deny). This would allow
> > for the creation of management tools in cooperation with the existing
> > drivers, without precluding the development of userspace platform-daemons which
> > could handle all aspects of the WMI interface (if they conflict with an existing
> > driver, they would need to run without that driver, which would avoid loading
> > the WMI filter).
> 
> Yes, agree. And if filtering for current WMI kernel driver is hard (or
> impossible), then such filter implemented in WMI driver would DENY any
> call from userspace.
> 
> > Possible concerns, as before, we run the risk of a new driver being written, or
> > a new feature being added to an existing driver, that needs to add a filter
> > which would then deny userspace accesses previously allowed. It becomes a first
> > to support the platform race.
> 
> With whitelisting the risk is lower. And we can mark userspace interface
> as experimental for now and make part of interface that kernel can block
> arbitrary userspace request.

And finally, to the filter vs. proxy idea - phew! :-)

It occurred to me this morning while thinking about this problem and
considering Greg KH's previous comment about it's OK to change the
interface, so long as it doesn't break anything. If instead of DENYing a
method call, we allow a driver to PROXY a method call, we make the
change transparent to userspace, and still retain the ability for kernel
drivers to claim ownership of certain WMI method signatures, and ensure
consistent internal state.

When a WMI driver binds to a GUID, it can also register a
wmi_method_proxy for that GUID. When a method call is received, the
proxy is called with the method ID, input and output buffers. The proxy
can choose to handle the call itself and populate the output buffer, or
not, and let the WMI system execute it.

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web