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:   Thu, 13 Apr 2017 20:38:28 +0000
From:   <Mario.Limonciello@...l.com>
To:     <dvhart@...radead.org>, <pali.rohar@...il.com>
CC:     <rjw@...ysocki.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

Earlier question from Andy.  I had some discussion with the right people about this.

> Is it just the "call SMBIOS" GUID or are there other things?

Today - it's just the SMBIOS calling GUID.  There are plans (not yet concrete) for
splitting up data access and organization of that data access classes across multiple 
 other GUID/method pairs in the future.

Ideally this could be done without needing kernel patches every time a new GUID
would (essentially) need to be whitelisted.

> I am a strong supporter of the following philosophy with respect to supporting
> innovation:
> "Enable them to enable themselves and get out of their way"
> 
> I've followed this approach over the years to encourage upstream first software
> development, open-first policy toward specifications and documentation, proper
> license selection, and development of new mechanisms in existing standards, like
> ACPI _DSD. All of these serve to support innovation by removing bottlenecks and
> enabling developers to be independent.
> 
> What I don't want to see is the Linux kernel becoming a bottleneck to feature
> parity with Windows (or to becoming the lead vehicle for new features). When a
> vendor has a feature they want to expose which they determine to be a value
> proposition for their product, I don't want the lack of a class driver to get in
> the way. Exposing specific GUIDs is a minimal and easy to upstream change which
> would enable rapid feature enabling.
> 
> Perhaps I should have led with this :-)
> 

So considering future plans, I'd really like if it's possible to expose all the GUID's the
GUID's the same as Windows does today.

As example is we have some diagnostic testing tools.  Having to whitelist interfaces
for them to operate would be sub-optimal.