linux-kernel - RE: [PATCH v3 2/2] dmi-id: add dmi/id/oem group for exporting oem strings to sysfs

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:   Wed, 31 Aug 2016 14:01:23 +0000
From:   <Mario_Limonciello@...l.com>
To:     <gregkh@...uxfoundation.org>, <Allen_Hung@...l.com>
CC:     <jdelvare@...e.com>, <rmk+kernel@....linux.org.uk>,
        <somlo@....edu>, <bjorn.andersson@...ymobile.com>,
        <jens.wiklander@...aro.org>, <agross@...eaurora.org>,
        <arnd@...db.de>, <sudeep.holla@....com>, <eric@...olt.net>,
        <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 2/2] dmi-id: add dmi/id/oem group for exporting oem
 strings to sysfs

Hi Greg,

> -----Original Message-----
> From: Greg Kroah-Hartman [mailto:gregkh@...uxfoundation.org]
> Sent: Wednesday, August 31, 2016 7:40 AM
> To: Hung, Allen <Allen_Hung@...l.com>
> Cc: Jean Delvare <jdelvare@...e.com>; Russell King
> <rmk+kernel@....linux.org.uk>; Gabriel Somlo <somlo@....edu>; Bjorn
> Andersson <bjorn.andersson@...ymobile.com>; Jens Wiklander
> <jens.wiklander@...aro.org>; Andy Gross <agross@...eaurora.org>; Arnd
> Bergmann <arnd@...db.de>; Sudeep Holla <sudeep.holla@....com>; Eric
> Anholt <eric@...olt.net>; linux-kernel@...r.kernel.org; Limonciello, Mario
> <Mario_Limonciello@...l.com>
> Subject: Re: [PATCH v3 2/2] dmi-id: add dmi/id/oem group for exporting oem
> strings to sysfs
> 
> On Mon, Aug 15, 2016 at 05:22:05PM +0800, Allen Hung wrote:
> > The oem strings in DMI system identification information of the BIOS
> > have been parsed and stored as dmi devices in dmi_scan.c but they are
> > not exported to userspace via sysfs.
> >
> > The patch intends to export oem strings to sysfs device /sys/class/dmi/id.
> > As the number of oem strings are dynamic, a group "oem" is added to
> > the device and the strings will be added to the group as string1,
> > string2, ..., and stringN.
> >
> > Signed-off-by: Allen Hung <allen_hung@...l.com>
> > ---
> >  drivers/firmware/Kconfig  |   9 ++++
> >  drivers/firmware/dmi-id.c | 116
> > ++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 125 insertions(+)
> >
> > diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index
> > 6664f11..885a6c9 100644
> > --- a/drivers/firmware/Kconfig
> > +++ b/drivers/firmware/Kconfig
> > @@ -119,6 +119,15 @@ config DMIID
> >  	  information from userspace through /sys/class/dmi/id/ or if you want
> >  	  DMI-based module auto-loading.
> >
> > +config DMIID_OEM_STRINGS
> > +	bool "Export OEM strings in SMBIOS/DMI via sysfs to userspace"
> > +	depends on DMIID
> > +	default n
> > +	help
> > +	  Say Y here if you want to query OEM strings (as part of the information
> > +	  contained in SMBIOS/DMI system identification) from userspace
> through
> > +	  /sys/class/dmi/id/oem/.
> 
> Why wouldn't you want these?
> 

Jean Delvare would rather see this implemented in userspace dmidecode.
Jean raised a concern in an earlier submission that this runs on every
machine (https://lkml.org/lkml/2016/8/2/799).

> > +
> >  config DMI_SYSFS
> >  	tristate "DMI table support in sysfs"
> >  	depends on SYSFS && DMI
> 
> Shouldn't the new option, if you really want it, be below this one?
> 

Ah yes, I think so.  If this ends up being the right approach Allen
will need to adjust and resubmit it.

> But again, why not just always provide these values, if they are in the DMI
> tables, and you want sysfs DMI support?

>From our (Allen and myself) perspective this makes the most sense too,
Jean had pushed back on this, so Allen re-submitted as making it optional.