linux-kernel - RE: [PATCH v6 14/14] platform/x86: dell-smbios-wmi: introduce userspace 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]

Date:   Tue, 10 Oct 2017 14:17:48 +0000
From:   <Mario.Limonciello@...l.com>
To:     <greg@...ah.com>
CC:     <dvhart@...radead.org>, <andy.shevchenko@...il.com>,
        <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <luto@...nel.org>,
        <quasisec@...gle.com>, <pali.rohar@...il.com>, <rjw@...ysocki.net>,
        <mjg59@...gle.com>, <hch@....de>
Subject: RE: [PATCH v6 14/14] platform/x86: dell-smbios-wmi: introduce
 userspace interface



> -----Original Message-----
> From: Greg KH [mailto:greg@...ah.com]
> Sent: Tuesday, October 10, 2017 8:59 AM
> To: Limonciello, Mario <Mario_Limonciello@...l.com>
> Cc: dvhart@...radead.org; Andy Shevchenko <andy.shevchenko@...il.com>;
> LKML <linux-kernel@...r.kernel.org>; platform-driver-x86@...r.kernel.org;
> Andy Lutomirski <luto@...nel.org>; quasisec@...gle.com;
> pali.rohar@...il.com; rjw@...ysocki.net; mjg59@...gle.com; hch@....de
> Subject: Re: [PATCH v6 14/14] platform/x86: dell-smbios-wmi: introduce
> userspace interface
> 
> On Mon, Oct 09, 2017 at 05:51:52PM -0500, Mario Limonciello wrote:
> > +	ret = device_create_file(&wdev->dev, &priv->req_buf_size_attr);
> > +	if (ret)
> > +		goto fail_create_sysfs;
> 
> Why isn't the "WMI core" creating this sysfs file?  Why have per-driver
> sysfs files, making all of the different apis totally different?  It's a
> "common" attribute that they are all going to have to provide, right?
> 
I hadn't really thought about that.  I suppose it's entirely reasonable
to have a way that all WMI ioctls for future drivers will advertise the size
of their expected buffer the same way.

So this does beg a question to others on this distribution who have worked
on WMI drivers- do you know of any WM**/ methods with multiple instances 
that use different buffer sizes, or is it reasonable to expect that the buffer size 
is consistent between instances?

Even in advanced MOF designs I haven't seen it, but this makes me
wonder if an attribute should be created for every instance to be future proof.
(For example $GUID/required_buffer_size/instance0, 
$GUID/required_buffer_size/instance1 etc)

> That way you also don't race with userspace :)
> 
> thanks,
> 
> greg k-h