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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20170613070535.GA13252@infradead.org>
Date:   Tue, 13 Jun 2017 00:05:35 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Darren Hart <dvhart@...radead.org>
Cc:     Pali Rohár <pali.rohar@...il.com>,
        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

Hi Darren,

first - can you please properly trim your replies and don't write
more than 7 characters per line?

On Mon, Jun 12, 2017 at 06:24:35PM -0700, Darren Hart wrote:
> This is a big topic for sure. Speed and scale of platform enabling is something
> I would like to see us support better. The barrier to entry to kernel
> changes is high, especially for trivial things, like adding IDs, GUIDs, etc.
> which would ideally, IMHO, be in the hands of the OEMs.

It's not.  It's a trivial patch, and you cover all Linux users.  Very
much unlike say the windows world where you are stuck with installing
a vendor specific set of drivers forever.

> Ideally, we would provide a generic way for users/OEMs/vendors to successfully
> support and maintain their own platforms, ideally with as little kernel changes
> as possible. If we can get closer to that than we are today with this WMI work,
> I think that is worth the effort.

Hell no!  The last thing we need on Linux is systems that once support
us added don't just work out of the box because you're missing your
vendor blob.

> > And filter layer which will accept only WMI calls which are safe for 
> > currently loaded/used kernel modules seems like a sane idea to ensure 
> > functionality of kernel plus allow userspace to do other things.
> 
> My biggest concern with this approach is maintenance. Because we would be doing
> something unforeseen by the specification, the various vendor implemented WMI
> APIs are not likely to be amenable to filtering. I can see these filters
> getting extremely complicated. They are "high touch", by which I mean each
> generation of platform may require subtle tweaks, which will be difficult to
> verify they don't break past generations.

Agreed.  As mentioned before I think the only sensible approach is
white listing GUIDs that have a valid userspace use case.  And use
the dynamic IDs approach to add them for debugging and reverse
engineering.

> There are certainly pros and cons. While this approach results in duplication of
> effort, it also allows vendors to "own their own destiny" and innovate and
> support their platforms independently. It also minimizes the amount of dead code
> accumulating for platforms that just don't exist for very long.

Bullshit alert..