linux-kernel - RE: [PATCH v9 17/17] tools/wmi: add a sample for dell smbios communication over WMI

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e225d842e0274a1897c63089444a0814@ausx13mpc120.AMER.DELL.COM>
Date:   Wed, 18 Oct 2017 13:55:45 +0000
From:   <Mario.Limonciello@...l.com>
To:     <pali.rohar@...il.com>, <greg@...ah.com>,
        <gnomes@...rguk.ukuu.org.uk>
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>, <rjw@...ysocki.net>, <mjg59@...gle.com>,
        <hch@....de>
Subject: RE: [PATCH v9 17/17] tools/wmi: add a sample for dell smbios
 communication over WMI

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@...il.com]
> Sent: Wednesday, October 18, 2017 2:29 AM
> To: Greg KH <greg@...ah.com>; Alan Cox <gnomes@...rguk.ukuu.org.uk>
> 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; rjw@...ysocki.net;
> mjg59@...gle.com; hch@....de; Limonciello, Mario
> <Mario_Limonciello@...l.com>
> Subject: Re: [PATCH v9 17/17] tools/wmi: add a sample for dell smbios
> communication over WMI
> 
> On Tuesday 17 October 2017 13:22:01 Mario Limonciello wrote:
> > diff --git a/tools/wmi/dell-smbios-example.c b/tools/wmi/dell-smbios-example.c
> > new file mode 100644
> > index 000000000000..69c4dd9c6056
> > --- /dev/null
> > +++ b/tools/wmi/dell-smbios-example.c
> > @@ -0,0 +1,214 @@
> > +/*
> > + *  Sample application for SMBIOS communication over WMI interface
> > + *  Performs the following:
> > + *  - Simple class/select lookup for TPM information
> > + *  - Simple query of known tokens and their values
> > + *  - Simple activation of a token
> > + *
> > + *  Copyright (C) 2017 Dell, Inc.
> > + *
> > + *  This program is free software; you can redistribute it and/or modify
> > + *  it under the terms of the GNU General Public License version 2 as
> > + *  published by the Free Software Foundation.
> > + */
> > +
> > +#include <errno.h>
> > +#include <fcntl.h>
> > +#include <stdio.h>
> > +#include <stdlib.h>
> > +#include <sys/ioctl.h>
> > +#include <unistd.h>
> > +
> > +/* if uapi header isn't installed, this might not yet exist */
> > +#ifndef __packed
> > +#define __packed __attribute__((packed))
> > +#endif
> > +#include <linux/wmi.h>
> > +
> > +/* It would be better to discover these using udev, but for a simple
> > + * application they're hardcoded
> > + */
> > +static const char *ioctl_devfs = "/dev/wmi/dell-smbios";
> > +static const char *token_sysfs =
> > +			"/sys/bus/platform/devices/dell-smbios.0/tokens";
> > +static const char *buffer_sysfs =
> > +			"/sys/bus/wmi/devices/A80593CE-A997-11DA-B012-
> B622A1EF5492/required_buffer_size";
> 
> Greg, Alan, could userspace expects those paths to be part of kernel
> <--> userspace ABI? Looking e.g. at "dell-smbios.0" name and I'm not
> sure if this is something which is going to be stable between kernel
> versions and forever as part of ABI.

In my sample application to be distributed with the kernel these are 
hardcoded paths, but if more dependencies were used, I would
expect all 3 of these paths to be discovered using udev.  
I do include a comment for that point specifically.

> 
> Also if everything is part of smbios API, would not it better to provide
> everything via IOCTL over /dev/wmi/dell-smbios? I think this code is too
> complicated, just because for correct IOCTL buffer size it needs to read
> other properties via sysfs, etc... For me it looks like that it is not a
> good API for userspace developers.
> 
> --

This does give me an idea, how about a read on the character device
will return required buffer size instead of needing to find a sysfs 
attribute?  This seems more intuitive to me.

Token information is provided over sysfs for multiple reasons.
1) It's applicable to all dispatchers.  Even if the WMI dispatcher wasn't
used it's useful for userspace to query through.  For example the SMI call
to get tokens in libsmbios can be simplified to just read sysfs files.

2) it's information not coming from ACPI-WMI.  This series is setting
precedent for how to interact with ACPI-WMI methods in userspace.
putting in random data on the IOCTL that is not used in the ACPI-WMI
method or provided by the WMI bus doesn't fit.

3) It is static information that won't change until you reboot.