lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 13 Jun 2017 10:40:27 -0700
From:   Darren Hart <dvhart@...radead.org>
To:     Pali Rohár <pali.rohar@...il.com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Mario Limonciello <mario_limonciello@...l.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Andy Lutomirski <luto@...capital.net>,
        LKML <linux-kernel@...r.kernel.org>,
        platform-driver-x86@...r.kernel.org
Subject: Re: WMI and Kernel:User interface

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

Powered by blists - more mailing lists