linux-kernel - RE: [PATCH 06/12] platform/x86: dell-wmi-smbios: Add a sysfs interface for SMBIOS tokens

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: <7c2e7a1dc9864acfbe7eb78900f4748e@ausx13mpc120.AMER.DELL.COM>
Date:   Wed, 27 Sep 2017 19:50:49 +0000
From:   <Mario.Limonciello@...l.com>
To:     <luto@...nel.org>, <dvhart@...radead.org>,
        <andy.shevchenko@...il.com>, <luto@...capital.net>
CC:     <pali.rohar@...il.com>, <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <quasisec@...gle.com>
Subject: RE: [PATCH 06/12] platform/x86: dell-wmi-smbios: Add a sysfs
 interface for SMBIOS tokens

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@...nel.org]
> Sent: Wednesday, September 27, 2017 3:49 PM
> To: Darren Hart <dvhart@...radead.org>; Andy Shevchenko
> <andy.shevchenko@...il.com>; Andy Lutomirski <luto@...capital.net>
> Cc: Limonciello, Mario <Mario_Limonciello@...l.com>; Pali Rohár
> <pali.rohar@...il.com>; linux-kernel@...r.kernel.org; Platform Driver <platform-
> driver-x86@...r.kernel.org>; quasisec@...gle.com
> Subject: Re: [PATCH 06/12] platform/x86: dell-wmi-smbios: Add a sysfs interface
> for SMBIOS tokens
> 
> On 09/27/2017 11:55 AM, Darren Hart wrote:
> > On Wed, Sep 27, 2017 at 09:31:47PM +0300, Andy Shevchenko wrote:
> >> On Wed, Sep 27, 2017 at 9:27 PM,  <Mario.Limonciello@...l.com> wrote:
> >>
> >>>>>>> Darren, Andy, any comments? I'm not quite sure if such API is suitable
> >>>>>>> for long term in kernel.
> >>>>>>
> >>>>>> I would try to avoid sysfs interfaces for some particular devices.
> >>>>>> Besides we are creating a character device. Would it be suitable there?
> >>>>>
> >>>>> If the character device having 2 different ioctls for different needs is
> >>>>> acceptable I'm happy to adjust the series to do this instead.
> >>>>
> >>>> One piece of feedback I had re the char device was to see if we could avoid the
> >>>> need for the IOCTL altogether, I'd like to have that discussion before we add
> >>>> another.
> >>>
> >>> My original design was sysfs files for everything but it was raised by several
> folks
> >>> that you run into the potential of two userspace processes stomping on each
> >>> other's data when they run the ACPI call.  That's why I need to have a mutex to
> >>> protect and make sure that userspace calls get the right results.
> >>>
> >>
> >>>>>>> Basically tokens are list of tuples <id, location, value> with
> >>>>>>> possibility to active them, right?
> >>>>>>>
> >>>>>
> >>>>> I didn't add a way to activate them through this, it was only for
> >>>>> reading purpose.  Activating them should be possible through the
> >>>>> SMBIOS calling interface though.
> >>>>>
> >>>>
> >>>> These are read-only as I understood it, and only with the right privileges.
> >>>> Sysfs seemed appropriate for this to me.
> >>>
> >>> Andy S was against having this data as another sysfs file.   From a userspace
> >>> perspective I think it's simpler to just parse a sysfs file with read only static
> >>> data as root.  With the current ioctl based solution it requires userspace to run
> >>> an ioctl to determine how many tokens exist, then allocate a chunk of memory
> >>> big enough to hold all the token data and then run another ioctl to get all the
> tokens.
> >>>
> >>> Andy S, given this change between v1 and v2 what do you feel is better?
> >>
> >> I have no strong opinion on this. That's why I recommended to listen to Andy L.
> >
> > +Andy Lutomirski
> >
> > Andy L, any preference on your part regarding exporting these tokens via sysfs
> > or through an additional IOCTL in the chardev?
> >
> 
> Not really.  If this is indeed static data that is potentially useful
> for scripts and such, than sysfs is kind of nice.

OK thanks.  I'll switch back to sysfs for v3.