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  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 09:56:46 -0700
From:   Darren Hart <>
To:     Pali Rohár <>
Cc:     Rafael Wysocki <>,
        Len Brown <>,
        Corentin Chary <>,
        Mario Limonciello <>,
        Andy Lutomirski <>,
        Andy Shevchenko <>,
        LKML <>,,
Subject: Re: RFC: WMI Enhancements

On Thu, Apr 13, 2017 at 09:33:39AM +0200, Pali Rohár wrote:
> On Wednesday 12 April 2017 16:08:54 Darren Hart wrote:
> > In Windows, applications interact with WMI more or less directly. We don't do
> > this in Linux currently, although it has been discussed in the past [3]. Some
> > vendors will work around this by performing SMI/SMM, which is inefficient at
> > best. Exposing WMI methods to userspace would bring parity to WMI for Linux and
> > Windows.
> Maybe we should first ask, why linux userspace applications need direct
> access to WMI? If we look at current WMI linux drivers, basically every
> one translate WMI interface to some standard linux class driver (with
> some extensions). This is something which should stay in kernel. E.g.
> rfkill, backlight, led, input keyboard, ...

Agreed on these common functions. Whenever we have a common subsystem / class
driver, we should make use of that. This is another good reason not to publish
all WMI methods wholesale to userspace. That said, class drivers are written
after we eventually see a pattern in drivers and refactor them to encapsulate a
common functionality. This takes time, and is only worth doing for things that
are truly common.

WMI (Windows Management Instrumentation) is very generic and is intended to
provide vendors the ability to manage and configure the systems at the firmware

I am a strong supporter of the following philosophy with respect to supporting
"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 :-)

Darren Hart
VMware Open Source Technology Center

Powered by blists - more mailing lists