linux-kernel - Re: WMI and Kernel:User interface

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201706131916.12144@pali>
Date:   Tue, 13 Jun 2017 19:16:11 +0200
From:   Pali Rohár <pali.rohar@...il.com>
To:     Darren Hart <dvhart@...radead.org>
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 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@...il.com

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)