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: <20170613120741.GG5248@pali>
Date:   Tue, 13 Jun 2017 14:07:41 +0200
From:   Pali Rohár <pali.rohar@...il.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Darren Hart <dvhart@...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 00:05:35 Christoph Hellwig wrote:
> 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.

Yes, adding new GUID is same hard as adding new PCI ID or USB ID. It is
really trivial patch.

> > 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.

Seeing vendor blob compiled for one particular userspace and
distribution which would be needed for having working notebook support
on Linux is way to the hell.

Here I agree with Christoph.

> > > 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.

In some cases filter function can be simple in some cases hard. I can
image that usage of while listing, plus in some cases also filtering
(when it would be relatively easy to implement).

-- 
Pali Rohár
pali.rohar@...il.com