linux-kernel - RE: RFC: WMI Enhancements

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:   Wed, 19 Apr 2017 17:24:00 +0000
From:   <Mario.Limonciello@...l.com>
To:     <pali.rohar@...il.com>
CC:     <dvhart@...radead.org>, <rjw@...ysocki.net>, <luto@...capital.net>,
        <len.brown@...el.com>, <corentin.chary@...il.com>,
        <luto@...nel.org>, <andriy.shevchenko@...ux.intel.com>,
        <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <linux-pm@...r.kernel.org>
Subject: RE: RFC: WMI Enhancements

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@...il.com]
> Sent: Wednesday, April 19, 2017 11:55 AM
> To: Limonciello, Mario <Mario_Limonciello@...l.com>
> Cc: dvhart@...radead.org; rjw@...ysocki.net; luto@...capital.net;
> len.brown@...el.com; corentin.chary@...il.com; luto@...nel.org;
> andriy.shevchenko@...ux.intel.com; linux-kernel@...r.kernel.org; platform-
> driver-x86@...r.kernel.org; linux-pm@...r.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Wednesday 19 April 2017 18:29:53 Mario.Limonciello@...l.com wrote:
> > > As wrote above, I'm fine with explicit whitelist of WMI GUIDs which
> > > will be exported to userspace after communication with vendor.
> >
> > What about GUID's not yet used by kernel drivers?  Would those
> > default to whitelist default to blacklist?  My preference would be
> > to default to whitelist. This allows new GUID's to be added later
> > without needing to modify kernel for something that kernel won't
> > need to do anything immediately.
> 
> I understood it as there would be explicit whitelist in kernel and new
> GUIDs would be needed to add into whitelist, even those which do not
> have kernel wmi driver.
> 
> Exporting all GUIDs (to userspace) which are not bind to kernel driver
> has one big problem. If kernel introduce new wmi driver for such GUID
> then it block userspace to access it or at least would need to provide
> audit filter and something would be probably filtered. It means that
> some userspace applications which would use that GUIDs stops working
> after upgrading to new kernel. And we can be in situation where *user*
> need to decide: either use 3rd party userspace application from vendor
> which provide some special settings for your laptop, or use kernel
> module which provides standard rfkill/led/input class driver.
> 

If this proposal goes forward it would sound like to me an audit filter
would become a prerequisite for any new WMI kernel driver.  This is not
a problem to me.

This audience recommends the way for users to configure the system but 
of course cannot stop users from doing what they decide to do.  
We're all in agreement that the kernel should keep responsibility for some
of these functionalities.
If a new kernel WMI driver duplicates functionality that happens to find its 
way in userspace and the kernel audits that out yes the userspace 
application may start to  have less functionality, but better support 
would live in the kernel and the user would be better supported by 
the stack (for example could use standard rfkill userspace utilities).