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 08:34:48 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Pali Rohár <pali.rohar@...il.com>
Cc:     Mario.Limonciello@...l.com, Hans de Goede <hdegoede@...hat.com>,
        Michał Kępień <kernel@...pniu.pl>,
        Darren Hart <dvhart@...radead.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <len.brown@...el.com>, corentin.chary@...il.com,
        Andrew Lutomirski <luto@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        platform-driver-x86@...r.kernel.org,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: RFC: WMI Enhancements

On Thu, Apr 13, 2017 at 6:51 AM, Pali Rohár <pali.rohar@...il.com> wrote:
> On Thursday 13 April 2017 13:29:41 Mario.Limonciello@...l.com wrote:
>> > Please pardon my ignorance, but what do we actually gain by exposing WMI to
>> > userspace?  Enabling applications to fetch SMBIOS data?  We already have an
>> > interface for that.  Enabling applications to receive input events?  Likewise.
>>
>> Input notifications are just one aspect that received over WMI.  I don't see any
>> reason to move the notifications out of the kernel.
>>
>> In terms of userspace applications, once a WMI interface to userspace is available
>> libsmbios would change over to that.  Applications using libsmbios would benefit.
>
> Really libsmbios matters here? Hans (added to thread) wrote that
> libsmbios is a relic, something of ages long gone by and a normal user
> should never use it.
>
> If this is truth and libsmbios should not be used, then we probably do
> not need to care about it in changes for WMI.
>
> Hans, Mario, any comment/clarification about it?
>
>> > You mentioned WMI's efficiency compared to SMI/SMM, but is it a difference
>> > significant enough for anyone to notice?
>>
>> At least for Dell there are optimizations being made when data is requested over
>> the WMI-ACPI wrapper instead of directly via SMI/SMM.
>>
>> For example if the data is a "static" table or the request is to something that is
>> passed thru to the EC it's a big waste of effort to put the CPU in SMM.
>>
>> The savings there is significant.
>
> Maybe we can use this Dell WMI-ACPI wrapper for kernel drivers instead
> of current SMI/SMM direct access?
>

This would make sense to me.  IIRC the only functional difference is
the way that pointers are handled.  It shouldn't be that hard to make
it work for both variants, though.  It could look like:

buf = dell_smbios_alloc(...);
dell_smbios_put_pointer(buf, offset of pointer, offset of pointee);
dell_smbios_call(buf);

or similar.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ