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]

Message-ID: <20170418075401.GC18887@pali>
Date:   Tue, 18 Apr 2017 09:54:01 +0200
From:   Pali Rohár <pali.rohar@...il.com>
To:     Mario.Limonciello@...l.com
Cc:     dvhart@...radead.org, luto@...nel.org, kernel@...pniu.pl,
        rjw@...ysocki.net, len.brown@...el.com, corentin.chary@...il.com,
        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 Thursday 13 April 2017 17:39:56 Mario.Limonciello@...l.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@...il.com