[PATCH 00/12] Introduce support for Dell SMBIOS over WMI

[PATCH 00/12] Introduce support for Dell SMBIOS over WMI

[Mario Limonciello]

The existing way that the dell-smbios helper module and associated
other drivers (dell-laptop, dell-wmi) communicate with the platform
really isn't secure.  It requires creating a buffer in physical
DMA32 memory space and passing that to the platform via SMM.

Since the platform got a physical memory pointer, you've just got
to trust that the platform has only modified (and accessed) memory
within that buffer.

Dell Platform designers recognize this security risk and offer a
safer way to communicate with the platform over ACPI.  This is
in turn exposed via a WMI interface to the OS.

When communicating over WMI-ACPI the communication doesn't occur
with physical memory pointers.  When the ASL is invoked, the fixed
length ACPI buffer is copied to a small operating region.  The ASL
will invoke the SMI, and SMM will only have access to this operating
region.  When the ASL returns the buffer is copied back for the OS
to process.

This method of communication should also deprecate the usage of the
dcdbas kernel module and software dependent upon it's interface.
Instead offer a syfs interface for communicating with this ASL
method to allow userspace to use instead.

To faciliate that needs for userspace and kernel space this patch
series introduces a generic way for WMI drivers to be able to
create character devices through the WMI bus when desired.
Requiring WMI drivers to explictly ask for this functionality will
act as an effective vendor whitelist.

Mario Limonciello (12):
  platform/x86: dell-wmi: label driver as handling notifications
  platform/x86: dell-wmi: Don't match on descriptor GUID modalias
  platform/x86: dell-smbios: Add pr_fmt definition to driver
  platform/x86: dell-smbios: Switch to a WMI-ACPI interface
  platform/x86: dell-smbios: rename to dell-wmi-smbios
  platform/x86: dell-wmi-smbios: Add a sysfs interface for SMBIOS tokens
  platform/x86: dell-wmi-smbios: Use Dell WMI descriptor check
  platform/x86: wmi: Cleanup exit routine in reverse order of init
  platform/x86: wmi: create character devices when requested by drivers
  platform/x86: wmi: destroy on cleanup rather than unregister
  platform/x86: dell-wmi-smbios: introduce character device for
    userspace
  platform/x86: Kconfig: Change the default settings for dell-wmi-smbios

 Documentation/ABI/testing/dell-wmi-smbios          |  19 +
 .../ABI/testing/sysfs-platform-dell-wmi-smbios     |  16 +
 MAINTAINERS                                        |   8 +-
 drivers/platform/x86/Kconfig                       |  13 +-
 drivers/platform/x86/Makefile                      |   2 +-
 drivers/platform/x86/dell-laptop.c                 |   2 +-
 drivers/platform/x86/dell-smbios.c                 | 213 ----------
 drivers/platform/x86/dell-wmi-smbios.c             | 444 +++++++++++++++++++++
 .../x86/{dell-smbios.h => dell-wmi-smbios.h}       |  23 +-
 drivers/platform/x86/dell-wmi.c                    |  78 +---
 drivers/platform/x86/wmi.c                         | 104 ++++-
 include/linux/wmi.h                                |   1 +
 12 files changed, 610 insertions(+), 313 deletions(-)
 create mode 100644 Documentation/ABI/testing/dell-wmi-smbios
 create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-wmi-smbios
 delete mode 100644 drivers/platform/x86/dell-smbios.c
 create mode 100644 drivers/platform/x86/dell-wmi-smbios.c
 rename drivers/platform/x86/{dell-smbios.h => dell-wmi-smbios.h} (75%)

-- 
2.14.1

[PATCH 01/12] platform/x86: dell-wmi: label driver as handling notifications

[Mario Limonciello]

This driver serves the purpose of responding to WMI based notifications
from the DELL_EVENT_GUID (9DBB5994-A997-11DA-B012-B622A1EF5492).
Other GUIDs will be handled by separate drivers.

Update the language used by this driver to avoid future confusion.

Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
---
 MAINTAINERS                  | 2 +-
 drivers/platform/x86/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2281af4b41b6..5d8ea24a8ee7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3996,7 +3996,7 @@ S:	Maintained
 F:	Documentation/dcdbas.txt
 F:	drivers/firmware/dcdbas.*
 
-DELL WMI EXTRAS DRIVER
+DELL WMI NOTIFICATIONS DRIVER
 M:	Matthew Garrett <mjg59@srcf.ucam.org>
 M:	Pali Rohár <pali.rohar@gmail.com>
 S:	Maintained
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 80b87954f6dd..9e52f05daa2e 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -116,7 +116,7 @@ config DELL_LAPTOP
 	laptops (except for some models covered by the Compal driver).
 
 config DELL_WMI
-	tristate "Dell WMI extras"
+	tristate "Dell WMI notifications"
 	depends on ACPI_WMI
 	depends on DMI
 	depends on INPUT
-- 
2.14.1

[PATCH 02/12] platform/x86: dell-wmi: Don't match on descriptor GUID modalias

[Mario Limonciello]

The descriptor GUID is not used to indicate that WMI notifications
in the dell-wmi driver work properly.  As such a modalias should
not be present that causes this driver to load on systems with this
GUID.

Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
---
 drivers/platform/x86/dell-wmi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 28d9f8696081..1fbef560ca67 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -51,7 +51,6 @@ MODULE_LICENSE("GPL");
 static bool wmi_requires_smbios_request;
 
 MODULE_ALIAS("wmi:"DELL_EVENT_GUID);
-MODULE_ALIAS("wmi:"DELL_DESCRIPTOR_GUID);
 
 struct dell_wmi_priv {
 	struct input_dev *input_dev;
-- 
2.14.1

[PATCH 03/12] platform/x86: dell-smbios: Add pr_fmt definition to driver

[Mario Limonciello]

Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
---
 drivers/platform/x86/dell-smbios.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/dell-smbios.c b/drivers/platform/x86/dell-smbios.c
index 0a5723468bff..e9b1ca07c872 100644
--- a/drivers/platform/x86/dell-smbios.c
+++ b/drivers/platform/x86/dell-smbios.c
@@ -12,6 +12,7 @@
  *  it under the terms of the GNU General Public License version 2 as
  *  published by the Free Software Foundation.
  */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include <linux/kernel.h>
 #include <linux/module.h>
-- 
2.14.1

[PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI interface

[Mario Limonciello]

The driver currently uses an SMI interface which grants direct access
to physical memory to the platform via a pointer.

Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
for a buffer of data storage when platform calls are performed.

This is a safer approach to use in kernel drivers as the platform will
only have access to that OperationRegion.

As a result, this change removes the dependency on this driver on the
dcdbas kernel module.

Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
---
 drivers/platform/x86/Kconfig       |  8 ++--
 drivers/platform/x86/dell-smbios.c | 76 ++++++++++++++++++++++++++------------
 drivers/platform/x86/dell-smbios.h | 11 +++---
 3 files changed, 63 insertions(+), 32 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 9e52f05daa2e..81d61c0f4ef8 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -92,13 +92,13 @@ config ASUS_LAPTOP
 	  If you have an ACPI-compatible ASUS laptop, say Y or M here.
 
 config DELL_SMBIOS
-	tristate
-	select DCDBAS
+	tristate "Dell WMI SMBIOS calling interface"
+	depends on ACPI_WMI
 	---help---
 	This module provides common functions for kernel modules using
-	Dell SMBIOS.
+	Dell SMBIOS over ACPI-WMI.
 
-	If you have a Dell laptop, say Y or M here.
+	If you have a Dell computer, say Y or M here.
 
 config DELL_LAPTOP
 	tristate "Dell Laptop Extras"
diff --git a/drivers/platform/x86/dell-smbios.c b/drivers/platform/x86/dell-smbios.c
index e9b1ca07c872..c06262a89169 100644
--- a/drivers/platform/x86/dell-smbios.c
+++ b/drivers/platform/x86/dell-smbios.c
@@ -4,6 +4,7 @@
  *  Copyright (c) Red Hat <mjg@redhat.com>
  *  Copyright (c) 2014 Gabriele Mazzotta <gabriele.mzt@gmail.com>
  *  Copyright (c) 2014 Pali Rohár <pali.rohar@gmail.com>
+ *  Copyright (c) 2017 Dell Inc.
  *
  *  Based on documentation in the libsmbios package:
  *  Copyright (C) 2005-2014 Dell Inc.
@@ -18,13 +19,12 @@
 #include <linux/module.h>
 #include <linux/dmi.h>
 #include <linux/err.h>
-#include <linux/gfp.h>
 #include <linux/mutex.h>
-#include <linux/slab.h>
-#include <linux/io.h>
-#include "../../firmware/dcdbas.h"
+#include <linux/wmi.h>
 #include "dell-smbios.h"
 
+#define DELL_WMI_SMBIOS_GUID "A80593CE-A997-11DA-B012-B622A1EF5492"
+
 struct calling_interface_structure {
 	struct dmi_header header;
 	u16 cmdIOAddress;
@@ -76,20 +76,39 @@ void dell_smbios_release_buffer(void)
 }
 EXPORT_SYMBOL_GPL(dell_smbios_release_buffer);
 
-void dell_smbios_send_request(int class, int select)
+int run_wmi_smbios_call(struct calling_interface_buffer *buffer)
 {
-	struct smi_cmd command;
+	struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+	struct acpi_buffer input;
+	union acpi_object *obj;
+	acpi_status status;
+
+	input.length = sizeof(struct calling_interface_buffer);
+	input.pointer = buffer;
+
+	status = wmi_evaluate_method(DELL_WMI_SMBIOS_GUID,
+				     0, 1, &input, &output);
+	if (ACPI_FAILURE(status)) {
+		pr_err("%x/%x [%x,%x,%x,%x] call failed\n",
+			buffer->class, buffer->select, buffer->input[0],
+			buffer->input[1], buffer->input[2], buffer->input[3]);
+			return -EIO;
+	}
+	obj = (union acpi_object *)output.pointer;
+	if (obj->type != ACPI_TYPE_BUFFER) {
+		pr_err("invalid type : %d\n", obj->type);
+		return -EIO;
+	}
+	memcpy(buffer, obj->buffer.pointer, input.length);
 
-	command.magic = SMI_CMD_MAGIC;
-	command.command_address = da_command_address;
-	command.command_code = da_command_code;
-	command.ebx = virt_to_phys(buffer);
-	command.ecx = 0x42534931;
+	return 0;
+}
 
+void dell_smbios_send_request(int class, int select)
+{
 	buffer->class = class;
 	buffer->select = select;
-
-	dcdbas_smi_request(&command);
+	run_wmi_smbios_call(buffer);
 }
 EXPORT_SYMBOL_GPL(dell_smbios_send_request);
 
@@ -170,7 +189,7 @@ static void __init find_tokens(const struct dmi_header *dm, void *dummy)
 	}
 }
 
-static int __init dell_smbios_init(void)
+static int dell_smbios_probe(struct wmi_device *wdev)
 {
 	int ret;
 
@@ -181,11 +200,7 @@ static int __init dell_smbios_init(void)
 		return -ENODEV;
 	}
 
-	/*
-	 * Allocate buffer below 4GB for SMI data--only 32-bit physical addr
-	 * is passed to SMI handler.
-	 */
-	buffer = (void *)__get_free_page(GFP_KERNEL | GFP_DMA32);
+	buffer = (void *)__get_free_page(GFP_KERNEL);
 	if (!buffer) {
 		ret = -ENOMEM;
 		goto fail_buffer;
@@ -198,17 +213,32 @@ static int __init dell_smbios_init(void)
 	return ret;
 }
 
-static void __exit dell_smbios_exit(void)
+static int dell_smbios_remove(struct wmi_device *wdev)
 {
 	kfree(da_tokens);
 	free_page((unsigned long)buffer);
+	return 0;
 }
 
-subsys_initcall(dell_smbios_init);
-module_exit(dell_smbios_exit);
+static const struct wmi_device_id dell_smbios_id_table[] = {
+	{ .guid_string = DELL_WMI_SMBIOS_GUID },
+	{ },
+};
+
+static struct wmi_driver dell_smbios_driver = {
+	.driver = {
+		.name = "dell-smbios",
+	},
+	.probe = dell_smbios_probe,
+	.remove = dell_smbios_remove,
+	.id_table = dell_smbios_id_table,
+};
+module_wmi_driver(dell_smbios_driver);
+
 
 MODULE_AUTHOR("Matthew Garrett <mjg@redhat.com>");
 MODULE_AUTHOR("Gabriele Mazzotta <gabriele.mzt@gmail.com>");
 MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
-MODULE_DESCRIPTION("Common functions for kernel modules using Dell SMBIOS");
+MODULE_AUTHOR("Mario Limonciello <mario.limonciello@dell.com>");
+MODULE_DESCRIPTION("Common functions for kernel modules using Dell SMBIOS over WMI");
 MODULE_LICENSE("GPL");
diff --git a/drivers/platform/x86/dell-smbios.h b/drivers/platform/x86/dell-smbios.h
index 45cbc2292cd3..e1e29697b362 100644
--- a/drivers/platform/x86/dell-smbios.h
+++ b/drivers/platform/x86/dell-smbios.h
@@ -4,6 +4,7 @@
  *  Copyright (c) Red Hat <mjg@redhat.com>
  *  Copyright (c) 2014 Gabriele Mazzotta <gabriele.mzt@gmail.com>
  *  Copyright (c) 2014 Pali Rohár <pali.rohar@gmail.com>
+ *  Copyright (c) 2017 Dell Inc.
  *
  *  Based on documentation in the libsmbios package:
  *  Copyright (C) 2005-2014 Dell Inc.
@@ -18,14 +19,14 @@
 
 struct notifier_block;
 
-/* This structure will be modified by the firmware when we enter
- * system management mode, hence the volatiles */
-
 struct calling_interface_buffer {
 	u16 class;
 	u16 select;
-	volatile u32 input[4];
-	volatile u32 output[4];
+	u32 input[4];
+	u32 output[4];
+	u32 argattrib;
+	u32 blength;
+	u8 data[4052];
 } __packed;
 
 struct calling_interface_token {
-- 
2.14.1

[PATCH 05/12] platform/x86: dell-smbios: rename to dell-wmi-smbios

[Mario Limonciello]

This follows the style of the rest of the platform x86 WMI drivers.

Renaming the driver requires adjusting the other drivers using
dell-smbios to pick up the newly named includes.

While renaming, I noticed that this driver was missing from
MAINTAINERs. Add it to that and myself to the list of people maintaing
it.

Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
---
 MAINTAINERS                                          |  6 ++++++
 drivers/platform/x86/Kconfig                         |  2 +-
 drivers/platform/x86/Makefile                        |  2 +-
 drivers/platform/x86/dell-laptop.c                   |  2 +-
 .../x86/{dell-smbios.c => dell-wmi-smbios.c}         | 20 ++++++++++----------
 .../x86/{dell-smbios.h => dell-wmi-smbios.h}         |  4 ++--
 drivers/platform/x86/dell-wmi.c                      |  2 +-
 7 files changed, 22 insertions(+), 16 deletions(-)
 rename drivers/platform/x86/{dell-smbios.c => dell-wmi-smbios.c} (92%)
 rename drivers/platform/x86/{dell-smbios.h => dell-wmi-smbios.h} (96%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5d8ea24a8ee7..437daa9062e1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4002,6 +4002,12 @@ M:	Pali Rohár <pali.rohar@gmail.com>
 S:	Maintained
 F:	drivers/platform/x86/dell-wmi.c
 
+DELL WMI SMBIOS DRIVER
+M:	Pali Rohár <pali.rohar@gmail.com>
+M:	Mario Limonciello <mario.limonciello@dell.com>
+S:	Maintained
+F:	drivers/platform/x86/dell-wmi-smbios.c
+
 DELTA ST MEDIA DRIVER
 M:	Hugues Fruchet <hugues.fruchet@st.com>
 L:	linux-media@vger.kernel.org
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 81d61c0f4ef8..a70bcd8caa72 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -91,7 +91,7 @@ config ASUS_LAPTOP
 
 	  If you have an ACPI-compatible ASUS laptop, say Y or M here.
 
-config DELL_SMBIOS
+config DELL_WMI_SMBIOS
 	tristate "Dell WMI SMBIOS calling interface"
 	depends on ACPI_WMI
 	---help---
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 91cec1751461..b127a3bc1fab 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -11,11 +11,11 @@ obj-$(CONFIG_EEEPC_WMI)		+= eeepc-wmi.o
 obj-$(CONFIG_MSI_LAPTOP)	+= msi-laptop.o
 obj-$(CONFIG_ACPI_CMPC)		+= classmate-laptop.o
 obj-$(CONFIG_COMPAL_LAPTOP)	+= compal-laptop.o
-obj-$(CONFIG_DELL_SMBIOS)	+= dell-smbios.o
 obj-$(CONFIG_DELL_LAPTOP)	+= dell-laptop.o
 obj-$(CONFIG_DELL_WMI)		+= dell-wmi.o
 obj-$(CONFIG_DELL_WMI_AIO)	+= dell-wmi-aio.o
 obj-$(CONFIG_DELL_WMI_LED)	+= dell-wmi-led.o
+obj-$(CONFIG_DELL_WMI_SMBIOS)	+= dell-wmi-smbios.o
 obj-$(CONFIG_DELL_SMO8800)	+= dell-smo8800.o
 obj-$(CONFIG_DELL_RBTN)		+= dell-rbtn.o
 obj-$(CONFIG_ACER_WMI)		+= acer-wmi.o
diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
index f42159fd2031..bf569ea93e9d 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -33,7 +33,7 @@
 #include <linux/seq_file.h>
 #include <acpi/video.h>
 #include "dell-rbtn.h"
-#include "dell-smbios.h"
+#include "dell-wmi-smbios.h"
 
 #define BRIGHTNESS_TOKEN 0x7d
 #define KBD_LED_OFF_TOKEN 0x01E1
diff --git a/drivers/platform/x86/dell-smbios.c b/drivers/platform/x86/dell-wmi-smbios.c
similarity index 92%
rename from drivers/platform/x86/dell-smbios.c
rename to drivers/platform/x86/dell-wmi-smbios.c
index c06262a89169..7f896701fb7b 100644
--- a/drivers/platform/x86/dell-smbios.c
+++ b/drivers/platform/x86/dell-wmi-smbios.c
@@ -21,7 +21,7 @@
 #include <linux/err.h>
 #include <linux/mutex.h>
 #include <linux/wmi.h>
-#include "dell-smbios.h"
+#include "dell-wmi-smbios.h"
 
 #define DELL_WMI_SMBIOS_GUID "A80593CE-A997-11DA-B012-B622A1EF5492"
 
@@ -189,7 +189,7 @@ static void __init find_tokens(const struct dmi_header *dm, void *dummy)
 	}
 }
 
-static int dell_smbios_probe(struct wmi_device *wdev)
+static int dell_wmi_smbios_probe(struct wmi_device *wdev)
 {
 	int ret;
 
@@ -213,27 +213,27 @@ static int dell_smbios_probe(struct wmi_device *wdev)
 	return ret;
 }
 
-static int dell_smbios_remove(struct wmi_device *wdev)
+static int dell_wmi_smbios_remove(struct wmi_device *wdev)
 {
 	kfree(da_tokens);
 	free_page((unsigned long)buffer);
 	return 0;
 }
 
-static const struct wmi_device_id dell_smbios_id_table[] = {
+static const struct wmi_device_id dell_wmi_smbios_id_table[] = {
 	{ .guid_string = DELL_WMI_SMBIOS_GUID },
 	{ },
 };
 
-static struct wmi_driver dell_smbios_driver = {
+static struct wmi_driver dell_wmi_smbios_driver = {
 	.driver = {
-		.name = "dell-smbios",
+		.name = "dell-wmi-smbios",
 	},
-	.probe = dell_smbios_probe,
-	.remove = dell_smbios_remove,
-	.id_table = dell_smbios_id_table,
+	.probe = dell_wmi_smbios_probe,
+	.remove = dell_wmi_smbios_remove,
+	.id_table = dell_wmi_smbios_id_table,
 };
-module_wmi_driver(dell_smbios_driver);
+module_wmi_driver(dell_wmi_smbios_driver);
 
 
 MODULE_AUTHOR("Matthew Garrett <mjg@redhat.com>");
diff --git a/drivers/platform/x86/dell-smbios.h b/drivers/platform/x86/dell-wmi-smbios.h
similarity index 96%
rename from drivers/platform/x86/dell-smbios.h
rename to drivers/platform/x86/dell-wmi-smbios.h
index e1e29697b362..e6e9990bb2b7 100644
--- a/drivers/platform/x86/dell-smbios.h
+++ b/drivers/platform/x86/dell-wmi-smbios.h
@@ -14,8 +14,8 @@
  *  published by the Free Software Foundation.
  */
 
-#ifndef _DELL_SMBIOS_H_
-#define _DELL_SMBIOS_H_
+#ifndef _DELL_WMI_SMBIOS_H_
+#define _DELL_WMI_SMBIOS_H_
 
 struct notifier_block;
 
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 1fbef560ca67..e8b4d412eabc 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -38,7 +38,7 @@
 #include <linux/dmi.h>
 #include <linux/wmi.h>
 #include <acpi/video.h>
-#include "dell-smbios.h"
+#include "dell-wmi-smbios.h"
 
 MODULE_AUTHOR("Matthew Garrett <mjg@redhat.com>");
 MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
-- 
2.14.1

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

[Mario Limonciello]

Currently userspace tools can access system tokens via the dcdbas
kernel module and a SMI call that will cause the platform to execute
SMM code.

With a goal in mind of deprecating the dcdbas kernel module a different
method for accessing these tokens from userspace needs to be created.

This is intentionally marked to only be readable as root as it can
contain sensitive information about the platform's configuration.

Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
---
 .../ABI/testing/sysfs-platform-dell-wmi-smbios     | 16 +++++++++
 drivers/platform/x86/dell-wmi-smbios.c             | 38 ++++++++++++++++++++++
 2 files changed, 54 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-wmi-smbios

diff --git a/Documentation/ABI/testing/sysfs-platform-dell-wmi-smbios b/Documentation/ABI/testing/sysfs-platform-dell-wmi-smbios
new file mode 100644
index 000000000000..6d151f2dffba
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-dell-wmi-smbios
@@ -0,0 +1,16 @@
+What:		/sys/devices/platform/<platform>/tokens
+Date:		October 2017
+KernelVersion:	4.15
+Contact:	"Mario Limonciello" <mario.limonciello@dell.com>
+Description:
+		A read-only description of Dell platform tokens
+		available on the machine.
+
+		The tokens will be displayed in the following
+		machine readable format with each token on a
+		new line:
+
+		ID @ Location : value
+
+		For example token:
+		5 @ 5 : 3
diff --git a/drivers/platform/x86/dell-wmi-smbios.c b/drivers/platform/x86/dell-wmi-smbios.c
index 7f896701fb7b..c3701fdadf7b 100644
--- a/drivers/platform/x86/dell-wmi-smbios.c
+++ b/drivers/platform/x86/dell-wmi-smbios.c
@@ -189,6 +189,34 @@ static void __init find_tokens(const struct dmi_header *dm, void *dummy)
 	}
 }
 
+static ssize_t tokens_show(struct device *dev,
+			   struct device_attribute *attr, char *buf)
+{
+	size_t off = 0;
+	int i;
+
+	for (i = 0; i < da_num_tokens; i++) {
+		if (off > PAGE_SIZE)
+			break;
+		off += scnprintf(buf+off, PAGE_SIZE-off, "%x @ %x : %x\n",
+		da_tokens[i].tokenID, da_tokens[i].location,
+		da_tokens[i].value);
+	}
+
+	return off;
+}
+
+DEVICE_ATTR(tokens, 0400, tokens_show, NULL);
+
+static struct attribute *smbios_attrs[] = {
+	&dev_attr_tokens.attr,
+	NULL
+};
+
+static const struct attribute_group smbios_attribute_group = {
+	.attrs = smbios_attrs,
+};
+
 static int dell_wmi_smbios_probe(struct wmi_device *wdev)
 {
 	int ret;
@@ -206,8 +234,16 @@ static int dell_wmi_smbios_probe(struct wmi_device *wdev)
 		goto fail_buffer;
 	}
 
+	ret = sysfs_create_group(&wdev->dev.kobj, &smbios_attribute_group);
+	if (ret)
+		goto fail_create_group;
+	kobject_uevent(&wdev->dev.kobj, KOBJ_CHANGE);
+
 	return 0;
 
+fail_create_group:
+	free_page((unsigned long)buffer);
+
 fail_buffer:
 	kfree(da_tokens);
 	return ret;
@@ -215,8 +251,10 @@ static int dell_wmi_smbios_probe(struct wmi_device *wdev)
 
 static int dell_wmi_smbios_remove(struct wmi_device *wdev)
 {
+	sysfs_remove_group(&wdev->dev.kobj, &smbios_attribute_group);
 	kfree(da_tokens);
 	free_page((unsigned long)buffer);
+	kobject_uevent(&wdev->dev.kobj, KOBJ_CHANGE);
 	return 0;
 }
 
-- 
2.14.1

[PATCH 07/12] platform/x86: dell-wmi-smbios: Use Dell WMI descriptor check

[Mario Limonciello]

The Dell WMI descriptor check is used as an indication that WMI
calls are safe to run both when used with the notification
ASL/GUID pair as well as the SMBIOS calling ASL/GUID pair.

As some code in dell-wmi-smbios is already a prerequisite for
dell-wmi, move the code for performing the descriptor check into
dell-wmi-smbios and let both drivers use it from there.

Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
---
 drivers/platform/x86/dell-wmi-smbios.c | 78 ++++++++++++++++++++++++++++++++++
 drivers/platform/x86/dell-wmi-smbios.h |  3 ++
 drivers/platform/x86/dell-wmi.c        | 75 +-------------------------------
 3 files changed, 82 insertions(+), 74 deletions(-)

diff --git a/drivers/platform/x86/dell-wmi-smbios.c b/drivers/platform/x86/dell-wmi-smbios.c
index c3701fdadf7b..9deb851ff517 100644
--- a/drivers/platform/x86/dell-wmi-smbios.c
+++ b/drivers/platform/x86/dell-wmi-smbios.c
@@ -24,6 +24,7 @@
 #include "dell-wmi-smbios.h"
 
 #define DELL_WMI_SMBIOS_GUID "A80593CE-A997-11DA-B012-B622A1EF5492"
+#define DELL_DESCRIPTOR_GUID "8D9DDCBC-A997-11DA-B012-B622A1EF5492"
 
 struct calling_interface_structure {
 	struct dmi_header header;
@@ -217,8 +218,81 @@ static const struct attribute_group smbios_attribute_group = {
 	.attrs = smbios_attrs,
 };
 
+/*
+ * Descriptor buffer is 128 byte long and contains:
+ *
+ *       Name             Offset  Length  Value
+ * Vendor Signature          0       4    "DELL"
+ * Object Signature          4       4    " WMI"
+ * WMI Interface Version     8       4    <version>
+ * WMI buffer length        12       4    4096
+ */
+int dell_wmi_check_descriptor_buffer(struct wmi_device *wdev, u32 *version)
+{
+	union acpi_object *obj = NULL;
+	struct wmi_device *desc_dev;
+	u32 *desc_buffer;
+	int ret;
+
+	desc_dev = wmidev_get_other_guid(wdev, DELL_DESCRIPTOR_GUID);
+	if (!desc_dev) {
+		dev_err(&wdev->dev, "Dell WMI descriptor does not exist\n");
+		return -ENODEV;
+	}
+
+	obj = wmidev_block_query(desc_dev, 0);
+	if (!obj) {
+		dev_err(&wdev->dev, "failed to read Dell WMI descriptor\n");
+		ret = -EIO;
+		goto out;
+	}
+
+	if (obj->type != ACPI_TYPE_BUFFER) {
+		dev_err(&wdev->dev, "Dell descriptor has wrong type\n");
+		ret = -EINVAL;
+		goto out;
+	}
+
+	if (obj->buffer.length != 128) {
+		dev_err(&wdev->dev,
+			"Dell descriptor buffer has invalid length (%d)\n",
+			obj->buffer.length);
+		if (obj->buffer.length < 16) {
+			ret = -EINVAL;
+			goto out;
+		}
+	}
+
+	desc_buffer = (u32 *)obj->buffer.pointer;
+
+	if (desc_buffer[0] != 0x4C4C4544 && desc_buffer[1] != 0x494D5720)
+		dev_warn(&wdev->dev, "Dell descriptor buffer has invalid signature (%*ph)\n",
+			8, desc_buffer);
+
+	if (desc_buffer[2] != 0 && desc_buffer[2] != 1)
+		dev_warn(&wdev->dev, "Dell descriptor buffer has unknown version (%d)\n",
+			desc_buffer[2]);
+
+	if (desc_buffer[3] != 4096)
+		dev_warn(&wdev->dev, "Dell descriptor buffer has invalid buffer length (%d)\n",
+			desc_buffer[3]);
+
+	*version = desc_buffer[2];
+	ret = 0;
+
+	dev_info(&wdev->dev, "Detected Dell WMI interface version %u\n",
+		*version);
+
+out:
+	kfree(obj);
+	put_device(&desc_dev->dev);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(dell_wmi_check_descriptor_buffer);
+
 static int dell_wmi_smbios_probe(struct wmi_device *wdev)
 {
+	u32 interface_version;
 	int ret;
 
 	dmi_walk(find_tokens, NULL);
@@ -228,6 +302,10 @@ static int dell_wmi_smbios_probe(struct wmi_device *wdev)
 		return -ENODEV;
 	}
 
+	ret = dell_wmi_check_descriptor_buffer(wdev, &interface_version);
+	if (ret)
+		return ret;
+
 	buffer = (void *)__get_free_page(GFP_KERNEL);
 	if (!buffer) {
 		ret = -ENOMEM;
diff --git a/drivers/platform/x86/dell-wmi-smbios.h b/drivers/platform/x86/dell-wmi-smbios.h
index e6e9990bb2b7..0521ec5d437b 100644
--- a/drivers/platform/x86/dell-wmi-smbios.h
+++ b/drivers/platform/x86/dell-wmi-smbios.h
@@ -17,6 +17,8 @@
 #ifndef _DELL_WMI_SMBIOS_H_
 #define _DELL_WMI_SMBIOS_H_
 
+#include <linux/wmi.h>
+
 struct notifier_block;
 
 struct calling_interface_buffer {
@@ -54,5 +56,6 @@ enum dell_laptop_notifier_actions {
 int dell_laptop_register_notifier(struct notifier_block *nb);
 int dell_laptop_unregister_notifier(struct notifier_block *nb);
 void dell_laptop_call_notifier(unsigned long action, void *data);
+int dell_wmi_check_descriptor_buffer(struct wmi_device *wdev, u32 *version);
 
 #endif
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index e8b4d412eabc..e7011792127f 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -46,7 +46,6 @@ MODULE_DESCRIPTION("Dell laptop WMI hotkeys driver");
 MODULE_LICENSE("GPL");
 
 #define DELL_EVENT_GUID "9DBB5994-A997-11DA-B012-B622A1EF5492"
-#define DELL_DESCRIPTOR_GUID "8D9DDCBC-A997-11DA-B012-B622A1EF5492"
 
 static bool wmi_requires_smbios_request;
 
@@ -617,78 +616,6 @@ static void dell_wmi_input_destroy(struct wmi_device *wdev)
 	input_unregister_device(priv->input_dev);
 }
 
-/*
- * Descriptor buffer is 128 byte long and contains:
- *
- *       Name             Offset  Length  Value
- * Vendor Signature          0       4    "DELL"
- * Object Signature          4       4    " WMI"
- * WMI Interface Version     8       4    <version>
- * WMI buffer length        12       4    4096
- */
-static int dell_wmi_check_descriptor_buffer(struct wmi_device *wdev)
-{
-	struct dell_wmi_priv *priv = dev_get_drvdata(&wdev->dev);
-	union acpi_object *obj = NULL;
-	struct wmi_device *desc_dev;
-	u32 *buffer;
-	int ret;
-
-	desc_dev = wmidev_get_other_guid(wdev, DELL_DESCRIPTOR_GUID);
-	if (!desc_dev) {
-		dev_err(&wdev->dev, "Dell WMI descriptor does not exist\n");
-		return -ENODEV;
-	}
-
-	obj = wmidev_block_query(desc_dev, 0);
-	if (!obj) {
-		dev_err(&wdev->dev, "failed to read Dell WMI descriptor\n");
-		ret = -EIO;
-		goto out;
-	}
-
-	if (obj->type != ACPI_TYPE_BUFFER) {
-		dev_err(&wdev->dev, "Dell descriptor has wrong type\n");
-		ret = -EINVAL;
-		goto out;
-	}
-
-	if (obj->buffer.length != 128) {
-		dev_err(&wdev->dev,
-			"Dell descriptor buffer has invalid length (%d)\n",
-			obj->buffer.length);
-		if (obj->buffer.length < 16) {
-			ret = -EINVAL;
-			goto out;
-		}
-	}
-
-	buffer = (u32 *)obj->buffer.pointer;
-
-	if (buffer[0] != 0x4C4C4544 && buffer[1] != 0x494D5720)
-		dev_warn(&wdev->dev, "Dell descriptor buffer has invalid signature (%*ph)\n",
-			8, buffer);
-
-	if (buffer[2] != 0 && buffer[2] != 1)
-		dev_warn(&wdev->dev, "Dell descriptor buffer has unknown version (%d)\n",
-			buffer[2]);
-
-	if (buffer[3] != 4096)
-		dev_warn(&wdev->dev, "Dell descriptor buffer has invalid buffer length (%d)\n",
-			buffer[3]);
-
-	priv->interface_version = buffer[2];
-	ret = 0;
-
-	dev_info(&wdev->dev, "Detected Dell WMI interface version %u\n",
-		priv->interface_version);
-
-out:
-	kfree(obj);
-	put_device(&desc_dev->dev);
-	return ret;
-}
-
 /*
  * According to Dell SMBIOS documentation:
  *
@@ -732,7 +659,7 @@ static int dell_wmi_probe(struct wmi_device *wdev)
 		return -ENOMEM;
 	dev_set_drvdata(&wdev->dev, priv);
 
-	err = dell_wmi_check_descriptor_buffer(wdev);
+	err = dell_wmi_check_descriptor_buffer(wdev, &priv->interface_version);
 	if (err)
 		return err;
 
-- 
2.14.1

[PATCH 08/12] platform/x86: wmi: Cleanup exit routine in reverse order of init

[Mario Limonciello]

The initialize routine is:
* class -> bus -> platform

The exit routine is:
* platform -> class -> bus

Fix the exit routine to be:
* platform -> bus -> class

Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
---
 drivers/platform/x86/wmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index 0765b1797d4c..077a9b7459ef 100644
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -1264,8 +1264,8 @@ static int __init acpi_wmi_init(void)
 static void __exit acpi_wmi_exit(void)
 {
 	platform_driver_unregister(&acpi_wmi_driver);
-	class_unregister(&wmi_bus_class);
 	bus_unregister(&wmi_bus_type);
+	class_unregister(&wmi_bus_class);
 }
 
 subsys_initcall(acpi_wmi_init);
-- 
2.14.1

[PATCH 09/12] platform/x86: wmi: create character devices when requested by drivers

[Mario Limonciello]

For WMI operations that are only Set or Query read or write sysfs
attributes created by WMI vendor drivers make sense.

For other WMI operations that are run on Method, there needs to be a
way to guarantee to userspace that the results from the method call
belong to the data request to the method call.  Sysfs attributes don't
work well in this scenario because two userspace processes may be
competing at reading/writing an attribute and step on each other's
data.

When a WMI vendor driver declares a set of functions in a
file_operations object the WMI bus driver will create a character
device that maps to those file operations.

The WMI vendor drivers will be responsible for managing access to
this character device and proper locking on it.

When a WMI vendor driver is unloaded the WMI bus driver will clean
up the character device.

Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
---
 drivers/platform/x86/wmi.c | 98 +++++++++++++++++++++++++++++++++++++++++++---
 include/linux/wmi.h        |  1 +
 2 files changed, 94 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index 077a9b7459ef..d1e128864d24 100644
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -44,12 +44,17 @@
 #include <linux/platform_device.h>
 #include <linux/wmi.h>
 #include <linux/uuid.h>
+#include <linux/cdev.h>
+#include <linux/idr.h>
 
 ACPI_MODULE_NAME("wmi");
 MODULE_AUTHOR("Carlos Corbacho");
 MODULE_DESCRIPTION("ACPI-WMI Mapping Driver");
 MODULE_LICENSE("GPL");
 
+#define WMI_MAX_DEVS  MINORMASK
+static DEFINE_IDR(wmi_idr);
+static DEFINE_MUTEX(wmi_minor_lock);
 static LIST_HEAD(wmi_block_list);
 
 struct guid_block {
@@ -69,6 +74,8 @@ struct wmi_block {
 	struct wmi_device dev;
 	struct list_head list;
 	struct guid_block gblock;
+	struct cdev *cdev;
+	int minor;
 	struct acpi_device *acpi_device;
 	wmi_notify_handler handler;
 	void *handler_data;
@@ -86,6 +93,7 @@ struct wmi_block {
 #define ACPI_WMI_STRING      0x4	/* GUID takes & returns a string */
 #define ACPI_WMI_EVENT       0x8	/* GUID is an event */
 
+static dev_t wmi_devt;
 static bool debug_event;
 module_param(debug_event, bool, 0444);
 MODULE_PARM_DESC(debug_event,
@@ -762,21 +770,88 @@ static int wmi_dev_match(struct device *dev, struct device_driver *driver)
 	return 0;
 }
 
+static struct class wmi_bus_class = {
+	.name = "wmi_bus",
+};
+
+static int wmi_minor_get(struct wmi_block *wblock)
+{
+	int ret;
+
+	mutex_lock(&wmi_minor_lock);
+	ret = idr_alloc(&wmi_idr, wblock, 0, WMI_MAX_DEVS, GFP_KERNEL);
+	if (ret >= 0)
+		wblock->minor = ret;
+	else if (ret == -ENOSPC)
+		dev_err(&wblock->dev.dev, "too many wmi devices\n");
+
+	mutex_unlock(&wmi_minor_lock);
+	return ret;
+}
+
+static void wmi_minor_free(struct wmi_block *wblock)
+{
+	mutex_lock(&wmi_minor_lock);
+	idr_remove(&wmi_idr, wblock->minor);
+	mutex_unlock(&wmi_minor_lock);
+}
+
+
 static int wmi_dev_probe(struct device *dev)
 {
 	struct wmi_block *wblock = dev_to_wblock(dev);
 	struct wmi_driver *wdriver =
 		container_of(dev->driver, struct wmi_driver, driver);
-	int ret = 0;
+	struct device *clsdev;
+	int ret = 0, devno;
 
 	if (ACPI_FAILURE(wmi_method_enable(wblock, 1)))
 		dev_warn(dev, "failed to enable device -- probing anyway\n");
 
+	/* driver wants a character device made */
+	if (wdriver->file_operations) {
+		dev->devt = wmi_devt;
+		wblock->cdev = cdev_alloc();
+		if (!wblock->cdev) {
+			dev_err(dev, "failed to allocate cdev\n");
+			return -ENOMEM;
+		}
+		cdev_init(wblock->cdev, wdriver->file_operations);
+		wblock->cdev->owner = wdriver->file_operations->owner;
+		ret = wmi_minor_get(wblock);
+		if (ret < 0)
+			return ret;
+		devno = MKDEV(MAJOR(wmi_devt), wblock->minor);
+		ret = cdev_add(wblock->cdev, devno, 1);
+		if (ret) {
+			dev_err(dev, "unable to create device %d:%d\n",
+			MAJOR(wmi_devt), wblock->minor);
+			goto err_probe_cdev;
+		}
+		clsdev = device_create(&wmi_bus_class, dev,
+				       MKDEV(MAJOR(wmi_devt), wblock->minor),
+				       NULL, "wmi-%s", wdriver->driver.name);
+
+		if (IS_ERR(clsdev)) {
+			dev_err(dev, "unable to create device %d:%d\n",
+			MAJOR(wmi_devt), wblock->minor);
+			ret = PTR_ERR(clsdev);
+			goto err_probe_class;
+		}
+	}
+
 	if (wdriver->probe) {
 		ret = wdriver->probe(dev_to_wdev(dev));
 		if (ret != 0 && ACPI_FAILURE(wmi_method_enable(wblock, 0)))
 			dev_warn(dev, "failed to disable device\n");
 	}
+	return ret;
+
+err_probe_class:
+	cdev_del(wblock->cdev);
+
+err_probe_cdev:
+	wmi_minor_free(wblock);
 
 	return ret;
 }
@@ -788,6 +863,13 @@ static int wmi_dev_remove(struct device *dev)
 		container_of(dev->driver, struct wmi_driver, driver);
 	int ret = 0;
 
+	if (wdriver->file_operations) {
+		device_destroy(&wmi_bus_class,
+			       MKDEV(MAJOR(wmi_devt), wblock->minor));
+		cdev_del(wblock->cdev);
+		wmi_minor_free(wblock);
+	}
+
 	if (wdriver->remove)
 		ret = wdriver->remove(dev_to_wdev(dev));
 
@@ -797,10 +879,6 @@ static int wmi_dev_remove(struct device *dev)
 	return ret;
 }
 
-static struct class wmi_bus_class = {
-	.name = "wmi_bus",
-};
-
 static struct bus_type wmi_bus_type = {
 	.name = "wmi",
 	.dev_groups = wmi_groups,
@@ -1250,8 +1328,17 @@ static int __init acpi_wmi_init(void)
 		goto err_unreg_bus;
 	}
 
+	error = alloc_chrdev_region(&wmi_devt, 0, WMI_MAX_DEVS, "wmi");
+	if (error < 0) {
+		pr_err("unable to allocate char dev region\n");
+		goto err_unreg_platform;
+	}
+
 	return 0;
 
+err_unreg_platform:
+	platform_driver_unregister(&acpi_wmi_driver);
+
 err_unreg_bus:
 	bus_unregister(&wmi_bus_type);
 
@@ -1263,6 +1350,7 @@ static int __init acpi_wmi_init(void)
 
 static void __exit acpi_wmi_exit(void)
 {
+	unregister_chrdev_region(wmi_devt, WMI_MAX_DEVS);
 	platform_driver_unregister(&acpi_wmi_driver);
 	bus_unregister(&wmi_bus_type);
 	class_unregister(&wmi_bus_class);
diff --git a/include/linux/wmi.h b/include/linux/wmi.h
index cd0d7734dc49..6899ddb6cd30 100644
--- a/include/linux/wmi.h
+++ b/include/linux/wmi.h
@@ -41,6 +41,7 @@ struct wmi_device_id {
 struct wmi_driver {
 	struct device_driver driver;
 	const struct wmi_device_id *id_table;
+	const struct file_operations *file_operations;
 
 	int (*probe)(struct wmi_device *wdev);
 	int (*remove)(struct wmi_device *wdev);
-- 
2.14.1

[PATCH 10/12] platform/x86: wmi: destroy on cleanup rather than unregister

[Mario Limonciello]

device_create documentation says to cleanup using device_destroy

Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
---
 drivers/platform/x86/wmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index d1e128864d24..84314c0ef9c2 100644
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -1223,7 +1223,7 @@ static int acpi_wmi_remove(struct platform_device *device)
 	acpi_remove_address_space_handler(acpi_device->handle,
 				ACPI_ADR_SPACE_EC, &acpi_wmi_ec_space_handler);
 	wmi_free_devices(acpi_device);
-	device_unregister((struct device *)dev_get_drvdata(&device->dev));
+	device_destroy(&wmi_bus_class, MKDEV(0, 0));
 
 	return 0;
 }
@@ -1277,7 +1277,7 @@ static int acpi_wmi_probe(struct platform_device *device)
 	return 0;
 
 err_remove_busdev:
-	device_unregister(wmi_bus_dev);
+	device_destroy(&wmi_bus_class, MKDEV(0, 0));
 
 err_remove_notify_handler:
 	acpi_remove_notify_handler(acpi_device->handle, ACPI_DEVICE_NOTIFY,
-- 
2.14.1

[PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character device for userspace

[Mario Limonciello]

This userspace character device will be used to perform SMBIOS calls
from any applications sending a properly formatted 4k calling interface
buffer.

This character device is intended to deprecate the dcdbas kernel module
and the interface that it provides to userspace.

It's important for the driver to provide a R/W ioctl to ensure that
two competing userspace processes don't race to provide or read each
others data.

Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
---
 Documentation/ABI/testing/dell-wmi-smbios |  19 ++++++
 drivers/platform/x86/dell-wmi-smbios.c    | 108 ++++++++++++++++++++++++++----
 drivers/platform/x86/dell-wmi-smbios.h    |   5 ++
 3 files changed, 120 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/ABI/testing/dell-wmi-smbios

diff --git a/Documentation/ABI/testing/dell-wmi-smbios b/Documentation/ABI/testing/dell-wmi-smbios
new file mode 100644
index 000000000000..54dcf73b3031
--- /dev/null
+++ b/Documentation/ABI/testing/dell-wmi-smbios
@@ -0,0 +1,19 @@
+What:		/dev/wmi-dell-wmi-smbios
+Date:		October 2017
+KernelVersion:	4.15
+Contact:	"Mario Limonciello" <mario.limonciello@dell.com>
+Description:
+		Perform an SMBIOS call on a supported Dell machine
+		through the Dell ACPI-WMI interface.
+
+		To make a call prepare a 4k buffer like this:
+		struct buffer {
+			u16 class;
+			u16 select;
+			u32 input[4];
+			u32 output[4];
+			u8 data[4060];
+		} __packed;
+
+		Perform this RW IOCTL to get the result:
+		_IOWR('D', 0, struct calling_interface_buffer)
diff --git a/drivers/platform/x86/dell-wmi-smbios.c b/drivers/platform/x86/dell-wmi-smbios.c
index 9deb851ff517..22e47fba6a59 100644
--- a/drivers/platform/x86/dell-wmi-smbios.c
+++ b/drivers/platform/x86/dell-wmi-smbios.c
@@ -21,6 +21,7 @@
 #include <linux/err.h>
 #include <linux/mutex.h>
 #include <linux/wmi.h>
+#include <linux/uaccess.h>
 #include "dell-wmi-smbios.h"
 
 #define DELL_WMI_SMBIOS_GUID "A80593CE-A997-11DA-B012-B622A1EF5492"
@@ -34,7 +35,8 @@ struct calling_interface_structure {
 	struct calling_interface_token tokens[];
 } __packed;
 
-static struct calling_interface_buffer *buffer;
+static struct calling_interface_buffer *internal_buffer;
+static struct calling_interface_buffer *sysfs_buffer;
 static DEFINE_MUTEX(buffer_mutex);
 
 static int da_command_address;
@@ -61,13 +63,13 @@ struct calling_interface_buffer *dell_smbios_get_buffer(void)
 {
 	mutex_lock(&buffer_mutex);
 	dell_smbios_clear_buffer();
-	return buffer;
+	return internal_buffer;
 }
 EXPORT_SYMBOL_GPL(dell_smbios_get_buffer);
 
 void dell_smbios_clear_buffer(void)
 {
-	memset(buffer, 0, sizeof(struct calling_interface_buffer));
+	memset(internal_buffer, 0, sizeof(struct calling_interface_buffer));
 }
 EXPORT_SYMBOL_GPL(dell_smbios_clear_buffer);
 
@@ -107,9 +109,9 @@ int run_wmi_smbios_call(struct calling_interface_buffer *buffer)
 
 void dell_smbios_send_request(int class, int select)
 {
-	buffer->class = class;
-	buffer->select = select;
-	run_wmi_smbios_call(buffer);
+	internal_buffer->class = class;
+	internal_buffer->select = select;
+	run_wmi_smbios_call(internal_buffer);
 }
 EXPORT_SYMBOL_GPL(dell_smbios_send_request);
 
@@ -218,6 +220,68 @@ static const struct attribute_group smbios_attribute_group = {
 	.attrs = smbios_attrs,
 };
 
+static int dell_wmi_smbios_open(struct inode *inode, struct file *file)
+{
+	return nonseekable_open(inode, file);
+}
+
+static int dell_wmi_smbios_release(struct inode *inode, struct file *file)
+{
+	return 0;
+}
+
+static ssize_t dell_wmi_smbios_read(struct file *file, char __user *data,
+				   size_t len, loff_t *ppos)
+{
+	ssize_t size = sizeof(struct calling_interface_buffer);
+	void *src;
+
+	if (*ppos >= size)
+		return 0;
+	if (len >= size)
+		len = size;
+	if (*ppos + len > size)
+		len = size - *ppos;
+	src = (void __force *) (sysfs_buffer + *ppos);
+	if (copy_to_user(data, src, len))
+		return -EFAULT;
+
+	*ppos += len;
+	return len;
+}
+
+static long dell_wmi_smbios_ioctl(struct file *filp, unsigned int cmd,
+	unsigned long arg)
+{
+	int ret = 0;
+	size_t size;
+
+	if (_IOC_TYPE(cmd) != DELL_WMI_SMBIOS_IOC)
+		return -ENOTTY;
+
+	switch (cmd) {
+	case DELL_WMI_SMBIOS_CMD:
+		size = sizeof(struct calling_interface_buffer);
+		mutex_lock(&buffer_mutex);
+		if (copy_from_user(sysfs_buffer, (void __user *) arg, size)) {
+			ret = -EFAULT;
+			goto fail_smbios_cmd;
+		}
+		ret = run_wmi_smbios_call(sysfs_buffer);
+		if (ret != 0)
+			goto fail_smbios_cmd;
+		if (copy_to_user((void __user *) arg, sysfs_buffer, size))
+			ret = -EFAULT;
+fail_smbios_cmd:
+		mutex_unlock(&buffer_mutex);
+		break;
+	default:
+		pr_err("unsupported ioctl: %d.\n", cmd);
+		ret = -ENOIOCTLCMD;
+	}
+	return ret;
+}
+
 /*
  * Descriptor buffer is 128 byte long and contains:
  *
@@ -306,12 +370,19 @@ static int dell_wmi_smbios_probe(struct wmi_device *wdev)
 	if (ret)
 		return ret;
 
-	buffer = (void *)__get_free_page(GFP_KERNEL);
-	if (!buffer) {
+	internal_buffer = (void *)__get_free_page(GFP_KERNEL);
+	if (!internal_buffer) {
 		ret = -ENOMEM;
-		goto fail_buffer;
+		goto fail_internal_buffer;
 	}
 
+	sysfs_buffer = (void *)__get_free_page(GFP_KERNEL);
+	if (!sysfs_buffer) {
+		ret = -ENOMEM;
+		goto fail_sysfs_buffer;
+	}
+	memset(sysfs_buffer, 0, sizeof(struct calling_interface_buffer));
+
 	ret = sysfs_create_group(&wdev->dev.kobj, &smbios_attribute_group);
 	if (ret)
 		goto fail_create_group;
@@ -320,9 +391,12 @@ static int dell_wmi_smbios_probe(struct wmi_device *wdev)
 	return 0;
 
 fail_create_group:
-	free_page((unsigned long)buffer);
+	free_page((unsigned long)sysfs_buffer);
 
-fail_buffer:
+fail_sysfs_buffer:
+	free_page((unsigned long)internal_buffer);
+
+fail_internal_buffer:
 	kfree(da_tokens);
 	return ret;
 }
@@ -331,7 +405,8 @@ static int dell_wmi_smbios_remove(struct wmi_device *wdev)
 {
 	sysfs_remove_group(&wdev->dev.kobj, &smbios_attribute_group);
 	kfree(da_tokens);
-	free_page((unsigned long)buffer);
+	free_page((unsigned long)internal_buffer);
+	free_page((unsigned long)sysfs_buffer);
 	kobject_uevent(&wdev->dev.kobj, KOBJ_CHANGE);
 	return 0;
 }
@@ -341,6 +416,14 @@ static const struct wmi_device_id dell_wmi_smbios_id_table[] = {
 	{ },
 };
 
+static const struct file_operations dell_wmi_smbios_fops = {
+	.owner		= THIS_MODULE,
+	.read		= dell_wmi_smbios_read,
+	.unlocked_ioctl	= dell_wmi_smbios_ioctl,
+	.open		= dell_wmi_smbios_open,
+	.release	= dell_wmi_smbios_release,
+};
+
 static struct wmi_driver dell_wmi_smbios_driver = {
 	.driver = {
 		.name = "dell-wmi-smbios",
@@ -348,6 +431,7 @@ static struct wmi_driver dell_wmi_smbios_driver = {
 	.probe = dell_wmi_smbios_probe,
 	.remove = dell_wmi_smbios_remove,
 	.id_table = dell_wmi_smbios_id_table,
+	.file_operations = &dell_wmi_smbios_fops,
 };
 module_wmi_driver(dell_wmi_smbios_driver);
 
diff --git a/drivers/platform/x86/dell-wmi-smbios.h b/drivers/platform/x86/dell-wmi-smbios.h
index 0521ec5d437b..b8215eb879b2 100644
--- a/drivers/platform/x86/dell-wmi-smbios.h
+++ b/drivers/platform/x86/dell-wmi-smbios.h
@@ -18,6 +18,7 @@
 #define _DELL_WMI_SMBIOS_H_
 
 #include <linux/wmi.h>
+#include <linux/ioctl.h>
 
 struct notifier_block;
 
@@ -40,6 +41,10 @@ struct calling_interface_token {
 	};
 };
 
+#define DELL_WMI_SMBIOS_IOC   'D'
+#define DELL_WMI_SMBIOS_CMD   _IOWR(DELL_WMI_SMBIOS_IOC, 0, \
+				   struct calling_interface_buffer)
+
 int dell_smbios_error(int value);
 
 struct calling_interface_buffer *dell_smbios_get_buffer(void);
-- 
2.14.1

[PATCH 12/12] platform/x86: Kconfig: Change the default settings for dell-wmi-smbios

[Mario Limonciello]

The dell-wmi-smbios driver should be enabled by default when ACPI_WMI
is enabled (like many other WMI drivers).

Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
---
 drivers/platform/x86/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index a70bcd8caa72..4f9ca51b1968 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -94,6 +94,7 @@ config ASUS_LAPTOP
 config DELL_WMI_SMBIOS
 	tristate "Dell WMI SMBIOS calling interface"
 	depends on ACPI_WMI
+	default ACPI_WMI
 	---help---
 	This module provides common functions for kernel modules using
 	Dell SMBIOS over ACPI-WMI.
-- 
2.14.1

Re: [PATCH 03/12] platform/x86: dell-smbios: Add pr_fmt definition to driver

[Andy Shevchenko]

On Thu, Sep 21, 2017 at 4:57 PM, Mario Limonciello
<mario.limonciello@dell.com> wrote:

We need a (formal) commit message even for simple patches.

> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 07/12] platform/x86: dell-wmi-smbios: Use Dell WMI descriptor check

[Andy Shevchenko]

On Thu, Sep 21, 2017 at 4:57 PM, Mario Limonciello
<mario.limonciello@dell.com> wrote:
> The Dell WMI descriptor check is used as an indication that WMI
> calls are safe to run both when used with the notification
> ASL/GUID pair as well as the SMBIOS calling ASL/GUID pair.
>
> As some code in dell-wmi-smbios is already a prerequisite for
> dell-wmi, move the code for performing the descriptor check into
> dell-wmi-smbios and let both drivers use it from there.

> +       desc_buffer = (u32 *)obj->buffer.pointer;
> +

> +       if (desc_buffer[0] != 0x4C4C4544 && desc_buffer[1] != 0x494D5720)

I was thinking about strncmp() here for a full line, though decide not
to push it anyhow. Those IDs is binary data, can be anything and you
have comment of what is expected here.

But I think it would be nice to create a separate definitions and make
comments there.

> +               dev_warn(&wdev->dev, "Dell descriptor buffer has invalid signature (%*ph)\n",
> +                       8, desc_buffer);

%8ph ?

> +
> +       if (desc_buffer[2] != 0 && desc_buffer[2] != 1)
> +               dev_warn(&wdev->dev, "Dell descriptor buffer has unknown version (%d)\n",
> +                       desc_buffer[2]);

%u ? u32 can't be negative and you basically allow it.

> +
> +       if (desc_buffer[3] != 4096)
> +               dev_warn(&wdev->dev, "Dell descriptor buffer has invalid buffer length (%d)\n",
> +                       desc_buffer[3]);

Ditto.


P.S. I noticed this all in old code, so, you can address my comments
in a separate patch if you find them useful.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 09/12] platform/x86: wmi: create character devices when requested by drivers

[Andy Shevchenko]

On Thu, Sep 21, 2017 at 4:57 PM, Mario Limonciello
<mario.limonciello@dell.com> wrote:
> For WMI operations that are only Set or Query read or write sysfs
> attributes created by WMI vendor drivers make sense.
>
> For other WMI operations that are run on Method, there needs to be a
> way to guarantee to userspace that the results from the method call
> belong to the data request to the method call.  Sysfs attributes don't
> work well in this scenario because two userspace processes may be
> competing at reading/writing an attribute and step on each other's
> data.
>
> When a WMI vendor driver declares a set of functions in a
> file_operations object the WMI bus driver will create a character
> device that maps to those file operations.
>
> The WMI vendor drivers will be responsible for managing access to
> this character device and proper locking on it.
>
> When a WMI vendor driver is unloaded the WMI bus driver will clean
> up the character device.
>

> @@ -44,12 +44,17 @@
>  #include <linux/platform_device.h>
>  #include <linux/wmi.h>
>  #include <linux/uuid.h>
> +#include <linux/cdev.h>
> +#include <linux/idr.h>

Keep alphabetical ordering.


-- 
With Best Regards,
Andy Shevchenko

RE: [PATCH 09/12] platform/x86: wmi: create character devices when requested by drivers

[Mario.Limonciello]

> -----Original Message-----
> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Sent: Thursday, September 21, 2017 11:47 AM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; Platform Driver
> <platform-driver-x86@vger.kernel.org>; quasisec@google.com; Pali Rohár
> <pali.rohar@gmail.com>
> Subject: Re: [PATCH 09/12] platform/x86: wmi: create character devices when
> requested by drivers
> 
> On Thu, Sep 21, 2017 at 4:57 PM, Mario Limonciello
> <mario.limonciello@dell.com> wrote:
> > For WMI operations that are only Set or Query read or write sysfs
> > attributes created by WMI vendor drivers make sense.
> >
> > For other WMI operations that are run on Method, there needs to be a
> > way to guarantee to userspace that the results from the method call
> > belong to the data request to the method call.  Sysfs attributes don't
> > work well in this scenario because two userspace processes may be
> > competing at reading/writing an attribute and step on each other's
> > data.
> >
> > When a WMI vendor driver declares a set of functions in a
> > file_operations object the WMI bus driver will create a character
> > device that maps to those file operations.
> >
> > The WMI vendor drivers will be responsible for managing access to
> > this character device and proper locking on it.
> >
> > When a WMI vendor driver is unloaded the WMI bus driver will clean
> > up the character device.
> >
> 
> > @@ -44,12 +44,17 @@
> >  #include <linux/platform_device.h>
> >  #include <linux/wmi.h>
> >  #include <linux/uuid.h>
> > +#include <linux/cdev.h>
> > +#include <linux/idr.h>
> 
> Keep alphabetical ordering.
> 

The existing list wasn't in alphabetical order.  I'll submit a patch in v2 earlier
in the series to sort and then put them in the right place for my patch.

RE: [PATCH 09/12] platform/x86: wmi: create character devices when requested by drivers

[Mario.Limonciello]

> -----Original Message-----
> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Sent: Thursday, September 21, 2017 11:47 AM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; Platform Driver
> <platform-driver-x86@vger.kernel.org>; quasisec@google.com; Pali Rohár
> <pali.rohar@gmail.com>
> Subject: Re: [PATCH 09/12] platform/x86: wmi: create character devices when
> requested by drivers
> 
> On Thu, Sep 21, 2017 at 4:57 PM, Mario Limonciello
> <mario.limonciello@dell.com> wrote:
> > For WMI operations that are only Set or Query read or write sysfs
> > attributes created by WMI vendor drivers make sense.
> >
> > For other WMI operations that are run on Method, there needs to be a
> > way to guarantee to userspace that the results from the method call
> > belong to the data request to the method call.  Sysfs attributes don't
> > work well in this scenario because two userspace processes may be
> > competing at reading/writing an attribute and step on each other's
> > data.
> >
> > When a WMI vendor driver declares a set of functions in a
> > file_operations object the WMI bus driver will create a character
> > device that maps to those file operations.
> >
> > The WMI vendor drivers will be responsible for managing access to
> > this character device and proper locking on it.
> >
> > When a WMI vendor driver is unloaded the WMI bus driver will clean
> > up the character device.
> >
> 
> > @@ -44,12 +44,17 @@
> >  #include <linux/platform_device.h>
> >  #include <linux/wmi.h>
> >  #include <linux/uuid.h>
> > +#include <linux/cdev.h>
> > +#include <linux/idr.h>
> 
> Keep alphabetical ordering.
> 

The existing list wasn't in alphabetical order.  I'll submit a patch in v2 earlier
in the series to sort and then put them in the right place for my patch.

RE: [PATCH 07/12] platform/x86: dell-wmi-smbios: Use Dell WMI descriptor check

[Mario.Limonciello]

> -----Original Message-----
> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Sent: Thursday, September 21, 2017 11:44 AM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; Platform Driver
> <platform-driver-x86@vger.kernel.org>; quasisec@google.com; Pali Rohár
> <pali.rohar@gmail.com>
> Subject: Re: [PATCH 07/12] platform/x86: dell-wmi-smbios: Use Dell WMI
> descriptor check
> 
> On Thu, Sep 21, 2017 at 4:57 PM, Mario Limonciello
> <mario.limonciello@dell.com> wrote:
> > The Dell WMI descriptor check is used as an indication that WMI
> > calls are safe to run both when used with the notification
> > ASL/GUID pair as well as the SMBIOS calling ASL/GUID pair.
> >
> > As some code in dell-wmi-smbios is already a prerequisite for
> > dell-wmi, move the code for performing the descriptor check into
> > dell-wmi-smbios and let both drivers use it from there.
> 
> > +       desc_buffer = (u32 *)obj->buffer.pointer;
> > +
> 
> > +       if (desc_buffer[0] != 0x4C4C4544 && desc_buffer[1] != 0x494D5720)
> 
> I was thinking about strncmp() here for a full line, though decide not
> to push it anyhow. Those IDs is binary data, can be anything and you
> have comment of what is expected here.
> 
> But I think it would be nice to create a separate definitions and make
> comments there.
> 
> > +               dev_warn(&wdev->dev, "Dell descriptor buffer has invalid signature
> (%*ph)\n",
> > +                       8, desc_buffer);
> 
> %8ph ?
> 
> > +
> > +       if (desc_buffer[2] != 0 && desc_buffer[2] != 1)
> > +               dev_warn(&wdev->dev, "Dell descriptor buffer has unknown version
> (%d)\n",
> > +                       desc_buffer[2]);
> 
> %u ? u32 can't be negative and you basically allow it.
> 
> > +
> > +       if (desc_buffer[3] != 4096)
> > +               dev_warn(&wdev->dev, "Dell descriptor buffer has invalid buffer length
> (%d)\n",
> > +                       desc_buffer[3]);
> 
> Ditto.
> 
> 
> P.S. I noticed this all in old code, so, you can address my comments
> in a separate patch if you find them useful.
> 

Yeah this is all old code.  I've made some adjustments to it in v2 in a completely separate
patch that comes after the patch it's "moved".  I'll submit back after other feedback
to this series.

RE: [PATCH 07/12] platform/x86: dell-wmi-smbios: Use Dell WMI descriptor check

[Mario.Limonciello]

> -----Original Message-----
> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Sent: Thursday, September 21, 2017 11:44 AM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; Platform Driver
> <platform-driver-x86@vger.kernel.org>; quasisec@google.com; Pali Rohár
> <pali.rohar@gmail.com>
> Subject: Re: [PATCH 07/12] platform/x86: dell-wmi-smbios: Use Dell WMI
> descriptor check
> 
> On Thu, Sep 21, 2017 at 4:57 PM, Mario Limonciello
> <mario.limonciello@dell.com> wrote:
> > The Dell WMI descriptor check is used as an indication that WMI
> > calls are safe to run both when used with the notification
> > ASL/GUID pair as well as the SMBIOS calling ASL/GUID pair.
> >
> > As some code in dell-wmi-smbios is already a prerequisite for
> > dell-wmi, move the code for performing the descriptor check into
> > dell-wmi-smbios and let both drivers use it from there.
> 
> > +       desc_buffer = (u32 *)obj->buffer.pointer;
> > +
> 
> > +       if (desc_buffer[0] != 0x4C4C4544 && desc_buffer[1] != 0x494D5720)
> 
> I was thinking about strncmp() here for a full line, though decide not
> to push it anyhow. Those IDs is binary data, can be anything and you
> have comment of what is expected here.
> 
> But I think it would be nice to create a separate definitions and make
> comments there.
> 
> > +               dev_warn(&wdev->dev, "Dell descriptor buffer has invalid signature
> (%*ph)\n",
> > +                       8, desc_buffer);
> 
> %8ph ?
> 
> > +
> > +       if (desc_buffer[2] != 0 && desc_buffer[2] != 1)
> > +               dev_warn(&wdev->dev, "Dell descriptor buffer has unknown version
> (%d)\n",
> > +                       desc_buffer[2]);
> 
> %u ? u32 can't be negative and you basically allow it.
> 
> > +
> > +       if (desc_buffer[3] != 4096)
> > +               dev_warn(&wdev->dev, "Dell descriptor buffer has invalid buffer length
> (%d)\n",
> > +                       desc_buffer[3]);
> 
> Ditto.
> 
> 
> P.S. I noticed this all in old code, so, you can address my comments
> in a separate patch if you find them useful.
> 

Yeah this is all old code.  I've made some adjustments to it in v2 in a completely separate
patch that comes after the patch it's "moved".  I'll submit back after other feedback
to this series.

Re: [PATCH 01/12] platform/x86: dell-wmi: label driver as handling notifications

[Pali Rohár]

On Thursday 21 September 2017 08:57:06 Mario Limonciello wrote:
> This driver serves the purpose of responding to WMI based notifications
> from the DELL_EVENT_GUID (9DBB5994-A997-11DA-B012-B622A1EF5492).
> Other GUIDs will be handled by separate drivers.
> 
> Update the language used by this driver to avoid future confusion.

Hi! I'm not sure if if "notifications" word is better then "extras".
Basically the most important part of the dell-wmi driver is to deliver
key press events via input device.

Has anybody else better word or description for this?

> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
> ---
>  MAINTAINERS                  | 2 +-
>  drivers/platform/x86/Kconfig | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2281af4b41b6..5d8ea24a8ee7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3996,7 +3996,7 @@ S:	Maintained
>  F:	Documentation/dcdbas.txt
>  F:	drivers/firmware/dcdbas.*
>  
> -DELL WMI EXTRAS DRIVER
> +DELL WMI NOTIFICATIONS DRIVER
>  M:	Matthew Garrett <mjg59@srcf.ucam.org>
>  M:	Pali Rohár <pali.rohar@gmail.com>
>  S:	Maintained
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index 80b87954f6dd..9e52f05daa2e 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -116,7 +116,7 @@ config DELL_LAPTOP
>  	laptops (except for some models covered by the Compal driver).
>  
>  config DELL_WMI
> -	tristate "Dell WMI extras"
> +	tristate "Dell WMI notifications"
>  	depends on ACPI_WMI
>  	depends on DMI
>  	depends on INPUT

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH 02/12] platform/x86: dell-wmi: Don't match on descriptor GUID modalias

[Pali Rohár]

On Thursday 21 September 2017 08:57:07 Mario Limonciello wrote:
> The descriptor GUID is not used to indicate that WMI notifications
> in the dell-wmi driver work properly.  As such a modalias should
> not be present that causes this driver to load on systems with this
> GUID.

Ok, understood. What we need there is to load driver in case both
aliases are present in system. But I have no idea if kernel supports
such logic. So, add my:

Reviewed-by: Pali Rohár <pali.rohar@gmail.com>

> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
> ---
>  drivers/platform/x86/dell-wmi.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
> index 28d9f8696081..1fbef560ca67 100644
> --- a/drivers/platform/x86/dell-wmi.c
> +++ b/drivers/platform/x86/dell-wmi.c
> @@ -51,7 +51,6 @@ MODULE_LICENSE("GPL");
>  static bool wmi_requires_smbios_request;
>  
>  MODULE_ALIAS("wmi:"DELL_EVENT_GUID);
> -MODULE_ALIAS("wmi:"DELL_DESCRIPTOR_GUID);
>  
>  struct dell_wmi_priv {
>  	struct input_dev *input_dev;

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH 03/12] platform/x86: dell-smbios: Add pr_fmt definition to driver

[Pali Rohár]

On Thursday 21 September 2017 08:57:08 Mario Limonciello wrote:
> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
> ---
>  drivers/platform/x86/dell-smbios.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/platform/x86/dell-smbios.c b/drivers/platform/x86/dell-smbios.c
> index 0a5723468bff..e9b1ca07c872 100644
> --- a/drivers/platform/x86/dell-smbios.c
> +++ b/drivers/platform/x86/dell-smbios.c
> @@ -12,6 +12,7 @@
>   *  it under the terms of the GNU General Public License version 2 as
>   *  published by the Free Software Foundation.
>   */
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>  
>  #include <linux/kernel.h>
>  #include <linux/module.h>

After fixing Andy's comment, you can add my

Reviewed-by: Pali Rohár <pali.rohar@gmail.com>

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI

[Pali Rohár]

On Thursday 21 September 2017 08:57:05 Mario Limonciello wrote:
> The existing way that the dell-smbios helper module and associated
> other drivers (dell-laptop, dell-wmi) communicate with the platform
> really isn't secure.  It requires creating a buffer in physical
> DMA32 memory space and passing that to the platform via SMM.
> 
> Since the platform got a physical memory pointer, you've just got
> to trust that the platform has only modified (and accessed) memory
> within that buffer.

And what is the problem? The whole memory management is done by kernel
itself, so you already need to trust it.

> Dell Platform designers recognize this security risk and offer a
> safer way to communicate with the platform over ACPI.  This is
> in turn exposed via a WMI interface to the OS.

Hm... I cannot understand how some proprietary ACPI bytecode interpreted
by kernel can be safer as kernel code itself.

Can you describe more details about this security risk?

> When communicating over WMI-ACPI the communication doesn't occur
> with physical memory pointers.  When the ASL is invoked, the fixed
> length ACPI buffer is copied to a small operating region.  The ASL
> will invoke the SMI, and SMM will only have access to this operating
> region.  When the ASL returns the buffer is copied back for the OS
> to process.

If problem is in current kernel implementation, then it can be fixed.

I'm not against using new WMI communication, but I cannot understand how
kernel code itself is less safer as some other code which is interpreted
by kernel. It does not make sense for me.

> This method of communication should also deprecate the usage of the
> dcdbas kernel module and software dependent upon it's interface.
> Instead offer a syfs interface for communicating with this ASL
> method to allow userspace to use instead.
> 
> To faciliate that needs for userspace and kernel space this patch
> series introduces a generic way for WMI drivers to be able to
> create character devices through the WMI bus when desired.
> Requiring WMI drivers to explictly ask for this functionality will
> act as an effective vendor whitelist.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI interface

[Pali Rohár]

On Thursday 21 September 2017 08:57:09 Mario Limonciello wrote:
> The driver currently uses an SMI interface which grants direct access
> to physical memory to the platform via a pointer.
> 
> Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
> for a buffer of data storage when platform calls are performed.
> 
> This is a safer approach to use in kernel drivers as the platform will
> only have access to that OperationRegion.

In my opinion direct access is safer then using ACPI wrapper for same
functionality.

Anyway, this change would break support for laptops without ACPI-WMI
functionality. IIRC I read in some Dell ACPI-WMI documentation that Dell
SMM via ACPI-WMI is not supported on all machines (probably older
machines) and it is needed to check some vendor bit in DMI data if Dell
SMM ACPI-WMI is really supported.

In linux kernel we do not want to remove support for older machines,
just because machines with new firmware can use also different new
communication method/protocol.

> As a result, this change removes the dependency on this driver on the
> dcdbas kernel module.
> 
> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
> ---
>  drivers/platform/x86/Kconfig       |  8 ++--
>  drivers/platform/x86/dell-smbios.c | 76 ++++++++++++++++++++++++++------------
>  drivers/platform/x86/dell-smbios.h | 11 +++---
>  3 files changed, 63 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index 9e52f05daa2e..81d61c0f4ef8 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -92,13 +92,13 @@ config ASUS_LAPTOP
>  	  If you have an ACPI-compatible ASUS laptop, say Y or M here.
>  
>  config DELL_SMBIOS
> -	tristate
> -	select DCDBAS
> +	tristate "Dell WMI SMBIOS calling interface"
> +	depends on ACPI_WMI
>  	---help---
>  	This module provides common functions for kernel modules using
> -	Dell SMBIOS.
> +	Dell SMBIOS over ACPI-WMI.
>  
> -	If you have a Dell laptop, say Y or M here.
> +	If you have a Dell computer, say Y or M here.
>  
>  config DELL_LAPTOP
>  	tristate "Dell Laptop Extras"
> diff --git a/drivers/platform/x86/dell-smbios.c b/drivers/platform/x86/dell-smbios.c
> index e9b1ca07c872..c06262a89169 100644
> --- a/drivers/platform/x86/dell-smbios.c
> +++ b/drivers/platform/x86/dell-smbios.c
> @@ -4,6 +4,7 @@
>   *  Copyright (c) Red Hat <mjg@redhat.com>
>   *  Copyright (c) 2014 Gabriele Mazzotta <gabriele.mzt@gmail.com>
>   *  Copyright (c) 2014 Pali Rohár <pali.rohar@gmail.com>
> + *  Copyright (c) 2017 Dell Inc.
>   *
>   *  Based on documentation in the libsmbios package:
>   *  Copyright (C) 2005-2014 Dell Inc.
> @@ -18,13 +19,12 @@
>  #include <linux/module.h>
>  #include <linux/dmi.h>
>  #include <linux/err.h>
> -#include <linux/gfp.h>
>  #include <linux/mutex.h>
> -#include <linux/slab.h>
> -#include <linux/io.h>
> -#include "../../firmware/dcdbas.h"
> +#include <linux/wmi.h>
>  #include "dell-smbios.h"
>  
> +#define DELL_WMI_SMBIOS_GUID "A80593CE-A997-11DA-B012-B622A1EF5492"
> +
>  struct calling_interface_structure {
>  	struct dmi_header header;
>  	u16 cmdIOAddress;
> @@ -76,20 +76,39 @@ void dell_smbios_release_buffer(void)
>  }
>  EXPORT_SYMBOL_GPL(dell_smbios_release_buffer);
>  
> -void dell_smbios_send_request(int class, int select)
> +int run_wmi_smbios_call(struct calling_interface_buffer *buffer)
>  {
> -	struct smi_cmd command;
> +	struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
> +	struct acpi_buffer input;
> +	union acpi_object *obj;
> +	acpi_status status;
> +
> +	input.length = sizeof(struct calling_interface_buffer);
> +	input.pointer = buffer;
> +
> +	status = wmi_evaluate_method(DELL_WMI_SMBIOS_GUID,
> +				     0, 1, &input, &output);
> +	if (ACPI_FAILURE(status)) {
> +		pr_err("%x/%x [%x,%x,%x,%x] call failed\n",
> +			buffer->class, buffer->select, buffer->input[0],
> +			buffer->input[1], buffer->input[2], buffer->input[3]);
> +			return -EIO;
> +	}
> +	obj = (union acpi_object *)output.pointer;
> +	if (obj->type != ACPI_TYPE_BUFFER) {
> +		pr_err("invalid type : %d\n", obj->type);
> +		return -EIO;
> +	}
> +	memcpy(buffer, obj->buffer.pointer, input.length);
>  
> -	command.magic = SMI_CMD_MAGIC;
> -	command.command_address = da_command_address;
> -	command.command_code = da_command_code;
> -	command.ebx = virt_to_phys(buffer);
> -	command.ecx = 0x42534931;
> +	return 0;
> +}
>  
> +void dell_smbios_send_request(int class, int select)
> +{
>  	buffer->class = class;
>  	buffer->select = select;
> -
> -	dcdbas_smi_request(&command);
> +	run_wmi_smbios_call(buffer);
>  }
>  EXPORT_SYMBOL_GPL(dell_smbios_send_request);
>  
> @@ -170,7 +189,7 @@ static void __init find_tokens(const struct dmi_header *dm, void *dummy)
>  	}
>  }
>  
> -static int __init dell_smbios_init(void)
> +static int dell_smbios_probe(struct wmi_device *wdev)
>  {
>  	int ret;
>  
> @@ -181,11 +200,7 @@ static int __init dell_smbios_init(void)
>  		return -ENODEV;
>  	}
>  
> -	/*
> -	 * Allocate buffer below 4GB for SMI data--only 32-bit physical addr
> -	 * is passed to SMI handler.
> -	 */
> -	buffer = (void *)__get_free_page(GFP_KERNEL | GFP_DMA32);
> +	buffer = (void *)__get_free_page(GFP_KERNEL);
>  	if (!buffer) {
>  		ret = -ENOMEM;
>  		goto fail_buffer;
> @@ -198,17 +213,32 @@ static int __init dell_smbios_init(void)
>  	return ret;
>  }
>  
> -static void __exit dell_smbios_exit(void)
> +static int dell_smbios_remove(struct wmi_device *wdev)
>  {
>  	kfree(da_tokens);
>  	free_page((unsigned long)buffer);
> +	return 0;
>  }
>  
> -subsys_initcall(dell_smbios_init);
> -module_exit(dell_smbios_exit);
> +static const struct wmi_device_id dell_smbios_id_table[] = {
> +	{ .guid_string = DELL_WMI_SMBIOS_GUID },
> +	{ },
> +};
> +
> +static struct wmi_driver dell_smbios_driver = {
> +	.driver = {
> +		.name = "dell-smbios",
> +	},
> +	.probe = dell_smbios_probe,
> +	.remove = dell_smbios_remove,
> +	.id_table = dell_smbios_id_table,
> +};
> +module_wmi_driver(dell_smbios_driver);
> +
>  
>  MODULE_AUTHOR("Matthew Garrett <mjg@redhat.com>");
>  MODULE_AUTHOR("Gabriele Mazzotta <gabriele.mzt@gmail.com>");
>  MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
> -MODULE_DESCRIPTION("Common functions for kernel modules using Dell SMBIOS");
> +MODULE_AUTHOR("Mario Limonciello <mario.limonciello@dell.com>");
> +MODULE_DESCRIPTION("Common functions for kernel modules using Dell SMBIOS over WMI");
>  MODULE_LICENSE("GPL");
> diff --git a/drivers/platform/x86/dell-smbios.h b/drivers/platform/x86/dell-smbios.h
> index 45cbc2292cd3..e1e29697b362 100644
> --- a/drivers/platform/x86/dell-smbios.h
> +++ b/drivers/platform/x86/dell-smbios.h
> @@ -4,6 +4,7 @@
>   *  Copyright (c) Red Hat <mjg@redhat.com>
>   *  Copyright (c) 2014 Gabriele Mazzotta <gabriele.mzt@gmail.com>
>   *  Copyright (c) 2014 Pali Rohár <pali.rohar@gmail.com>
> + *  Copyright (c) 2017 Dell Inc.
>   *
>   *  Based on documentation in the libsmbios package:
>   *  Copyright (C) 2005-2014 Dell Inc.
> @@ -18,14 +19,14 @@
>  
>  struct notifier_block;
>  
> -/* This structure will be modified by the firmware when we enter
> - * system management mode, hence the volatiles */
> -
>  struct calling_interface_buffer {
>  	u16 class;
>  	u16 select;
> -	volatile u32 input[4];
> -	volatile u32 output[4];
> +	u32 input[4];
> +	u32 output[4];
> +	u32 argattrib;
> +	u32 blength;
> +	u8 data[4052];
>  } __packed;
>  
>  struct calling_interface_token {

-- 
Pali Rohár
pali.rohar@gmail.com

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

[Pali Rohár]

On Thursday 21 September 2017 08:57:11 Mario Limonciello wrote:
> Currently userspace tools can access system tokens via the dcdbas
> kernel module and a SMI call that will cause the platform to execute
> SMM code.
> 
> With a goal in mind of deprecating the dcdbas kernel module a different
> method for accessing these tokens from userspace needs to be created.
> 
> This is intentionally marked to only be readable as root as it can
> contain sensitive information about the platform's configuration.

Darren, Andy, any comments? I'm not quite sure if such API is suitable
for long term in kernel.

Basically tokens are list of tuples <id, location, value> with
possibility to active them, right?

Does not kernel have some better API for it?

Also, keep in mind security aspect of tokens. They represent e.g. boot
order priority or enable/disable some machine peripheral.

> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
> ---
>  .../ABI/testing/sysfs-platform-dell-wmi-smbios     | 16 +++++++++
>  drivers/platform/x86/dell-wmi-smbios.c             | 38 ++++++++++++++++++++++
>  2 files changed, 54 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-wmi-smbios
> 
> diff --git a/Documentation/ABI/testing/sysfs-platform-dell-wmi-smbios b/Documentation/ABI/testing/sysfs-platform-dell-wmi-smbios
> new file mode 100644
> index 000000000000..6d151f2dffba
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-platform-dell-wmi-smbios
> @@ -0,0 +1,16 @@
> +What:		/sys/devices/platform/<platform>/tokens
> +Date:		October 2017
> +KernelVersion:	4.15
> +Contact:	"Mario Limonciello" <mario.limonciello@dell.com>
> +Description:
> +		A read-only description of Dell platform tokens
> +		available on the machine.
> +
> +		The tokens will be displayed in the following
> +		machine readable format with each token on a
> +		new line:
> +
> +		ID @ Location : value
> +
> +		For example token:
> +		5 @ 5 : 3
> diff --git a/drivers/platform/x86/dell-wmi-smbios.c b/drivers/platform/x86/dell-wmi-smbios.c
> index 7f896701fb7b..c3701fdadf7b 100644
> --- a/drivers/platform/x86/dell-wmi-smbios.c
> +++ b/drivers/platform/x86/dell-wmi-smbios.c
> @@ -189,6 +189,34 @@ static void __init find_tokens(const struct dmi_header *dm, void *dummy)
>  	}
>  }
>  
> +static ssize_t tokens_show(struct device *dev,
> +			   struct device_attribute *attr, char *buf)
> +{
> +	size_t off = 0;
> +	int i;
> +
> +	for (i = 0; i < da_num_tokens; i++) {
> +		if (off > PAGE_SIZE)
> +			break;
> +		off += scnprintf(buf+off, PAGE_SIZE-off, "%x @ %x : %x\n",
> +		da_tokens[i].tokenID, da_tokens[i].location,
> +		da_tokens[i].value);
> +	}
> +
> +	return off;
> +}
> +
> +DEVICE_ATTR(tokens, 0400, tokens_show, NULL);
> +
> +static struct attribute *smbios_attrs[] = {
> +	&dev_attr_tokens.attr,
> +	NULL
> +};
> +
> +static const struct attribute_group smbios_attribute_group = {
> +	.attrs = smbios_attrs,
> +};
> +
>  static int dell_wmi_smbios_probe(struct wmi_device *wdev)
>  {
>  	int ret;
> @@ -206,8 +234,16 @@ static int dell_wmi_smbios_probe(struct wmi_device *wdev)
>  		goto fail_buffer;
>  	}
>  
> +	ret = sysfs_create_group(&wdev->dev.kobj, &smbios_attribute_group);
> +	if (ret)
> +		goto fail_create_group;
> +	kobject_uevent(&wdev->dev.kobj, KOBJ_CHANGE);
> +
>  	return 0;
>  
> +fail_create_group:
> +	free_page((unsigned long)buffer);
> +
>  fail_buffer:
>  	kfree(da_tokens);
>  	return ret;
> @@ -215,8 +251,10 @@ static int dell_wmi_smbios_probe(struct wmi_device *wdev)
>  
>  static int dell_wmi_smbios_remove(struct wmi_device *wdev)
>  {
> +	sysfs_remove_group(&wdev->dev.kobj, &smbios_attribute_group);
>  	kfree(da_tokens);
>  	free_page((unsigned long)buffer);
> +	kobject_uevent(&wdev->dev.kobj, KOBJ_CHANGE);
>  	return 0;
>  }
>  

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character device for userspace

[Pali Rohár]

On Thursday 21 September 2017 08:57:16 Mario Limonciello wrote:
> This userspace character device will be used to perform SMBIOS calls
> from any applications sending a properly formatted 4k calling interface
> buffer.
> 
> This character device is intended to deprecate the dcdbas kernel module
> and the interface that it provides to userspace.
> 
> It's important for the driver to provide a R/W ioctl to ensure that
> two competing userspace processes don't race to provide or read each
> others data.
> 
> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
> ---
>  Documentation/ABI/testing/dell-wmi-smbios |  19 ++++++
>  drivers/platform/x86/dell-wmi-smbios.c    | 108 ++++++++++++++++++++++++++----
>  drivers/platform/x86/dell-wmi-smbios.h    |   5 ++
>  3 files changed, 120 insertions(+), 12 deletions(-)
>  create mode 100644 Documentation/ABI/testing/dell-wmi-smbios
> 
> diff --git a/Documentation/ABI/testing/dell-wmi-smbios b/Documentation/ABI/testing/dell-wmi-smbios
> new file mode 100644
> index 000000000000..54dcf73b3031
> --- /dev/null
> +++ b/Documentation/ABI/testing/dell-wmi-smbios
> @@ -0,0 +1,19 @@
> +What:		/dev/wmi-dell-wmi-smbios

What about just /dev/dell-smbios? IOCTL provided here is just SMBIOS
related and I think userspace does not have to care if it is via WMI or
direct SMM mode... Important is that it provides character device for
SMBIOS API and not how it is implemented.

Anyway, Darren, Andy, do we have some convention for naming platform
character devices?

> +Date:		October 2017
> +KernelVersion:	4.15
> +Contact:	"Mario Limonciello" <mario.limonciello@dell.com>
> +Description:
> +		Perform an SMBIOS call on a supported Dell machine
> +		through the Dell ACPI-WMI interface.
> +
> +		To make a call prepare a 4k buffer like this:
> +		struct buffer {
> +			u16 class;
> +			u16 select;
> +			u32 input[4];
> +			u32 output[4];
> +			u8 data[4060];
> +		} __packed;
> +
> +		Perform this RW IOCTL to get the result:
> +		_IOWR('D', 0, struct calling_interface_buffer)

I would suggest to provide uapi header file with all needed structures
and defines. So userspace application would have it and would not need
to implement own buffer...

> diff --git a/drivers/platform/x86/dell-wmi-smbios.c b/drivers/platform/x86/dell-wmi-smbios.c
> index 9deb851ff517..22e47fba6a59 100644
> --- a/drivers/platform/x86/dell-wmi-smbios.c
> +++ b/drivers/platform/x86/dell-wmi-smbios.c
> @@ -21,6 +21,7 @@
>  #include <linux/err.h>
>  #include <linux/mutex.h>
>  #include <linux/wmi.h>
> +#include <linux/uaccess.h>
>  #include "dell-wmi-smbios.h"
>  
>  #define DELL_WMI_SMBIOS_GUID "A80593CE-A997-11DA-B012-B622A1EF5492"
> @@ -34,7 +35,8 @@ struct calling_interface_structure {
>  	struct calling_interface_token tokens[];
>  } __packed;
>  
> -static struct calling_interface_buffer *buffer;
> +static struct calling_interface_buffer *internal_buffer;
> +static struct calling_interface_buffer *sysfs_buffer;
>  static DEFINE_MUTEX(buffer_mutex);
>  
>  static int da_command_address;
> @@ -61,13 +63,13 @@ struct calling_interface_buffer *dell_smbios_get_buffer(void)
>  {
>  	mutex_lock(&buffer_mutex);
>  	dell_smbios_clear_buffer();
> -	return buffer;
> +	return internal_buffer;
>  }
>  EXPORT_SYMBOL_GPL(dell_smbios_get_buffer);
>  
>  void dell_smbios_clear_buffer(void)
>  {
> -	memset(buffer, 0, sizeof(struct calling_interface_buffer));
> +	memset(internal_buffer, 0, sizeof(struct calling_interface_buffer));
>  }
>  EXPORT_SYMBOL_GPL(dell_smbios_clear_buffer);
>  
> @@ -107,9 +109,9 @@ int run_wmi_smbios_call(struct calling_interface_buffer *buffer)
>  
>  void dell_smbios_send_request(int class, int select)
>  {
> -	buffer->class = class;
> -	buffer->select = select;
> -	run_wmi_smbios_call(buffer);
> +	internal_buffer->class = class;
> +	internal_buffer->select = select;
> +	run_wmi_smbios_call(internal_buffer);
>  }
>  EXPORT_SYMBOL_GPL(dell_smbios_send_request);
>  
> @@ -218,6 +220,68 @@ static const struct attribute_group smbios_attribute_group = {
>  	.attrs = smbios_attrs,
>  };
>  
> +static int dell_wmi_smbios_open(struct inode *inode, struct file *file)
> +{
> +	return nonseekable_open(inode, file);
> +}
> +
> +static int dell_wmi_smbios_release(struct inode *inode, struct file *file)
> +{
> +	return 0;
> +}
> +
> +static ssize_t dell_wmi_smbios_read(struct file *file, char __user *data,
> +				   size_t len, loff_t *ppos)
> +{
> +	ssize_t size = sizeof(struct calling_interface_buffer);
> +	void *src;
> +
> +	if (*ppos >= size)
> +		return 0;
> +	if (len >= size)
> +		len = size;
> +	if (*ppos + len > size)
> +		len = size - *ppos;
> +	src = (void __force *) (sysfs_buffer + *ppos);
> +	if (copy_to_user(data, src, len))
> +		return -EFAULT;
> +
> +	*ppos += len;
> +	return len;
> +}
> +
> +static long dell_wmi_smbios_ioctl(struct file *filp, unsigned int cmd,
> +	unsigned long arg)
> +{
> +	int ret = 0;
> +	size_t size;
> +
> +	if (_IOC_TYPE(cmd) != DELL_WMI_SMBIOS_IOC)
> +		return -ENOTTY;
> +
> +	switch (cmd) {
> +	case DELL_WMI_SMBIOS_CMD:
> +		size = sizeof(struct calling_interface_buffer);
> +		mutex_lock(&buffer_mutex);
> +		if (copy_from_user(sysfs_buffer, (void __user *) arg, size)) {
> +			ret = -EFAULT;
> +			goto fail_smbios_cmd;
> +		}
> +		ret = run_wmi_smbios_call(sysfs_buffer);
> +		if (ret != 0)
> +			goto fail_smbios_cmd;
> +		if (copy_to_user((void __user *) arg, sysfs_buffer, size))
> +			ret = -EFAULT;
> +fail_smbios_cmd:
> +		mutex_unlock(&buffer_mutex);
> +		break;
> +	default:
> +		pr_err("unsupported ioctl: %d.\n", cmd);
> +		ret = -ENOIOCTLCMD;
> +	}
> +	return ret;
> +}
> +
>  /*
>   * Descriptor buffer is 128 byte long and contains:
>   *
> @@ -306,12 +370,19 @@ static int dell_wmi_smbios_probe(struct wmi_device *wdev)
>  	if (ret)
>  		return ret;
>  
> -	buffer = (void *)__get_free_page(GFP_KERNEL);
> -	if (!buffer) {
> +	internal_buffer = (void *)__get_free_page(GFP_KERNEL);
> +	if (!internal_buffer) {
>  		ret = -ENOMEM;
> -		goto fail_buffer;
> +		goto fail_internal_buffer;
>  	}
>  
> +	sysfs_buffer = (void *)__get_free_page(GFP_KERNEL);
> +	if (!sysfs_buffer) {
> +		ret = -ENOMEM;
> +		goto fail_sysfs_buffer;
> +	}
> +	memset(sysfs_buffer, 0, sizeof(struct calling_interface_buffer));
> +
>  	ret = sysfs_create_group(&wdev->dev.kobj, &smbios_attribute_group);
>  	if (ret)
>  		goto fail_create_group;
> @@ -320,9 +391,12 @@ static int dell_wmi_smbios_probe(struct wmi_device *wdev)
>  	return 0;
>  
>  fail_create_group:
> -	free_page((unsigned long)buffer);
> +	free_page((unsigned long)sysfs_buffer);
>  
> -fail_buffer:
> +fail_sysfs_buffer:
> +	free_page((unsigned long)internal_buffer);
> +
> +fail_internal_buffer:
>  	kfree(da_tokens);
>  	return ret;
>  }
> @@ -331,7 +405,8 @@ static int dell_wmi_smbios_remove(struct wmi_device *wdev)
>  {
>  	sysfs_remove_group(&wdev->dev.kobj, &smbios_attribute_group);
>  	kfree(da_tokens);
> -	free_page((unsigned long)buffer);
> +	free_page((unsigned long)internal_buffer);
> +	free_page((unsigned long)sysfs_buffer);
>  	kobject_uevent(&wdev->dev.kobj, KOBJ_CHANGE);
>  	return 0;
>  }
> @@ -341,6 +416,14 @@ static const struct wmi_device_id dell_wmi_smbios_id_table[] = {
>  	{ },
>  };
>  
> +static const struct file_operations dell_wmi_smbios_fops = {
> +	.owner		= THIS_MODULE,
> +	.read		= dell_wmi_smbios_read,
> +	.unlocked_ioctl	= dell_wmi_smbios_ioctl,
> +	.open		= dell_wmi_smbios_open,
> +	.release	= dell_wmi_smbios_release,
> +};
> +
>  static struct wmi_driver dell_wmi_smbios_driver = {
>  	.driver = {
>  		.name = "dell-wmi-smbios",
> @@ -348,6 +431,7 @@ static struct wmi_driver dell_wmi_smbios_driver = {
>  	.probe = dell_wmi_smbios_probe,
>  	.remove = dell_wmi_smbios_remove,
>  	.id_table = dell_wmi_smbios_id_table,
> +	.file_operations = &dell_wmi_smbios_fops,
>  };
>  module_wmi_driver(dell_wmi_smbios_driver);
>  
> diff --git a/drivers/platform/x86/dell-wmi-smbios.h b/drivers/platform/x86/dell-wmi-smbios.h
> index 0521ec5d437b..b8215eb879b2 100644
> --- a/drivers/platform/x86/dell-wmi-smbios.h
> +++ b/drivers/platform/x86/dell-wmi-smbios.h
> @@ -18,6 +18,7 @@
>  #define _DELL_WMI_SMBIOS_H_
>  
>  #include <linux/wmi.h>
> +#include <linux/ioctl.h>
>  
>  struct notifier_block;
>  
> @@ -40,6 +41,10 @@ struct calling_interface_token {
>  	};
>  };
>  
> +#define DELL_WMI_SMBIOS_IOC   'D'
> +#define DELL_WMI_SMBIOS_CMD   _IOWR(DELL_WMI_SMBIOS_IOC, 0, \
> +				   struct calling_interface_buffer)
> +
>  int dell_smbios_error(int value);
>  
>  struct calling_interface_buffer *dell_smbios_get_buffer(void);

-- 
Pali Rohár
pali.rohar@gmail.com

RE: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI

[Mario.Limonciello]

Hi Pali,

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Monday, September 25, 2017 12:14 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; platform-driver-
> x86@vger.kernel.org; quasisec@google.com
> Subject: Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI
> 
> On Thursday 21 September 2017 08:57:05 Mario Limonciello wrote:
> > The existing way that the dell-smbios helper module and associated
> > other drivers (dell-laptop, dell-wmi) communicate with the platform
> > really isn't secure.  It requires creating a buffer in physical
> > DMA32 memory space and passing that to the platform via SMM.
> >
> > Since the platform got a physical memory pointer, you've just got
> > to trust that the platform has only modified (and accessed) memory
> > within that buffer.
> 
> And what is the problem? The whole memory management is done by kernel
> itself, so you already need to trust it.

There's a lot of ifs, but it's not that crazy of a scenario.

The problem is that if a malicious payload was delivered to the platform
and exercised a vulnerability in the platform code that payload could 
potentially modify memory that it wasn't intended to modify and the OS
would not be aware as operating in SMM.

> 
> > Dell Platform designers recognize this security risk and offer a
> > safer way to communicate with the platform over ACPI.  This is
> > in turn exposed via a WMI interface to the OS.
> 
> Hm... I cannot understand how some proprietary ACPI bytecode interpreted
> by kernel can be safer as kernel code itself.
> 

Inherently ACPI can only operate on operation regions and not physical memory.
Data passed into ACPI needs to be copied to an operation region for any ACPI
calls to use it.

Furthermore you can decompile the ASL and audit, you can't do this with direct
SMI/SMM.

> Can you describe more details about this security risk?
> 
> > When communicating over WMI-ACPI the communication doesn't occur
> > with physical memory pointers.  When the ASL is invoked, the fixed
> > length ACPI buffer is copied to a small operating region.  The ASL
> > will invoke the SMI, and SMM will only have access to this operating
> > region.  When the ASL returns the buffer is copied back for the OS
> > to process.
> 
> If problem is in current kernel implementation, then it can be fixed.
> 
>
> I'm not against using new WMI communication, but I cannot understand how
> kernel code itself is less safer as some other code which is interpreted
> by kernel. It does not make sense for me.
> 

Well we're talking hypotheticals here in the way things work.
There aren't necessarily problems with the current implementation.

Also, I didn't already mention this explicitly but I've alluded it to it;
Dell is deprecating that interface.  I can't say when, but it will stop working
on some new hardware at some point.

That's the other reason why I'm pushing for the new communication path
now.

> > This method of communication should also deprecate the usage of the
> > dcdbas kernel module and software dependent upon it's interface.
> > Instead offer a syfs interface for communicating with this ASL
> > method to allow userspace to use instead.
> >
> > To faciliate that needs for userspace and kernel space this patch
> > series introduces a generic way for WMI drivers to be able to
> > create character devices through the WMI bus when desired.
> > Requiring WMI drivers to explictly ask for this functionality will
> > act as an effective vendor whitelist.
> 
> --
> Pali Rohár
> pali.rohar@gmail.com

RE: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI

[Mario.Limonciello]

Hi Pali,

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Monday, September 25, 2017 12:14 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; platform-driver-
> x86@vger.kernel.org; quasisec@google.com
> Subject: Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI
> 
> On Thursday 21 September 2017 08:57:05 Mario Limonciello wrote:
> > The existing way that the dell-smbios helper module and associated
> > other drivers (dell-laptop, dell-wmi) communicate with the platform
> > really isn't secure.  It requires creating a buffer in physical
> > DMA32 memory space and passing that to the platform via SMM.
> >
> > Since the platform got a physical memory pointer, you've just got
> > to trust that the platform has only modified (and accessed) memory
> > within that buffer.
> 
> And what is the problem? The whole memory management is done by kernel
> itself, so you already need to trust it.

There's a lot of ifs, but it's not that crazy of a scenario.

The problem is that if a malicious payload was delivered to the platform
and exercised a vulnerability in the platform code that payload could 
potentially modify memory that it wasn't intended to modify and the OS
would not be aware as operating in SMM.

> 
> > Dell Platform designers recognize this security risk and offer a
> > safer way to communicate with the platform over ACPI.  This is
> > in turn exposed via a WMI interface to the OS.
> 
> Hm... I cannot understand how some proprietary ACPI bytecode interpreted
> by kernel can be safer as kernel code itself.
> 

Inherently ACPI can only operate on operation regions and not physical memory.
Data passed into ACPI needs to be copied to an operation region for any ACPI
calls to use it.

Furthermore you can decompile the ASL and audit, you can't do this with direct
SMI/SMM.

> Can you describe more details about this security risk?
> 
> > When communicating over WMI-ACPI the communication doesn't occur
> > with physical memory pointers.  When the ASL is invoked, the fixed
> > length ACPI buffer is copied to a small operating region.  The ASL
> > will invoke the SMI, and SMM will only have access to this operating
> > region.  When the ASL returns the buffer is copied back for the OS
> > to process.
> 
> If problem is in current kernel implementation, then it can be fixed.
> 
>
> I'm not against using new WMI communication, but I cannot understand how
> kernel code itself is less safer as some other code which is interpreted
> by kernel. It does not make sense for me.
> 

Well we're talking hypotheticals here in the way things work.
There aren't necessarily problems with the current implementation.

Also, I didn't already mention this explicitly but I've alluded it to it;
Dell is deprecating that interface.  I can't say when, but it will stop working
on some new hardware at some point.

That's the other reason why I'm pushing for the new communication path
now.

> > This method of communication should also deprecate the usage of the
> > dcdbas kernel module and software dependent upon it's interface.
> > Instead offer a syfs interface for communicating with this ASL
> > method to allow userspace to use instead.
> >
> > To faciliate that needs for userspace and kernel space this patch
> > series introduces a generic way for WMI drivers to be able to
> > create character devices through the WMI bus when desired.
> > Requiring WMI drivers to explictly ask for this functionality will
> > act as an effective vendor whitelist.
> 
> --
> Pali Rohár
> pali.rohar@gmail.com

Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI

[Pali Rohár]

On Monday 25 September 2017 16:32:52 Mario.Limonciello@dell.com wrote:
> Hi Pali,
> 
> > -----Original Message-----
> > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > Sent: Monday, September 25, 2017 12:14 PM
> > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; platform-driver-
> > x86@vger.kernel.org; quasisec@google.com
> > Subject: Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI
> > 
> > On Thursday 21 September 2017 08:57:05 Mario Limonciello wrote:
> > > The existing way that the dell-smbios helper module and associated
> > > other drivers (dell-laptop, dell-wmi) communicate with the platform
> > > really isn't secure.  It requires creating a buffer in physical
> > > DMA32 memory space and passing that to the platform via SMM.
> > >
> > > Since the platform got a physical memory pointer, you've just got
> > > to trust that the platform has only modified (and accessed) memory
> > > within that buffer.
> > 
> > And what is the problem? The whole memory management is done by kernel
> > itself, so you already need to trust it.
> 
> There's a lot of ifs, but it's not that crazy of a scenario.
> 
> The problem is that if a malicious payload was delivered to the platform
> and exercised a vulnerability in the platform code that payload could 
> potentially modify memory that it wasn't intended to modify and the OS
> would not be aware as operating in SMM.
> 
> > 
> > > Dell Platform designers recognize this security risk and offer a
> > > safer way to communicate with the platform over ACPI.  This is
> > > in turn exposed via a WMI interface to the OS.
> > 
> > Hm... I cannot understand how some proprietary ACPI bytecode interpreted
> > by kernel can be safer as kernel code itself.
> > 
> 
> Inherently ACPI can only operate on operation regions and not physical memory.
> Data passed into ACPI needs to be copied to an operation region for any ACPI
> calls to use it.

But operation regions access is implemented by ACPI interpreter, which
is again kernel code.

> Furthermore you can decompile the ASL and audit, you can't do this with direct
> SMI/SMM.
> 
> > Can you describe more details about this security risk?
> > 
> > > When communicating over WMI-ACPI the communication doesn't occur
> > > with physical memory pointers.  When the ASL is invoked, the fixed
> > > length ACPI buffer is copied to a small operating region.  The ASL
> > > will invoke the SMI, and SMM will only have access to this operating
> > > region.  When the ASL returns the buffer is copied back for the OS
> > > to process.
> > 
> > If problem is in current kernel implementation, then it can be fixed.
> > 
> >
> > I'm not against using new WMI communication, but I cannot understand how
> > kernel code itself is less safer as some other code which is interpreted
> > by kernel. It does not make sense for me.
> > 
> 
> Well we're talking hypotheticals here in the way things work.
> There aren't necessarily problems with the current implementation.

Ok.

> Also, I didn't already mention this explicitly but I've alluded it to it;
> Dell is deprecating that interface.  I can't say when, but it will stop working
> on some new hardware at some point.
> 
> That's the other reason why I'm pushing for the new communication path
> now.

Ok, as I wrote I'm not against new communication method and specially
now, when you confirmed that in future new machines would not support
"old" method...

... but old communication method should stay there for older machines. I
do not think it would be hard to have both implementations in kernel and
choosing that which is supported on current machine.

> > > This method of communication should also deprecate the usage of the
> > > dcdbas kernel module and software dependent upon it's interface.
> > > Instead offer a syfs interface for communicating with this ASL
> > > method to allow userspace to use instead.
> > >
> > > To faciliate that needs for userspace and kernel space this patch
> > > series introduces a generic way for WMI drivers to be able to
> > > create character devices through the WMI bus when desired.
> > > Requiring WMI drivers to explictly ask for this functionality will
> > > act as an effective vendor whitelist.
> > 
> > --
> > Pali Rohár
> > pali.rohar@gmail.com

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character device for userspace

[Andy Shevchenko]

On Mon, Sep 25, 2017 at 7:31 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Thursday 21 September 2017 08:57:16 Mario Limonciello wrote:
>> This userspace character device will be used to perform SMBIOS calls
>> from any applications sending a properly formatted 4k calling interface
>> buffer.
>>
>> This character device is intended to deprecate the dcdbas kernel module
>> and the interface that it provides to userspace.
>>
>> It's important for the driver to provide a R/W ioctl to ensure that
>> two competing userspace processes don't race to provide or read each
>> others data.

>> +What:                /dev/wmi-dell-wmi-smbios
>
> What about just /dev/dell-smbios? IOCTL provided here is just SMBIOS
> related and I think userspace does not have to care if it is via WMI or
> direct SMM mode... Important is that it provides character device for
> SMBIOS API and not how it is implemented.
>
> Anyway, Darren, Andy, do we have some convention for naming platform
> character devices?

For me, looking to this case, seems better to expose a folder like
/dev/smbios/
with actual vendor device nodes inside like
/dev/smbios/dell

Darren?

P.S. Interestingly I wasn't in Cc list for this series at all.

-- 
With Best Regards,
Andy Shevchenko

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

[Andy Shevchenko]

On Mon, Sep 25, 2017 at 7:23 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Thursday 21 September 2017 08:57:11 Mario Limonciello wrote:
>> Currently userspace tools can access system tokens via the dcdbas
>> kernel module and a SMI call that will cause the platform to execute
>> SMM code.
>>
>> With a goal in mind of deprecating the dcdbas kernel module a different
>> method for accessing these tokens from userspace needs to be created.
>>
>> This is intentionally marked to only be readable as root as it can
>> contain sensitive information about the platform's configuration.
>
> 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?

> Basically tokens are list of tuples <id, location, value> with
> possibility to active them, right?
>
> Does not kernel have some better API for it?

I think the best what kernel may provide is a CSV-like format with or
without title line and different delimiter (TAB/space/etc).

>
> Also, keep in mind security aspect of tokens. They represent e.g. boot
> order priority or enable/disable some machine peripheral.

For IOCTLs we may use capabilities.
In sysfs case we may zero output based on capabilities or some other factors.

-- 
With Best Regards,
Andy Shevchenko

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

[Mario.Limonciello]

> -----Original Message-----
> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Sent: Monday, September 25, 2017 1:04 PM
> To: Pali Rohár <pali.rohar@gmail.com>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; dvhart@infradead.org;
> LKML <linux-kernel@vger.kernel.org>; Platform Driver <platform-driver-
> x86@vger.kernel.org>; quasisec@google.com
> Subject: Re: [PATCH 06/12] platform/x86: dell-wmi-smbios: Add a sysfs interface
> for SMBIOS tokens
> 
> On Mon, Sep 25, 2017 at 7:23 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Thursday 21 September 2017 08:57:11 Mario Limonciello wrote:
> >> Currently userspace tools can access system tokens via the dcdbas
> >> kernel module and a SMI call that will cause the platform to execute
> >> SMM code.
> >>
> >> With a goal in mind of deprecating the dcdbas kernel module a different
> >> method for accessing these tokens from userspace needs to be created.
> >>
> >> This is intentionally marked to only be readable as root as it can
> >> contain sensitive information about the platform's configuration.
> >
> > 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.

> 
> > 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.

> > Does not kernel have some better API for it?
> 
> I think the best what kernel may provide is a CSV-like format with or
> without title line and different delimiter (TAB/space/etc).
> 
> >
> > Also, keep in mind security aspect of tokens. They represent e.g. boot
> > order priority or enable/disable some machine peripheral.
> 
> For IOCTLs we may use capabilities.
> In sysfs case we may zero output based on capabilities or some other factors.
> 

Can you recommend what capabilities you would prefer to see this based upon?

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

[Mario.Limonciello]

> -----Original Message-----
> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Sent: Monday, September 25, 2017 1:04 PM
> To: Pali Rohár <pali.rohar@gmail.com>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; dvhart@infradead.org;
> LKML <linux-kernel@vger.kernel.org>; Platform Driver <platform-driver-
> x86@vger.kernel.org>; quasisec@google.com
> Subject: Re: [PATCH 06/12] platform/x86: dell-wmi-smbios: Add a sysfs interface
> for SMBIOS tokens
> 
> On Mon, Sep 25, 2017 at 7:23 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Thursday 21 September 2017 08:57:11 Mario Limonciello wrote:
> >> Currently userspace tools can access system tokens via the dcdbas
> >> kernel module and a SMI call that will cause the platform to execute
> >> SMM code.
> >>
> >> With a goal in mind of deprecating the dcdbas kernel module a different
> >> method for accessing these tokens from userspace needs to be created.
> >>
> >> This is intentionally marked to only be readable as root as it can
> >> contain sensitive information about the platform's configuration.
> >
> > 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.

> 
> > 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.

> > Does not kernel have some better API for it?
> 
> I think the best what kernel may provide is a CSV-like format with or
> without title line and different delimiter (TAB/space/etc).
> 
> >
> > Also, keep in mind security aspect of tokens. They represent e.g. boot
> > order priority or enable/disable some machine peripheral.
> 
> For IOCTLs we may use capabilities.
> In sysfs case we may zero output based on capabilities or some other factors.
> 

Can you recommend what capabilities you would prefer to see this based upon?

RE: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character device for userspace

[Mario.Limonciello]

> -----Original Message-----
> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Sent: Monday, September 25, 2017 12:58 PM
> To: Pali Rohár <pali.rohar@gmail.com>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; dvhart@infradead.org;
> LKML <linux-kernel@vger.kernel.org>; Platform Driver <platform-driver-
> x86@vger.kernel.org>; quasisec@google.com
> Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character
> device for userspace
> 
> On Mon, Sep 25, 2017 at 7:31 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Thursday 21 September 2017 08:57:16 Mario Limonciello wrote:
> >> This userspace character device will be used to perform SMBIOS calls
> >> from any applications sending a properly formatted 4k calling interface
> >> buffer.
> >>
> >> This character device is intended to deprecate the dcdbas kernel module
> >> and the interface that it provides to userspace.
> >>
> >> It's important for the driver to provide a R/W ioctl to ensure that
> >> two competing userspace processes don't race to provide or read each
> >> others data.
> 
> >> +What:                /dev/wmi-dell-wmi-smbios
> >
> > What about just /dev/dell-smbios? IOCTL provided here is just SMBIOS
> > related and I think userspace does not have to care if it is via WMI or
> > direct SMM mode... Important is that it provides character device for
> > SMBIOS API and not how it is implemented.
> >
> > Anyway, Darren, Andy, do we have some convention for naming platform
> > character devices?
> 
> For me, looking to this case, seems better to expose a folder like
> /dev/smbios/
> with actual vendor device nodes inside like
> /dev/smbios/dell

I disagree with this.  Dell exposes smbios calling in this kernel interface but
other vendor drivers may also expose different methods for character devices
that are not SMBIOS.

I'm envisioning that this is just the first kernel module that will use a WMI
character device to userspace.  That's why I wanted to use a generic namespace.

I would say it could be /dev/wmi-$GUID or /dev/wmi/$driver-$GUID if you want 
something more generic.
As long as it's discovereable from uevent that's fine to me.

> 
> Darren?
> 
> P.S. Interestingly I wasn't in Cc list for this series at all.

Sorry, my mistake in gitconfig.  I'll add you in next version submission.

RE: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character device for userspace

[Mario.Limonciello]

> -----Original Message-----
> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Sent: Monday, September 25, 2017 12:58 PM
> To: Pali Rohár <pali.rohar@gmail.com>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; dvhart@infradead.org;
> LKML <linux-kernel@vger.kernel.org>; Platform Driver <platform-driver-
> x86@vger.kernel.org>; quasisec@google.com
> Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character
> device for userspace
> 
> On Mon, Sep 25, 2017 at 7:31 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Thursday 21 September 2017 08:57:16 Mario Limonciello wrote:
> >> This userspace character device will be used to perform SMBIOS calls
> >> from any applications sending a properly formatted 4k calling interface
> >> buffer.
> >>
> >> This character device is intended to deprecate the dcdbas kernel module
> >> and the interface that it provides to userspace.
> >>
> >> It's important for the driver to provide a R/W ioctl to ensure that
> >> two competing userspace processes don't race to provide or read each
> >> others data.
> 
> >> +What:                /dev/wmi-dell-wmi-smbios
> >
> > What about just /dev/dell-smbios? IOCTL provided here is just SMBIOS
> > related and I think userspace does not have to care if it is via WMI or
> > direct SMM mode... Important is that it provides character device for
> > SMBIOS API and not how it is implemented.
> >
> > Anyway, Darren, Andy, do we have some convention for naming platform
> > character devices?
> 
> For me, looking to this case, seems better to expose a folder like
> /dev/smbios/
> with actual vendor device nodes inside like
> /dev/smbios/dell

I disagree with this.  Dell exposes smbios calling in this kernel interface but
other vendor drivers may also expose different methods for character devices
that are not SMBIOS.

I'm envisioning that this is just the first kernel module that will use a WMI
character device to userspace.  That's why I wanted to use a generic namespace.

I would say it could be /dev/wmi-$GUID or /dev/wmi/$driver-$GUID if you want 
something more generic.
As long as it's discovereable from uevent that's fine to me.

> 
> Darren?
> 
> P.S. Interestingly I wasn't in Cc list for this series at all.

Sorry, my mistake in gitconfig.  I'll add you in next version submission.

RE: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI

[Mario.Limonciello]

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Monday, September 25, 2017 12:49 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; linux-kernel@vger.kernel.org; platform-driver-
> x86@vger.kernel.org; quasisec@google.com
> Subject: Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI
> 
> On Monday 25 September 2017 16:32:52 Mario.Limonciello@dell.com wrote:
> > Hi Pali,
> >
> > > -----Original Message-----
> > > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > > Sent: Monday, September 25, 2017 12:14 PM
> > > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; platform-
> driver-
> > > x86@vger.kernel.org; quasisec@google.com
> > > Subject: Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI
> > >
> > > On Thursday 21 September 2017 08:57:05 Mario Limonciello wrote:
> > > > The existing way that the dell-smbios helper module and associated
> > > > other drivers (dell-laptop, dell-wmi) communicate with the platform
> > > > really isn't secure.  It requires creating a buffer in physical
> > > > DMA32 memory space and passing that to the platform via SMM.
> > > >
> > > > Since the platform got a physical memory pointer, you've just got
> > > > to trust that the platform has only modified (and accessed) memory
> > > > within that buffer.
> > >
> > > And what is the problem? The whole memory management is done by kernel
> > > itself, so you already need to trust it.
> >
> > There's a lot of ifs, but it's not that crazy of a scenario.
> >
> > The problem is that if a malicious payload was delivered to the platform
> > and exercised a vulnerability in the platform code that payload could
> > potentially modify memory that it wasn't intended to modify and the OS
> > would not be aware as operating in SMM.
> >
> > >
> > > > Dell Platform designers recognize this security risk and offer a
> > > > safer way to communicate with the platform over ACPI.  This is
> > > > in turn exposed via a WMI interface to the OS.
> > >
> > > Hm... I cannot understand how some proprietary ACPI bytecode interpreted
> > > by kernel can be safer as kernel code itself.
> > >
> >
> > Inherently ACPI can only operate on operation regions and not physical memory.
> > Data passed into ACPI needs to be copied to an operation region for any ACPI
> > calls to use it.
> 
> But operation regions access is implemented by ACPI interpreter, which
> is again kernel code.

So isn't that making my point?
* Kernel can control operation region accessibility.  SMM can't operate outside
of this region.
* Direct SMI gives platform access to everything < 4G, kernel can't control this.

> 
> > Furthermore you can decompile the ASL and audit, you can't do this with direct
> > SMI/SMM.
> >
> > > Can you describe more details about this security risk?
> > >
> > > > When communicating over WMI-ACPI the communication doesn't occur
> > > > with physical memory pointers.  When the ASL is invoked, the fixed
> > > > length ACPI buffer is copied to a small operating region.  The ASL
> > > > will invoke the SMI, and SMM will only have access to this operating
> > > > region.  When the ASL returns the buffer is copied back for the OS
> > > > to process.
> > >
> > > If problem is in current kernel implementation, then it can be fixed.
> > >
> > >
> > > I'm not against using new WMI communication, but I cannot understand how
> > > kernel code itself is less safer as some other code which is interpreted
> > > by kernel. It does not make sense for me.
> > >
> >
> > Well we're talking hypotheticals here in the way things work.
> > There aren't necessarily problems with the current implementation.
> 
> Ok.
> 
> > Also, I didn't already mention this explicitly but I've alluded it to it;
> > Dell is deprecating that interface.  I can't say when, but it will stop working
> > on some new hardware at some point.
> >
> > That's the other reason why I'm pushing for the new communication path
> > now.
> 
> Ok, as I wrote I'm not against new communication method and specially
> now, when you confirmed that in future new machines would not support
> "old" method...
> 
> ... but old communication method should stay there for older machines. I
> do not think it would be hard to have both implementations in kernel and
> choosing that which is supported on current machine.

The WMI interface has been around for at least 10 years.  I think the number
of machines still running on the older implementation only is very small.

There is however a bit that will set the availability of this interface.  I'll rework
my patches to offer both WMI and legacy SMI approach based upon that
presence of the bit.

> 
> > > > This method of communication should also deprecate the usage of the
> > > > dcdbas kernel module and software dependent upon it's interface.
> > > > Instead offer a syfs interface for communicating with this ASL
> > > > method to allow userspace to use instead.
> > > >
> > > > To faciliate that needs for userspace and kernel space this patch
> > > > series introduces a generic way for WMI drivers to be able to
> > > > create character devices through the WMI bus when desired.
> > > > Requiring WMI drivers to explictly ask for this functionality will
> > > > act as an effective vendor whitelist.
> > >
> > > --
> > > Pali Rohár
> > > pali.rohar@gmail.com
> 
> --
> Pali Rohár
> pali.rohar@gmail.com

RE: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI

[Mario.Limonciello]

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Monday, September 25, 2017 12:49 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; linux-kernel@vger.kernel.org; platform-driver-
> x86@vger.kernel.org; quasisec@google.com
> Subject: Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI
> 
> On Monday 25 September 2017 16:32:52 Mario.Limonciello@dell.com wrote:
> > Hi Pali,
> >
> > > -----Original Message-----
> > > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > > Sent: Monday, September 25, 2017 12:14 PM
> > > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; platform-
> driver-
> > > x86@vger.kernel.org; quasisec@google.com
> > > Subject: Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI
> > >
> > > On Thursday 21 September 2017 08:57:05 Mario Limonciello wrote:
> > > > The existing way that the dell-smbios helper module and associated
> > > > other drivers (dell-laptop, dell-wmi) communicate with the platform
> > > > really isn't secure.  It requires creating a buffer in physical
> > > > DMA32 memory space and passing that to the platform via SMM.
> > > >
> > > > Since the platform got a physical memory pointer, you've just got
> > > > to trust that the platform has only modified (and accessed) memory
> > > > within that buffer.
> > >
> > > And what is the problem? The whole memory management is done by kernel
> > > itself, so you already need to trust it.
> >
> > There's a lot of ifs, but it's not that crazy of a scenario.
> >
> > The problem is that if a malicious payload was delivered to the platform
> > and exercised a vulnerability in the platform code that payload could
> > potentially modify memory that it wasn't intended to modify and the OS
> > would not be aware as operating in SMM.
> >
> > >
> > > > Dell Platform designers recognize this security risk and offer a
> > > > safer way to communicate with the platform over ACPI.  This is
> > > > in turn exposed via a WMI interface to the OS.
> > >
> > > Hm... I cannot understand how some proprietary ACPI bytecode interpreted
> > > by kernel can be safer as kernel code itself.
> > >
> >
> > Inherently ACPI can only operate on operation regions and not physical memory.
> > Data passed into ACPI needs to be copied to an operation region for any ACPI
> > calls to use it.
> 
> But operation regions access is implemented by ACPI interpreter, which
> is again kernel code.

So isn't that making my point?
* Kernel can control operation region accessibility.  SMM can't operate outside
of this region.
* Direct SMI gives platform access to everything < 4G, kernel can't control this.

> 
> > Furthermore you can decompile the ASL and audit, you can't do this with direct
> > SMI/SMM.
> >
> > > Can you describe more details about this security risk?
> > >
> > > > When communicating over WMI-ACPI the communication doesn't occur
> > > > with physical memory pointers.  When the ASL is invoked, the fixed
> > > > length ACPI buffer is copied to a small operating region.  The ASL
> > > > will invoke the SMI, and SMM will only have access to this operating
> > > > region.  When the ASL returns the buffer is copied back for the OS
> > > > to process.
> > >
> > > If problem is in current kernel implementation, then it can be fixed.
> > >
> > >
> > > I'm not against using new WMI communication, but I cannot understand how
> > > kernel code itself is less safer as some other code which is interpreted
> > > by kernel. It does not make sense for me.
> > >
> >
> > Well we're talking hypotheticals here in the way things work.
> > There aren't necessarily problems with the current implementation.
> 
> Ok.
> 
> > Also, I didn't already mention this explicitly but I've alluded it to it;
> > Dell is deprecating that interface.  I can't say when, but it will stop working
> > on some new hardware at some point.
> >
> > That's the other reason why I'm pushing for the new communication path
> > now.
> 
> Ok, as I wrote I'm not against new communication method and specially
> now, when you confirmed that in future new machines would not support
> "old" method...
> 
> ... but old communication method should stay there for older machines. I
> do not think it would be hard to have both implementations in kernel and
> choosing that which is supported on current machine.

The WMI interface has been around for at least 10 years.  I think the number
of machines still running on the older implementation only is very small.

There is however a bit that will set the availability of this interface.  I'll rework
my patches to offer both WMI and legacy SMI approach based upon that
presence of the bit.

> 
> > > > This method of communication should also deprecate the usage of the
> > > > dcdbas kernel module and software dependent upon it's interface.
> > > > Instead offer a syfs interface for communicating with this ASL
> > > > method to allow userspace to use instead.
> > > >
> > > > To faciliate that needs for userspace and kernel space this patch
> > > > series introduces a generic way for WMI drivers to be able to
> > > > create character devices through the WMI bus when desired.
> > > > Requiring WMI drivers to explictly ask for this functionality will
> > > > act as an effective vendor whitelist.
> > >
> > > --
> > > Pali Rohár
> > > pali.rohar@gmail.com
> 
> --
> Pali Rohár
> pali.rohar@gmail.com

RE: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI interface

[Mario.Limonciello]

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Monday, September 25, 2017 12:19 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; platform-driver-
> x86@vger.kernel.org; quasisec@google.com
> Subject: Re: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI
> interface
> 
> On Thursday 21 September 2017 08:57:09 Mario Limonciello wrote:
> > The driver currently uses an SMI interface which grants direct access
> > to physical memory to the platform via a pointer.
> >
> > Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
> > for a buffer of data storage when platform calls are performed.
> >
> > This is a safer approach to use in kernel drivers as the platform will
> > only have access to that OperationRegion.
> 
> In my opinion direct access is safer then using ACPI wrapper for same
> functionality.

I'd like to hear how this is safer.

> 
> Anyway, this change would break support for laptops without ACPI-WMI
> functionality. IIRC I read in some Dell ACPI-WMI documentation that Dell
> SMM via ACPI-WMI is not supported on all machines (probably older
> machines) and it is needed to check some vendor bit in DMI data if Dell
> SMM ACPI-WMI is really supported.
> 
> In linux kernel we do not want to remove support for older machines,
> just because machines with new firmware can use also different new
> communication method/protocol.
> 

As mentioned on other email, I'll rework to support both methods and
prefer WMI method.

> > As a result, this change removes the dependency on this driver on the
> > dcdbas kernel module.
> >
> > Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
> > ---
> >  drivers/platform/x86/Kconfig       |  8 ++--
> >  drivers/platform/x86/dell-smbios.c | 76 ++++++++++++++++++++++++++------------
> >  drivers/platform/x86/dell-smbios.h | 11 +++---
> >  3 files changed, 63 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> > index 9e52f05daa2e..81d61c0f4ef8 100644
> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
> > @@ -92,13 +92,13 @@ config ASUS_LAPTOP
> >  	  If you have an ACPI-compatible ASUS laptop, say Y or M here.
> >
> >  config DELL_SMBIOS
> > -	tristate
> > -	select DCDBAS
> > +	tristate "Dell WMI SMBIOS calling interface"
> > +	depends on ACPI_WMI
> >  	---help---
> >  	This module provides common functions for kernel modules using
> > -	Dell SMBIOS.
> > +	Dell SMBIOS over ACPI-WMI.
> >
> > -	If you have a Dell laptop, say Y or M here.
> > +	If you have a Dell computer, say Y or M here.
> >
> >  config DELL_LAPTOP
> >  	tristate "Dell Laptop Extras"
> > diff --git a/drivers/platform/x86/dell-smbios.c b/drivers/platform/x86/dell-
> smbios.c
> > index e9b1ca07c872..c06262a89169 100644
> > --- a/drivers/platform/x86/dell-smbios.c
> > +++ b/drivers/platform/x86/dell-smbios.c
> > @@ -4,6 +4,7 @@
> >   *  Copyright (c) Red Hat <mjg@redhat.com>
> >   *  Copyright (c) 2014 Gabriele Mazzotta <gabriele.mzt@gmail.com>
> >   *  Copyright (c) 2014 Pali Rohár <pali.rohar@gmail.com>
> > + *  Copyright (c) 2017 Dell Inc.
> >   *
> >   *  Based on documentation in the libsmbios package:
> >   *  Copyright (C) 2005-2014 Dell Inc.
> > @@ -18,13 +19,12 @@
> >  #include <linux/module.h>
> >  #include <linux/dmi.h>
> >  #include <linux/err.h>
> > -#include <linux/gfp.h>
> >  #include <linux/mutex.h>
> > -#include <linux/slab.h>
> > -#include <linux/io.h>
> > -#include "../../firmware/dcdbas.h"
> > +#include <linux/wmi.h>
> >  #include "dell-smbios.h"
> >
> > +#define DELL_WMI_SMBIOS_GUID "A80593CE-A997-11DA-B012-
> B622A1EF5492"
> > +
> >  struct calling_interface_structure {
> >  	struct dmi_header header;
> >  	u16 cmdIOAddress;
> > @@ -76,20 +76,39 @@ void dell_smbios_release_buffer(void)
> >  }
> >  EXPORT_SYMBOL_GPL(dell_smbios_release_buffer);
> >
> > -void dell_smbios_send_request(int class, int select)
> > +int run_wmi_smbios_call(struct calling_interface_buffer *buffer)
> >  {
> > -	struct smi_cmd command;
> > +	struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
> > +	struct acpi_buffer input;
> > +	union acpi_object *obj;
> > +	acpi_status status;
> > +
> > +	input.length = sizeof(struct calling_interface_buffer);
> > +	input.pointer = buffer;
> > +
> > +	status = wmi_evaluate_method(DELL_WMI_SMBIOS_GUID,
> > +				     0, 1, &input, &output);
> > +	if (ACPI_FAILURE(status)) {
> > +		pr_err("%x/%x [%x,%x,%x,%x] call failed\n",
> > +			buffer->class, buffer->select, buffer->input[0],
> > +			buffer->input[1], buffer->input[2], buffer->input[3]);
> > +			return -EIO;
> > +	}
> > +	obj = (union acpi_object *)output.pointer;
> > +	if (obj->type != ACPI_TYPE_BUFFER) {
> > +		pr_err("invalid type : %d\n", obj->type);
> > +		return -EIO;
> > +	}
> > +	memcpy(buffer, obj->buffer.pointer, input.length);
> >
> > -	command.magic = SMI_CMD_MAGIC;
> > -	command.command_address = da_command_address;
> > -	command.command_code = da_command_code;
> > -	command.ebx = virt_to_phys(buffer);
> > -	command.ecx = 0x42534931;
> > +	return 0;
> > +}
> >
> > +void dell_smbios_send_request(int class, int select)
> > +{
> >  	buffer->class = class;
> >  	buffer->select = select;
> > -
> > -	dcdbas_smi_request(&command);
> > +	run_wmi_smbios_call(buffer);
> >  }
> >  EXPORT_SYMBOL_GPL(dell_smbios_send_request);
> >
> > @@ -170,7 +189,7 @@ static void __init find_tokens(const struct dmi_header
> *dm, void *dummy)
> >  	}
> >  }
> >
> > -static int __init dell_smbios_init(void)
> > +static int dell_smbios_probe(struct wmi_device *wdev)
> >  {
> >  	int ret;
> >
> > @@ -181,11 +200,7 @@ static int __init dell_smbios_init(void)
> >  		return -ENODEV;
> >  	}
> >
> > -	/*
> > -	 * Allocate buffer below 4GB for SMI data--only 32-bit physical addr
> > -	 * is passed to SMI handler.
> > -	 */
> > -	buffer = (void *)__get_free_page(GFP_KERNEL | GFP_DMA32);
> > +	buffer = (void *)__get_free_page(GFP_KERNEL);
> >  	if (!buffer) {
> >  		ret = -ENOMEM;
> >  		goto fail_buffer;
> > @@ -198,17 +213,32 @@ static int __init dell_smbios_init(void)
> >  	return ret;
> >  }
> >
> > -static void __exit dell_smbios_exit(void)
> > +static int dell_smbios_remove(struct wmi_device *wdev)
> >  {
> >  	kfree(da_tokens);
> >  	free_page((unsigned long)buffer);
> > +	return 0;
> >  }
> >
> > -subsys_initcall(dell_smbios_init);
> > -module_exit(dell_smbios_exit);
> > +static const struct wmi_device_id dell_smbios_id_table[] = {
> > +	{ .guid_string = DELL_WMI_SMBIOS_GUID },
> > +	{ },
> > +};
> > +
> > +static struct wmi_driver dell_smbios_driver = {
> > +	.driver = {
> > +		.name = "dell-smbios",
> > +	},
> > +	.probe = dell_smbios_probe,
> > +	.remove = dell_smbios_remove,
> > +	.id_table = dell_smbios_id_table,
> > +};
> > +module_wmi_driver(dell_smbios_driver);
> > +
> >
> >  MODULE_AUTHOR("Matthew Garrett <mjg@redhat.com>");
> >  MODULE_AUTHOR("Gabriele Mazzotta <gabriele.mzt@gmail.com>");
> >  MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
> > -MODULE_DESCRIPTION("Common functions for kernel modules using Dell
> SMBIOS");
> > +MODULE_AUTHOR("Mario Limonciello <mario.limonciello@dell.com>");
> > +MODULE_DESCRIPTION("Common functions for kernel modules using Dell
> SMBIOS over WMI");
> >  MODULE_LICENSE("GPL");
> > diff --git a/drivers/platform/x86/dell-smbios.h b/drivers/platform/x86/dell-
> smbios.h
> > index 45cbc2292cd3..e1e29697b362 100644
> > --- a/drivers/platform/x86/dell-smbios.h
> > +++ b/drivers/platform/x86/dell-smbios.h
> > @@ -4,6 +4,7 @@
> >   *  Copyright (c) Red Hat <mjg@redhat.com>
> >   *  Copyright (c) 2014 Gabriele Mazzotta <gabriele.mzt@gmail.com>
> >   *  Copyright (c) 2014 Pali Rohár <pali.rohar@gmail.com>
> > + *  Copyright (c) 2017 Dell Inc.
> >   *
> >   *  Based on documentation in the libsmbios package:
> >   *  Copyright (C) 2005-2014 Dell Inc.
> > @@ -18,14 +19,14 @@
> >
> >  struct notifier_block;
> >
> > -/* This structure will be modified by the firmware when we enter
> > - * system management mode, hence the volatiles */
> > -
> >  struct calling_interface_buffer {
> >  	u16 class;
> >  	u16 select;
> > -	volatile u32 input[4];
> > -	volatile u32 output[4];
> > +	u32 input[4];
> > +	u32 output[4];
> > +	u32 argattrib;
> > +	u32 blength;
> > +	u8 data[4052];
> >  } __packed;
> >
> >  struct calling_interface_token {
> 
> --
> Pali Rohár
> pali.rohar@gmail.com

RE: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI interface

[Mario.Limonciello]

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Monday, September 25, 2017 12:19 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; platform-driver-
> x86@vger.kernel.org; quasisec@google.com
> Subject: Re: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI
> interface
> 
> On Thursday 21 September 2017 08:57:09 Mario Limonciello wrote:
> > The driver currently uses an SMI interface which grants direct access
> > to physical memory to the platform via a pointer.
> >
> > Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
> > for a buffer of data storage when platform calls are performed.
> >
> > This is a safer approach to use in kernel drivers as the platform will
> > only have access to that OperationRegion.
> 
> In my opinion direct access is safer then using ACPI wrapper for same
> functionality.

I'd like to hear how this is safer.

> 
> Anyway, this change would break support for laptops without ACPI-WMI
> functionality. IIRC I read in some Dell ACPI-WMI documentation that Dell
> SMM via ACPI-WMI is not supported on all machines (probably older
> machines) and it is needed to check some vendor bit in DMI data if Dell
> SMM ACPI-WMI is really supported.
> 
> In linux kernel we do not want to remove support for older machines,
> just because machines with new firmware can use also different new
> communication method/protocol.
> 

As mentioned on other email, I'll rework to support both methods and
prefer WMI method.

> > As a result, this change removes the dependency on this driver on the
> > dcdbas kernel module.
> >
> > Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
> > ---
> >  drivers/platform/x86/Kconfig       |  8 ++--
> >  drivers/platform/x86/dell-smbios.c | 76 ++++++++++++++++++++++++++------------
> >  drivers/platform/x86/dell-smbios.h | 11 +++---
> >  3 files changed, 63 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> > index 9e52f05daa2e..81d61c0f4ef8 100644
> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
> > @@ -92,13 +92,13 @@ config ASUS_LAPTOP
> >  	  If you have an ACPI-compatible ASUS laptop, say Y or M here.
> >
> >  config DELL_SMBIOS
> > -	tristate
> > -	select DCDBAS
> > +	tristate "Dell WMI SMBIOS calling interface"
> > +	depends on ACPI_WMI
> >  	---help---
> >  	This module provides common functions for kernel modules using
> > -	Dell SMBIOS.
> > +	Dell SMBIOS over ACPI-WMI.
> >
> > -	If you have a Dell laptop, say Y or M here.
> > +	If you have a Dell computer, say Y or M here.
> >
> >  config DELL_LAPTOP
> >  	tristate "Dell Laptop Extras"
> > diff --git a/drivers/platform/x86/dell-smbios.c b/drivers/platform/x86/dell-
> smbios.c
> > index e9b1ca07c872..c06262a89169 100644
> > --- a/drivers/platform/x86/dell-smbios.c
> > +++ b/drivers/platform/x86/dell-smbios.c
> > @@ -4,6 +4,7 @@
> >   *  Copyright (c) Red Hat <mjg@redhat.com>
> >   *  Copyright (c) 2014 Gabriele Mazzotta <gabriele.mzt@gmail.com>
> >   *  Copyright (c) 2014 Pali Rohár <pali.rohar@gmail.com>
> > + *  Copyright (c) 2017 Dell Inc.
> >   *
> >   *  Based on documentation in the libsmbios package:
> >   *  Copyright (C) 2005-2014 Dell Inc.
> > @@ -18,13 +19,12 @@
> >  #include <linux/module.h>
> >  #include <linux/dmi.h>
> >  #include <linux/err.h>
> > -#include <linux/gfp.h>
> >  #include <linux/mutex.h>
> > -#include <linux/slab.h>
> > -#include <linux/io.h>
> > -#include "../../firmware/dcdbas.h"
> > +#include <linux/wmi.h>
> >  #include "dell-smbios.h"
> >
> > +#define DELL_WMI_SMBIOS_GUID "A80593CE-A997-11DA-B012-
> B622A1EF5492"
> > +
> >  struct calling_interface_structure {
> >  	struct dmi_header header;
> >  	u16 cmdIOAddress;
> > @@ -76,20 +76,39 @@ void dell_smbios_release_buffer(void)
> >  }
> >  EXPORT_SYMBOL_GPL(dell_smbios_release_buffer);
> >
> > -void dell_smbios_send_request(int class, int select)
> > +int run_wmi_smbios_call(struct calling_interface_buffer *buffer)
> >  {
> > -	struct smi_cmd command;
> > +	struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
> > +	struct acpi_buffer input;
> > +	union acpi_object *obj;
> > +	acpi_status status;
> > +
> > +	input.length = sizeof(struct calling_interface_buffer);
> > +	input.pointer = buffer;
> > +
> > +	status = wmi_evaluate_method(DELL_WMI_SMBIOS_GUID,
> > +				     0, 1, &input, &output);
> > +	if (ACPI_FAILURE(status)) {
> > +		pr_err("%x/%x [%x,%x,%x,%x] call failed\n",
> > +			buffer->class, buffer->select, buffer->input[0],
> > +			buffer->input[1], buffer->input[2], buffer->input[3]);
> > +			return -EIO;
> > +	}
> > +	obj = (union acpi_object *)output.pointer;
> > +	if (obj->type != ACPI_TYPE_BUFFER) {
> > +		pr_err("invalid type : %d\n", obj->type);
> > +		return -EIO;
> > +	}
> > +	memcpy(buffer, obj->buffer.pointer, input.length);
> >
> > -	command.magic = SMI_CMD_MAGIC;
> > -	command.command_address = da_command_address;
> > -	command.command_code = da_command_code;
> > -	command.ebx = virt_to_phys(buffer);
> > -	command.ecx = 0x42534931;
> > +	return 0;
> > +}
> >
> > +void dell_smbios_send_request(int class, int select)
> > +{
> >  	buffer->class = class;
> >  	buffer->select = select;
> > -
> > -	dcdbas_smi_request(&command);
> > +	run_wmi_smbios_call(buffer);
> >  }
> >  EXPORT_SYMBOL_GPL(dell_smbios_send_request);
> >
> > @@ -170,7 +189,7 @@ static void __init find_tokens(const struct dmi_header
> *dm, void *dummy)
> >  	}
> >  }
> >
> > -static int __init dell_smbios_init(void)
> > +static int dell_smbios_probe(struct wmi_device *wdev)
> >  {
> >  	int ret;
> >
> > @@ -181,11 +200,7 @@ static int __init dell_smbios_init(void)
> >  		return -ENODEV;
> >  	}
> >
> > -	/*
> > -	 * Allocate buffer below 4GB for SMI data--only 32-bit physical addr
> > -	 * is passed to SMI handler.
> > -	 */
> > -	buffer = (void *)__get_free_page(GFP_KERNEL | GFP_DMA32);
> > +	buffer = (void *)__get_free_page(GFP_KERNEL);
> >  	if (!buffer) {
> >  		ret = -ENOMEM;
> >  		goto fail_buffer;
> > @@ -198,17 +213,32 @@ static int __init dell_smbios_init(void)
> >  	return ret;
> >  }
> >
> > -static void __exit dell_smbios_exit(void)
> > +static int dell_smbios_remove(struct wmi_device *wdev)
> >  {
> >  	kfree(da_tokens);
> >  	free_page((unsigned long)buffer);
> > +	return 0;
> >  }
> >
> > -subsys_initcall(dell_smbios_init);
> > -module_exit(dell_smbios_exit);
> > +static const struct wmi_device_id dell_smbios_id_table[] = {
> > +	{ .guid_string = DELL_WMI_SMBIOS_GUID },
> > +	{ },
> > +};
> > +
> > +static struct wmi_driver dell_smbios_driver = {
> > +	.driver = {
> > +		.name = "dell-smbios",
> > +	},
> > +	.probe = dell_smbios_probe,
> > +	.remove = dell_smbios_remove,
> > +	.id_table = dell_smbios_id_table,
> > +};
> > +module_wmi_driver(dell_smbios_driver);
> > +
> >
> >  MODULE_AUTHOR("Matthew Garrett <mjg@redhat.com>");
> >  MODULE_AUTHOR("Gabriele Mazzotta <gabriele.mzt@gmail.com>");
> >  MODULE_AUTHOR("Pali Rohár <pali.rohar@gmail.com>");
> > -MODULE_DESCRIPTION("Common functions for kernel modules using Dell
> SMBIOS");
> > +MODULE_AUTHOR("Mario Limonciello <mario.limonciello@dell.com>");
> > +MODULE_DESCRIPTION("Common functions for kernel modules using Dell
> SMBIOS over WMI");
> >  MODULE_LICENSE("GPL");
> > diff --git a/drivers/platform/x86/dell-smbios.h b/drivers/platform/x86/dell-
> smbios.h
> > index 45cbc2292cd3..e1e29697b362 100644
> > --- a/drivers/platform/x86/dell-smbios.h
> > +++ b/drivers/platform/x86/dell-smbios.h
> > @@ -4,6 +4,7 @@
> >   *  Copyright (c) Red Hat <mjg@redhat.com>
> >   *  Copyright (c) 2014 Gabriele Mazzotta <gabriele.mzt@gmail.com>
> >   *  Copyright (c) 2014 Pali Rohár <pali.rohar@gmail.com>
> > + *  Copyright (c) 2017 Dell Inc.
> >   *
> >   *  Based on documentation in the libsmbios package:
> >   *  Copyright (C) 2005-2014 Dell Inc.
> > @@ -18,14 +19,14 @@
> >
> >  struct notifier_block;
> >
> > -/* This structure will be modified by the firmware when we enter
> > - * system management mode, hence the volatiles */
> > -
> >  struct calling_interface_buffer {
> >  	u16 class;
> >  	u16 select;
> > -	volatile u32 input[4];
> > -	volatile u32 output[4];
> > +	u32 input[4];
> > +	u32 output[4];
> > +	u32 argattrib;
> > +	u32 blength;
> > +	u8 data[4052];
> >  } __packed;
> >
> >  struct calling_interface_token {
> 
> --
> Pali Rohár
> pali.rohar@gmail.com

RE: [PATCH 01/12] platform/x86: dell-wmi: label driver as handling notifications

[Mario.Limonciello]

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Monday, September 25, 2017 12:04 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; platform-driver-
> x86@vger.kernel.org; quasisec@google.com
> Subject: Re: [PATCH 01/12] platform/x86: dell-wmi: label driver as handling
> notifications
> 
> On Thursday 21 September 2017 08:57:06 Mario Limonciello wrote:
> > This driver serves the purpose of responding to WMI based notifications
> > from the DELL_EVENT_GUID (9DBB5994-A997-11DA-B012-B622A1EF5492).
> > Other GUIDs will be handled by separate drivers.
> >
> > Update the language used by this driver to avoid future confusion.
> 
> Hi! I'm not sure if if "notifications" word is better then "extras".
> Basically the most important part of the dell-wmi driver is to deliver
> key press events via input device.
> 
> Has anybody else better word or description for this?
> 
I was actually tempted to rename the driver itself to dell-wmi-notifications.
Realistically it is hooking up to the notifications _WED0 AML method so yes
it is picking up notifications exclusively.

I thought about this too, but I can also envision that the notifications that
come through this driver that aren't consumed by the kernel for keypress
purposes are also useful to user space potentially.  It's not part of this series
but maybe in the future providing those through a character device too may
make sense.

> > Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
> > ---
> >  MAINTAINERS                  | 2 +-
> >  drivers/platform/x86/Kconfig | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 2281af4b41b6..5d8ea24a8ee7 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -3996,7 +3996,7 @@ S:	Maintained
> >  F:	Documentation/dcdbas.txt
> >  F:	drivers/firmware/dcdbas.*
> >
> > -DELL WMI EXTRAS DRIVER
> > +DELL WMI NOTIFICATIONS DRIVER
> >  M:	Matthew Garrett <mjg59@srcf.ucam.org>
> >  M:	Pali Rohár <pali.rohar@gmail.com>
> >  S:	Maintained
> > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> > index 80b87954f6dd..9e52f05daa2e 100644
> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
> > @@ -116,7 +116,7 @@ config DELL_LAPTOP
> >  	laptops (except for some models covered by the Compal driver).
> >
> >  config DELL_WMI
> > -	tristate "Dell WMI extras"
> > +	tristate "Dell WMI notifications"
> >  	depends on ACPI_WMI
> >  	depends on DMI
> >  	depends on INPUT
> 
> --
> Pali Rohár
> pali.rohar@gmail.com

RE: [PATCH 01/12] platform/x86: dell-wmi: label driver as handling notifications

[Mario.Limonciello]

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Monday, September 25, 2017 12:04 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; platform-driver-
> x86@vger.kernel.org; quasisec@google.com
> Subject: Re: [PATCH 01/12] platform/x86: dell-wmi: label driver as handling
> notifications
> 
> On Thursday 21 September 2017 08:57:06 Mario Limonciello wrote:
> > This driver serves the purpose of responding to WMI based notifications
> > from the DELL_EVENT_GUID (9DBB5994-A997-11DA-B012-B622A1EF5492).
> > Other GUIDs will be handled by separate drivers.
> >
> > Update the language used by this driver to avoid future confusion.
> 
> Hi! I'm not sure if if "notifications" word is better then "extras".
> Basically the most important part of the dell-wmi driver is to deliver
> key press events via input device.
> 
> Has anybody else better word or description for this?
> 
I was actually tempted to rename the driver itself to dell-wmi-notifications.
Realistically it is hooking up to the notifications _WED0 AML method so yes
it is picking up notifications exclusively.

I thought about this too, but I can also envision that the notifications that
come through this driver that aren't consumed by the kernel for keypress
purposes are also useful to user space potentially.  It's not part of this series
but maybe in the future providing those through a character device too may
make sense.

> > Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
> > ---
> >  MAINTAINERS                  | 2 +-
> >  drivers/platform/x86/Kconfig | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 2281af4b41b6..5d8ea24a8ee7 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -3996,7 +3996,7 @@ S:	Maintained
> >  F:	Documentation/dcdbas.txt
> >  F:	drivers/firmware/dcdbas.*
> >
> > -DELL WMI EXTRAS DRIVER
> > +DELL WMI NOTIFICATIONS DRIVER
> >  M:	Matthew Garrett <mjg59@srcf.ucam.org>
> >  M:	Pali Rohár <pali.rohar@gmail.com>
> >  S:	Maintained
> > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> > index 80b87954f6dd..9e52f05daa2e 100644
> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
> > @@ -116,7 +116,7 @@ config DELL_LAPTOP
> >  	laptops (except for some models covered by the Compal driver).
> >
> >  config DELL_WMI
> > -	tristate "Dell WMI extras"
> > +	tristate "Dell WMI notifications"
> >  	depends on ACPI_WMI
> >  	depends on DMI
> >  	depends on INPUT
> 
> --
> Pali Rohár
> pali.rohar@gmail.com

Re: [PATCH 01/12] platform/x86: dell-wmi: label driver as handling notifications

[Darren Hart]

On Mon, Sep 25, 2017 at 08:14:00PM +0000, Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > Sent: Monday, September 25, 2017 12:04 PM
> > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; platform-driver-
> > x86@vger.kernel.org; quasisec@google.com
> > Subject: Re: [PATCH 01/12] platform/x86: dell-wmi: label driver as handling
> > notifications
> > 
> > On Thursday 21 September 2017 08:57:06 Mario Limonciello wrote:
> > > This driver serves the purpose of responding to WMI based notifications
> > > from the DELL_EVENT_GUID (9DBB5994-A997-11DA-B012-B622A1EF5492).
> > > Other GUIDs will be handled by separate drivers.
> > >
> > > Update the language used by this driver to avoid future confusion.
> > 
> > Hi! I'm not sure if if "notifications" word is better then "extras".
> > Basically the most important part of the dell-wmi driver is to deliver
> > key press events via input device.
> > 
> > Has anybody else better word or description for this?
> > 
> I was actually tempted to rename the driver itself to dell-wmi-notifications.
> Realistically it is hooking up to the notifications _WED0 AML method so yes
> it is picking up notifications exclusively.
> 
> I thought about this too, but I can also envision that the notifications that
> come through this driver that aren't consumed by the kernel for keypress
> purposes are also useful to user space potentially.  It's not part of this series
> but maybe in the future providing those through a character device too may
> make sense.

Naming is hard, but this seems like a reasonable refinement without
over-specifying.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI

[Darren Hart]

On Mon, Sep 25, 2017 at 07:27:24PM +0000, Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > Sent: Monday, September 25, 2017 12:49 PM
> > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > Cc: dvhart@infradead.org; linux-kernel@vger.kernel.org; platform-driver-
> > x86@vger.kernel.org; quasisec@google.com
> > Subject: Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI
> > 
> > On Monday 25 September 2017 16:32:52 Mario.Limonciello@dell.com wrote:
> > > Hi Pali,
> > >
> > > > -----Original Message-----
> > > > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > > > Sent: Monday, September 25, 2017 12:14 PM
> > > > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > > Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; platform-
> > driver-
> > > > x86@vger.kernel.org; quasisec@google.com
> > > > Subject: Re: [PATCH 00/12] Introduce support for Dell SMBIOS over WMI
> > > >
> > > > On Thursday 21 September 2017 08:57:05 Mario Limonciello wrote:
> > > > > The existing way that the dell-smbios helper module and associated
> > > > > other drivers (dell-laptop, dell-wmi) communicate with the platform
> > > > > really isn't secure.  It requires creating a buffer in physical
> > > > > DMA32 memory space and passing that to the platform via SMM.
> > > > >
> > > > > Since the platform got a physical memory pointer, you've just got
> > > > > to trust that the platform has only modified (and accessed) memory
> > > > > within that buffer.
> > > >
> > > > And what is the problem? The whole memory management is done by kernel
> > > > itself, so you already need to trust it.
> > >
> > > There's a lot of ifs, but it's not that crazy of a scenario.
> > >
> > > The problem is that if a malicious payload was delivered to the platform
> > > and exercised a vulnerability in the platform code that payload could
> > > potentially modify memory that it wasn't intended to modify and the OS
> > > would not be aware as operating in SMM.
> > >
> > > >
> > > > > Dell Platform designers recognize this security risk and offer a
> > > > > safer way to communicate with the platform over ACPI.  This is
> > > > > in turn exposed via a WMI interface to the OS.
> > > >
> > > > Hm... I cannot understand how some proprietary ACPI bytecode interpreted
> > > > by kernel can be safer as kernel code itself.
> > > >
> > >
> > > Inherently ACPI can only operate on operation regions and not physical memory.
> > > Data passed into ACPI needs to be copied to an operation region for any ACPI
> > > calls to use it.
> > 
> > But operation regions access is implemented by ACPI interpreter, which
> > is again kernel code.
> 
> So isn't that making my point?
> * Kernel can control operation region accessibility.  SMM can't operate outside
> of this region.
> * Direct SMI gives platform access to everything < 4G, kernel can't control this.

I think there may be some confusion with the term "platform code" - it means
different things to different people. I believe Mario is talking about limiting
memory access to the SMI/SMM code through the use of the ACPI op region in place
of the physical memory pointer, which is not visible nor can it be audited.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI interface

[Darren Hart]

On Mon, Sep 25, 2017 at 07:28:57PM +0000, Mario.Limonciello@dell.com wrote:
> 
> 
> > -----Original Message-----
> > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > Sent: Monday, September 25, 2017 12:19 PM
> > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; platform-driver-
> > x86@vger.kernel.org; quasisec@google.com
> > Subject: Re: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI
> > interface
> > 
> > On Thursday 21 September 2017 08:57:09 Mario Limonciello wrote:
> > > The driver currently uses an SMI interface which grants direct access
> > > to physical memory to the platform via a pointer.
> > >
> > > Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
> > > for a buffer of data storage when platform calls are performed.
> > >
> > > This is a safer approach to use in kernel drivers as the platform will
> > > only have access to that OperationRegion.
> > 
> > In my opinion direct access is safer then using ACPI wrapper for same
> > functionality.
> 
> I'd like to hear how this is safer.

Again, I think the disconnect is around the term "platform". I think above you
can s/platform/SMM/ right?

-- 
Darren Hart
VMware Open Source Technology Center

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

[Darren Hart]

On Mon, Sep 25, 2017 at 05:31:05PM +0000, Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> > Sent: Monday, September 25, 2017 1:04 PM
> > To: Pali Rohár <pali.rohar@gmail.com>
> > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; dvhart@infradead.org;
> > LKML <linux-kernel@vger.kernel.org>; Platform Driver <platform-driver-
> > x86@vger.kernel.org>; quasisec@google.com
> > Subject: Re: [PATCH 06/12] platform/x86: dell-wmi-smbios: Add a sysfs interface
> > for SMBIOS tokens
> > 
> > On Mon, Sep 25, 2017 at 7:23 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > > On Thursday 21 September 2017 08:57:11 Mario Limonciello wrote:
> > >> Currently userspace tools can access system tokens via the dcdbas
> > >> kernel module and a SMI call that will cause the platform to execute
> > >> SMM code.
> > >>
> > >> With a goal in mind of deprecating the dcdbas kernel module a different
> > >> method for accessing these tokens from userspace needs to be created.
> > >>
> > >> This is intentionally marked to only be readable as root as it can
> > >> contain sensitive information about the platform's configuration.
> > >
> > > 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.

> 
> > 
> > > 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.


-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character device for userspace

[Darren Hart]

On Mon, Sep 25, 2017 at 05:46:54PM +0000, Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> > Sent: Monday, September 25, 2017 12:58 PM
> > To: Pali Rohár <pali.rohar@gmail.com>
> > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; dvhart@infradead.org;
> > LKML <linux-kernel@vger.kernel.org>; Platform Driver <platform-driver-
> > x86@vger.kernel.org>; quasisec@google.com
> > Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character
> > device for userspace
> > 
> > On Mon, Sep 25, 2017 at 7:31 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > > On Thursday 21 September 2017 08:57:16 Mario Limonciello wrote:
> > >> This userspace character device will be used to perform SMBIOS calls
> > >> from any applications sending a properly formatted 4k calling interface
> > >> buffer.
> > >>
> > >> This character device is intended to deprecate the dcdbas kernel module
> > >> and the interface that it provides to userspace.
> > >>
> > >> It's important for the driver to provide a R/W ioctl to ensure that
> > >> two competing userspace processes don't race to provide or read each
> > >> others data.
> > 
> > >> +What:                /dev/wmi-dell-wmi-smbios
> > >
> > > What about just /dev/dell-smbios? IOCTL provided here is just SMBIOS
> > > related and I think userspace does not have to care if it is via WMI or
> > > direct SMM mode... Important is that it provides character device for
> > > SMBIOS API and not how it is implemented.

I agree with this point, the implementation (WMI under the covers) is
not relevant. That said, this is an example of exposing WMI
functionality to userspace, and I DO NOT want to have a naming
discussion for every single WMI GUID that we choose to expose.

> > >
> > > Anyway, Darren, Andy, do we have some convention for naming platform
> > > character devices?
> > 
> > For me, looking to this case, seems better to expose a folder like
> > /dev/smbios/
> > with actual vendor device nodes inside like
> > /dev/smbios/dell
> 
> I disagree with this.  Dell exposes smbios calling in this kernel interface but
> other vendor drivers may also expose different methods for character devices
> that are not SMBIOS.
> 
> I'm envisioning that this is just the first kernel module that will use a WMI
> character device to userspace.  That's why I wanted to use a generic namespace.
> 
> I would say it could be /dev/wmi-$GUID or /dev/wmi/$driver-$GUID if you want 
> something more generic.
> As long as it's discovereable from uevent that's fine to me.
> 
> > 
> > Darren?

I would like to see an automated and definiitive way to export WMI
GUIDs. Something we can look at, compare to a set of rules, and say
yay/nay. From that perspective, I like Mario's general proposal. It is
not clear to me if the $driver- prefix adds any value though - would we
ever have need of DRIVER_X-GUID_A and DRIVER_Y-GUID_A ??? I'm thinking
not.

/dev/wmi/$GUID

-- 
Darren Hart
VMware Open Source Technology Center

RE: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character device for userspace

[Mario.Limonciello]

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Wednesday, September 27, 2017 1:00 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: andy.shevchenko@gmail.com; pali.rohar@gmail.com; linux-
> kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org;
> quasisec@google.com
> Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character
> device for userspace
> 
> On Mon, Sep 25, 2017 at 05:46:54PM +0000, Mario.Limonciello@dell.com wrote:
> > > -----Original Message-----
> > > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> > > Sent: Monday, September 25, 2017 12:58 PM
> > > To: Pali Rohár <pali.rohar@gmail.com>
> > > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; dvhart@infradead.org;
> > > LKML <linux-kernel@vger.kernel.org>; Platform Driver <platform-driver-
> > > x86@vger.kernel.org>; quasisec@google.com
> > > Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character
> > > device for userspace
> > >
> > > On Mon, Sep 25, 2017 at 7:31 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > > > On Thursday 21 September 2017 08:57:16 Mario Limonciello wrote:
> > > >> This userspace character device will be used to perform SMBIOS calls
> > > >> from any applications sending a properly formatted 4k calling interface
> > > >> buffer.
> > > >>
> > > >> This character device is intended to deprecate the dcdbas kernel module
> > > >> and the interface that it provides to userspace.
> > > >>
> > > >> It's important for the driver to provide a R/W ioctl to ensure that
> > > >> two competing userspace processes don't race to provide or read each
> > > >> others data.
> > >
> > > >> +What:                /dev/wmi-dell-wmi-smbios
> > > >
> > > > What about just /dev/dell-smbios? IOCTL provided here is just SMBIOS
> > > > related and I think userspace does not have to care if it is via WMI or
> > > > direct SMM mode... Important is that it provides character device for
> > > > SMBIOS API and not how it is implemented.
> 
> I agree with this point, the implementation (WMI under the covers) is
> not relevant. That said, this is an example of exposing WMI
> functionality to userspace, and I DO NOT want to have a naming
> discussion for every single WMI GUID that we choose to expose.

Yes, I agree let's make sure it's stable and automatic for all drivers that will use it.

> 
> > > >
> > > > Anyway, Darren, Andy, do we have some convention for naming platform
> > > > character devices?
> > >
> > > For me, looking to this case, seems better to expose a folder like
> > > /dev/smbios/
> > > with actual vendor device nodes inside like
> > > /dev/smbios/dell
> >
> > I disagree with this.  Dell exposes smbios calling in this kernel interface but
> > other vendor drivers may also expose different methods for character devices
> > that are not SMBIOS.
> >
> > I'm envisioning that this is just the first kernel module that will use a WMI
> > character device to userspace.  That's why I wanted to use a generic namespace.
> >
> > I would say it could be /dev/wmi-$GUID or /dev/wmi/$driver-$GUID if you want
> > something more generic.
> > As long as it's discovereable from uevent that's fine to me.
> >
> > >
> > > Darren?
> 
> I would like to see an automated and definiitive way to export WMI
> GUIDs. Something we can look at, compare to a set of rules, and say
> yay/nay. From that perspective, I like Mario's general proposal. It is
> not clear to me if the $driver- prefix adds any value though - would we
> ever have need of DRIVER_X-GUID_A and DRIVER_Y-GUID_A ??? I'm thinking
> not.
> 
> /dev/wmi/$GUID
> 

I don't think you should allow two drivers to use the same GUID, but what if
a driver needs to use multiple GUIDs?

This obviously isn't a problem yet.
I envision that as we get MOF interpretation as part of the bus we "may" get into 
that situation with more complicated MOF design.  The vendor driver could 
register with the bus for each GUID and  request a character device for each but 
that's meaning userspace has to worry about knowing which GUIDs do what.  
I think it's potentially asking for a complicated interface to userspace for the future.

Here's a hypothetical scenario based on some more advanced MOF design I know of:

Separate GUID provided for each:
* All integer settings (data type)
* All string settings (data type)
* Notifications (event type)
* enumeration types (data type)
* Applying a Setting (method type)
* Managing users (method type)

How would a new driver for that look?  I would think you would want one driver to register
and encapsulate at least all of those GUIDs.

I would say all the data should be exported into sysfs, but that you really only want
one character device that is used for both methods.

The interface to userspace would then have two IOCTL's that the driver would internally
apply to the correct GUID.  Example: 
"/dev/wmi/$driver" supports 2 different IOCTL's.
Internally the driver would then ferry the request through the WMI bus to the correct
GUID based on the ioctl call number.

If you went with the pass the GUID information up and create character device for each
GUID, userspace will have to know:
"I use /dev/wmi/$GUID_X" for applying the setting IOCTL on Acme Inc machine.
And
"I use /dev/wmi/$GUID_Y" for managing users IOCTL on Acme Inc machine.

And what if the notifications are valuable to userspace?  Would you want to create another
character device for those?  I think you would just want to keep them in the same device
and add a poll/select file operation.

RE: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character device for userspace

[Mario.Limonciello]

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Wednesday, September 27, 2017 1:00 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: andy.shevchenko@gmail.com; pali.rohar@gmail.com; linux-
> kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org;
> quasisec@google.com
> Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character
> device for userspace
> 
> On Mon, Sep 25, 2017 at 05:46:54PM +0000, Mario.Limonciello@dell.com wrote:
> > > -----Original Message-----
> > > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> > > Sent: Monday, September 25, 2017 12:58 PM
> > > To: Pali Rohár <pali.rohar@gmail.com>
> > > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; dvhart@infradead.org;
> > > LKML <linux-kernel@vger.kernel.org>; Platform Driver <platform-driver-
> > > x86@vger.kernel.org>; quasisec@google.com
> > > Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character
> > > device for userspace
> > >
> > > On Mon, Sep 25, 2017 at 7:31 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > > > On Thursday 21 September 2017 08:57:16 Mario Limonciello wrote:
> > > >> This userspace character device will be used to perform SMBIOS calls
> > > >> from any applications sending a properly formatted 4k calling interface
> > > >> buffer.
> > > >>
> > > >> This character device is intended to deprecate the dcdbas kernel module
> > > >> and the interface that it provides to userspace.
> > > >>
> > > >> It's important for the driver to provide a R/W ioctl to ensure that
> > > >> two competing userspace processes don't race to provide or read each
> > > >> others data.
> > >
> > > >> +What:                /dev/wmi-dell-wmi-smbios
> > > >
> > > > What about just /dev/dell-smbios? IOCTL provided here is just SMBIOS
> > > > related and I think userspace does not have to care if it is via WMI or
> > > > direct SMM mode... Important is that it provides character device for
> > > > SMBIOS API and not how it is implemented.
> 
> I agree with this point, the implementation (WMI under the covers) is
> not relevant. That said, this is an example of exposing WMI
> functionality to userspace, and I DO NOT want to have a naming
> discussion for every single WMI GUID that we choose to expose.

Yes, I agree let's make sure it's stable and automatic for all drivers that will use it.

> 
> > > >
> > > > Anyway, Darren, Andy, do we have some convention for naming platform
> > > > character devices?
> > >
> > > For me, looking to this case, seems better to expose a folder like
> > > /dev/smbios/
> > > with actual vendor device nodes inside like
> > > /dev/smbios/dell
> >
> > I disagree with this.  Dell exposes smbios calling in this kernel interface but
> > other vendor drivers may also expose different methods for character devices
> > that are not SMBIOS.
> >
> > I'm envisioning that this is just the first kernel module that will use a WMI
> > character device to userspace.  That's why I wanted to use a generic namespace.
> >
> > I would say it could be /dev/wmi-$GUID or /dev/wmi/$driver-$GUID if you want
> > something more generic.
> > As long as it's discovereable from uevent that's fine to me.
> >
> > >
> > > Darren?
> 
> I would like to see an automated and definiitive way to export WMI
> GUIDs. Something we can look at, compare to a set of rules, and say
> yay/nay. From that perspective, I like Mario's general proposal. It is
> not clear to me if the $driver- prefix adds any value though - would we
> ever have need of DRIVER_X-GUID_A and DRIVER_Y-GUID_A ??? I'm thinking
> not.
> 
> /dev/wmi/$GUID
> 

I don't think you should allow two drivers to use the same GUID, but what if
a driver needs to use multiple GUIDs?

This obviously isn't a problem yet.
I envision that as we get MOF interpretation as part of the bus we "may" get into 
that situation with more complicated MOF design.  The vendor driver could 
register with the bus for each GUID and  request a character device for each but 
that's meaning userspace has to worry about knowing which GUIDs do what.  
I think it's potentially asking for a complicated interface to userspace for the future.

Here's a hypothetical scenario based on some more advanced MOF design I know of:

Separate GUID provided for each:
* All integer settings (data type)
* All string settings (data type)
* Notifications (event type)
* enumeration types (data type)
* Applying a Setting (method type)
* Managing users (method type)

How would a new driver for that look?  I would think you would want one driver to register
and encapsulate at least all of those GUIDs.

I would say all the data should be exported into sysfs, but that you really only want
one character device that is used for both methods.

The interface to userspace would then have two IOCTL's that the driver would internally
apply to the correct GUID.  Example: 
"/dev/wmi/$driver" supports 2 different IOCTL's.
Internally the driver would then ferry the request through the WMI bus to the correct
GUID based on the ioctl call number.

If you went with the pass the GUID information up and create character device for each
GUID, userspace will have to know:
"I use /dev/wmi/$GUID_X" for applying the setting IOCTL on Acme Inc machine.
And
"I use /dev/wmi/$GUID_Y" for managing users IOCTL on Acme Inc machine.

And what if the notifications are valuable to userspace?  Would you want to create another
character device for those?  I think you would just want to keep them in the same device
and add a poll/select file operation.

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

[Mario.Limonciello]

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Wednesday, September 27, 2017 12:51 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: andy.shevchenko@gmail.com; pali.rohar@gmail.com; linux-
> kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org;
> quasisec@google.com
> Subject: Re: [PATCH 06/12] platform/x86: dell-wmi-smbios: Add a sysfs interface
> for SMBIOS tokens
> 
> On Mon, Sep 25, 2017 at 05:31:05PM +0000, Mario.Limonciello@dell.com wrote:
> > > -----Original Message-----
> > > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> > > Sent: Monday, September 25, 2017 1:04 PM
> > > To: Pali Rohár <pali.rohar@gmail.com>
> > > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; dvhart@infradead.org;
> > > LKML <linux-kernel@vger.kernel.org>; Platform Driver <platform-driver-
> > > x86@vger.kernel.org>; quasisec@google.com
> > > Subject: Re: [PATCH 06/12] platform/x86: dell-wmi-smbios: Add a sysfs
> interface
> > > for SMBIOS tokens
> > >
> > > On Mon, Sep 25, 2017 at 7:23 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > > > On Thursday 21 September 2017 08:57:11 Mario Limonciello wrote:
> > > >> Currently userspace tools can access system tokens via the dcdbas
> > > >> kernel module and a SMI call that will cause the platform to execute
> > > >> SMM code.
> > > >>
> > > >> With a goal in mind of deprecating the dcdbas kernel module a different
> > > >> method for accessing these tokens from userspace needs to be created.
> > > >>
> > > >> This is intentionally marked to only be readable as root as it can
> > > >> contain sensitive information about the platform's configuration.
> > > >
> > > > 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?

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

[Mario.Limonciello]

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Wednesday, September 27, 2017 12:51 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: andy.shevchenko@gmail.com; pali.rohar@gmail.com; linux-
> kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org;
> quasisec@google.com
> Subject: Re: [PATCH 06/12] platform/x86: dell-wmi-smbios: Add a sysfs interface
> for SMBIOS tokens
> 
> On Mon, Sep 25, 2017 at 05:31:05PM +0000, Mario.Limonciello@dell.com wrote:
> > > -----Original Message-----
> > > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> > > Sent: Monday, September 25, 2017 1:04 PM
> > > To: Pali Rohár <pali.rohar@gmail.com>
> > > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; dvhart@infradead.org;
> > > LKML <linux-kernel@vger.kernel.org>; Platform Driver <platform-driver-
> > > x86@vger.kernel.org>; quasisec@google.com
> > > Subject: Re: [PATCH 06/12] platform/x86: dell-wmi-smbios: Add a sysfs
> interface
> > > for SMBIOS tokens
> > >
> > > On Mon, Sep 25, 2017 at 7:23 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > > > On Thursday 21 September 2017 08:57:11 Mario Limonciello wrote:
> > > >> Currently userspace tools can access system tokens via the dcdbas
> > > >> kernel module and a SMI call that will cause the platform to execute
> > > >> SMM code.
> > > >>
> > > >> With a goal in mind of deprecating the dcdbas kernel module a different
> > > >> method for accessing these tokens from userspace needs to be created.
> > > >>
> > > >> This is intentionally marked to only be readable as root as it can
> > > >> contain sensitive information about the platform's configuration.
> > > >
> > > > 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?

RE: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI interface

[Mario.Limonciello]

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Wednesday, September 27, 2017 12:46 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: pali.rohar@gmail.com; linux-kernel@vger.kernel.org; platform-driver-
> x86@vger.kernel.org; quasisec@google.com
> Subject: Re: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI
> interface
> 
> On Mon, Sep 25, 2017 at 07:28:57PM +0000, Mario.Limonciello@dell.com wrote:
> >
> >
> > > -----Original Message-----
> > > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > > Sent: Monday, September 25, 2017 12:19 PM
> > > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; platform-
> driver-
> > > x86@vger.kernel.org; quasisec@google.com
> > > Subject: Re: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI
> > > interface
> > >
> > > On Thursday 21 September 2017 08:57:09 Mario Limonciello wrote:
> > > > The driver currently uses an SMI interface which grants direct access
> > > > to physical memory to the platform via a pointer.
> > > >
> > > > Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
> > > > for a buffer of data storage when platform calls are performed.
> > > >
> > > > This is a safer approach to use in kernel drivers as the platform will
> > > > only have access to that OperationRegion.
> > >
> > > In my opinion direct access is safer then using ACPI wrapper for same
> > > functionality.
> >
> > I'd like to hear how this is safer.
> 
> Again, I think the disconnect is around the term "platform". I think above you
> can s/platform/SMM/ right?
> 

>From my OEM hat we don't really refer to SMM as an entity, but "Yeah" if that
makes it clearer I'd agree.

RE: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI interface

[Mario.Limonciello]

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Wednesday, September 27, 2017 12:46 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: pali.rohar@gmail.com; linux-kernel@vger.kernel.org; platform-driver-
> x86@vger.kernel.org; quasisec@google.com
> Subject: Re: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI
> interface
> 
> On Mon, Sep 25, 2017 at 07:28:57PM +0000, Mario.Limonciello@dell.com wrote:
> >
> >
> > > -----Original Message-----
> > > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > > Sent: Monday, September 25, 2017 12:19 PM
> > > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > Cc: dvhart@infradead.org; LKML <linux-kernel@vger.kernel.org>; platform-
> driver-
> > > x86@vger.kernel.org; quasisec@google.com
> > > Subject: Re: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI
> > > interface
> > >
> > > On Thursday 21 September 2017 08:57:09 Mario Limonciello wrote:
> > > > The driver currently uses an SMI interface which grants direct access
> > > > to physical memory to the platform via a pointer.
> > > >
> > > > Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
> > > > for a buffer of data storage when platform calls are performed.
> > > >
> > > > This is a safer approach to use in kernel drivers as the platform will
> > > > only have access to that OperationRegion.
> > >
> > > In my opinion direct access is safer then using ACPI wrapper for same
> > > functionality.
> >
> > I'd like to hear how this is safer.
> 
> Again, I think the disconnect is around the term "platform". I think above you
> can s/platform/SMM/ right?
> 

From my OEM hat we don't really refer to SMM as an entity, but "Yeah" if that
makes it clearer I'd agree.

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

[Andy Shevchenko]

On Wed, Sep 27, 2017 at 9:27 PM,  <Mario.Limonciello@dell.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.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character device for userspace

[Darren Hart]

On Wed, Sep 27, 2017 at 06:10:55PM +0000, Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Darren Hart [mailto:dvhart@infradead.org]
> > Sent: Wednesday, September 27, 2017 1:00 PM
> > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > Cc: andy.shevchenko@gmail.com; pali.rohar@gmail.com; linux-
> > kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org;
> > quasisec@google.com
> > Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character
> > device for userspace
> > 
> > On Mon, Sep 25, 2017 at 05:46:54PM +0000, Mario.Limonciello@dell.com wrote:
> > > > -----Original Message-----
> > > > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> > > > Sent: Monday, September 25, 2017 12:58 PM
> > > > To: Pali Rohár <pali.rohar@gmail.com>
> > > > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; dvhart@infradead.org;
> > > > LKML <linux-kernel@vger.kernel.org>; Platform Driver <platform-driver-
> > > > x86@vger.kernel.org>; quasisec@google.com
> > > > Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character
> > > > device for userspace
> > > >
> > > > On Mon, Sep 25, 2017 at 7:31 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > > > > On Thursday 21 September 2017 08:57:16 Mario Limonciello wrote:
> > > > >> This userspace character device will be used to perform SMBIOS calls
> > > > >> from any applications sending a properly formatted 4k calling interface
> > > > >> buffer.
> > > > >>
> > > > >> This character device is intended to deprecate the dcdbas kernel module
> > > > >> and the interface that it provides to userspace.
> > > > >>
> > > > >> It's important for the driver to provide a R/W ioctl to ensure that
> > > > >> two competing userspace processes don't race to provide or read each
> > > > >> others data.
> > > >
> > > > >> +What:                /dev/wmi-dell-wmi-smbios
> > > > >
> > > > > What about just /dev/dell-smbios? IOCTL provided here is just SMBIOS
> > > > > related and I think userspace does not have to care if it is via WMI or
> > > > > direct SMM mode... Important is that it provides character device for
> > > > > SMBIOS API and not how it is implemented.
> > 
> > I agree with this point, the implementation (WMI under the covers) is
> > not relevant. That said, this is an example of exposing WMI
> > functionality to userspace, and I DO NOT want to have a naming
> > discussion for every single WMI GUID that we choose to expose.
> 
> Yes, I agree let's make sure it's stable and automatic for all drivers that will use it.
> 
> > 
> > > > >
> > > > > Anyway, Darren, Andy, do we have some convention for naming platform
> > > > > character devices?
> > > >
> > > > For me, looking to this case, seems better to expose a folder like
> > > > /dev/smbios/
> > > > with actual vendor device nodes inside like
> > > > /dev/smbios/dell
> > >
> > > I disagree with this.  Dell exposes smbios calling in this kernel interface but
> > > other vendor drivers may also expose different methods for character devices
> > > that are not SMBIOS.
> > >
> > > I'm envisioning that this is just the first kernel module that will use a WMI
> > > character device to userspace.  That's why I wanted to use a generic namespace.
> > >
> > > I would say it could be /dev/wmi-$GUID or /dev/wmi/$driver-$GUID if you want
> > > something more generic.
> > > As long as it's discovereable from uevent that's fine to me.
> > >
> > > >
> > > > Darren?
> > 
> > I would like to see an automated and definiitive way to export WMI
> > GUIDs. Something we can look at, compare to a set of rules, and say
> > yay/nay. From that perspective, I like Mario's general proposal. It is
> > not clear to me if the $driver- prefix adds any value though - would we
> > ever have need of DRIVER_X-GUID_A and DRIVER_Y-GUID_A ??? I'm thinking
> > not.
> > 
> > /dev/wmi/$GUID
> > 
> 
> I don't think you should allow two drivers to use the same GUID, but what if
> a driver needs to use multiple GUIDs?
> 
> This obviously isn't a problem yet.
> I envision that as we get MOF interpretation as part of the bus we "may" get into 
> that situation with more complicated MOF design.  The vendor driver could 
> register with the bus for each GUID and  request a character device for each but 
> that's meaning userspace has to worry about knowing which GUIDs do what.  
> I think it's potentially asking for a complicated interface to userspace for the future.
> 
> Here's a hypothetical scenario based on some more advanced MOF design I know of:
> 
> Separate GUID provided for each:
> * All integer settings (data type)
> * All string settings (data type)
> * Notifications (event type)
> * enumeration types (data type)
> * Applying a Setting (method type)
> * Managing users (method type)
> 
> How would a new driver for that look?  I would think you would want one driver to register
> and encapsulate at least all of those GUIDs.
> 
> I would say all the data should be exported into sysfs, but that you really only want
> one character device that is used for both methods.
> 
> The interface to userspace would then have two IOCTL's that the driver would internally
> apply to the correct GUID.  Example: 
> "/dev/wmi/$driver" supports 2 different IOCTL's.
> Internally the driver would then ferry the request through the WMI bus to the correct
> GUID based on the ioctl call number.
> 
> If you went with the pass the GUID information up and create character device for each
> GUID, userspace will have to know:
> "I use /dev/wmi/$GUID_X" for applying the setting IOCTL on Acme Inc machine.
> And
> "I use /dev/wmi/$GUID_Y" for managing users IOCTL on Acme Inc machine.
> 
> And what if the notifications are valuable to userspace?  Would you want to create another
> character device for those?  I think you would just want to keep them in the same device
> and add a poll/select file operation.
> 

Thanks for the concrete example, this helps a lot.

One guiding principle of this series and something Pali correctly pointed out,
is that for Linux, we're keeping WMI as the implementation and exposing features
to userspace through char devs and IOCTLS. You points above are consistent with
that theme, and the GUIDs are not an appropriate namespace.

The driver namespace does make more sense as you suggested above:

/dev/wmi/$driver

This still has wmi in the name, but given that is the bus name, I think it's a
reasonable way organize the files - and is still a well-defined naming scheme.

-- 
Darren Hart
VMware Open Source Technology Center

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

[Darren Hart]

On Wed, Sep 27, 2017 at 09:31:47PM +0300, Andy Shevchenko wrote:
> On Wed, Sep 27, 2017 at 9:27 PM,  <Mario.Limonciello@dell.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?

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI interface

[Andy Lutomirski]

On 09/21/2017 06:57 AM, Mario Limonciello wrote:
> The driver currently uses an SMI interface which grants direct access
> to physical memory to the platform via a pointer.
> 
> Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
> for a buffer of data storage when platform calls are performed.
> 
> This is a safer approach to use in kernel drivers as the platform will
> only have access to that OperationRegion.
> 
> As a result, this change removes the dependency on this driver on the
> dcdbas kernel module.
> 

> +	status = wmi_evaluate_method(DELL_WMI_SMBIOS_GUID,
> +				     0, 1, &input, &output);

It might be nice to add a wmidev_method_evaluate(struct wmi_device 
*wdev, ...) function to better aligh with the new world order.  The only 
reason I didn't do it is that I didn't convert any drivers that wanted it.

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

[Andy Lutomirski]

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@dell.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.

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

[Mario.Limonciello]

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@kernel.org]
> Sent: Wednesday, September 27, 2017 3:49 PM
> To: Darren Hart <dvhart@infradead.org>; Andy Shevchenko
> <andy.shevchenko@gmail.com>; Andy Lutomirski <luto@amacapital.net>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; Pali Rohár
> <pali.rohar@gmail.com>; linux-kernel@vger.kernel.org; Platform Driver <platform-
> driver-x86@vger.kernel.org>; quasisec@google.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@dell.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.

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

[Mario.Limonciello]

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@kernel.org]
> Sent: Wednesday, September 27, 2017 3:49 PM
> To: Darren Hart <dvhart@infradead.org>; Andy Shevchenko
> <andy.shevchenko@gmail.com>; Andy Lutomirski <luto@amacapital.net>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; Pali Rohár
> <pali.rohar@gmail.com>; linux-kernel@vger.kernel.org; Platform Driver <platform-
> driver-x86@vger.kernel.org>; quasisec@google.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@dell.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.

RE: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character device for userspace

[Mario.Limonciello]

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Wednesday, September 27, 2017 2:50 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: andy.shevchenko@gmail.com; pali.rohar@gmail.com; linux-
> kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org;
> quasisec@google.com
> Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character
> device for userspace
> 
> On Wed, Sep 27, 2017 at 06:10:55PM +0000, Mario.Limonciello@dell.com wrote:
> > > -----Original Message-----
> > > From: Darren Hart [mailto:dvhart@infradead.org]
> > > Sent: Wednesday, September 27, 2017 1:00 PM
> > > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > Cc: andy.shevchenko@gmail.com; pali.rohar@gmail.com; linux-
> > > kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org;
> > > quasisec@google.com
> > > Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character
> > > device for userspace
> > >
> > > On Mon, Sep 25, 2017 at 05:46:54PM +0000, Mario.Limonciello@dell.com
> wrote:
> > > > > -----Original Message-----
> > > > > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> > > > > Sent: Monday, September 25, 2017 12:58 PM
> > > > > To: Pali Rohár <pali.rohar@gmail.com>
> > > > > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>;
> dvhart@infradead.org;
> > > > > LKML <linux-kernel@vger.kernel.org>; Platform Driver <platform-driver-
> > > > > x86@vger.kernel.org>; quasisec@google.com
> > > > > Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce
> character
> > > > > device for userspace
> > > > >
> > > > > On Mon, Sep 25, 2017 at 7:31 PM, Pali Rohár <pali.rohar@gmail.com>
> wrote:
> > > > > > On Thursday 21 September 2017 08:57:16 Mario Limonciello wrote:
> > > > > >> This userspace character device will be used to perform SMBIOS calls
> > > > > >> from any applications sending a properly formatted 4k calling interface
> > > > > >> buffer.
> > > > > >>
> > > > > >> This character device is intended to deprecate the dcdbas kernel module
> > > > > >> and the interface that it provides to userspace.
> > > > > >>
> > > > > >> It's important for the driver to provide a R/W ioctl to ensure that
> > > > > >> two competing userspace processes don't race to provide or read each
> > > > > >> others data.
> > > > >
> > > > > >> +What:                /dev/wmi-dell-wmi-smbios
> > > > > >
> > > > > > What about just /dev/dell-smbios? IOCTL provided here is just SMBIOS
> > > > > > related and I think userspace does not have to care if it is via WMI or
> > > > > > direct SMM mode... Important is that it provides character device for
> > > > > > SMBIOS API and not how it is implemented.
> > >
> > > I agree with this point, the implementation (WMI under the covers) is
> > > not relevant. That said, this is an example of exposing WMI
> > > functionality to userspace, and I DO NOT want to have a naming
> > > discussion for every single WMI GUID that we choose to expose.
> >
> > Yes, I agree let's make sure it's stable and automatic for all drivers that will use it.
> >
> > >
> > > > > >
> > > > > > Anyway, Darren, Andy, do we have some convention for naming platform
> > > > > > character devices?
> > > > >
> > > > > For me, looking to this case, seems better to expose a folder like
> > > > > /dev/smbios/
> > > > > with actual vendor device nodes inside like
> > > > > /dev/smbios/dell
> > > >
> > > > I disagree with this.  Dell exposes smbios calling in this kernel interface but
> > > > other vendor drivers may also expose different methods for character devices
> > > > that are not SMBIOS.
> > > >
> > > > I'm envisioning that this is just the first kernel module that will use a WMI
> > > > character device to userspace.  That's why I wanted to use a generic
> namespace.
> > > >
> > > > I would say it could be /dev/wmi-$GUID or /dev/wmi/$driver-$GUID if you
> want
> > > > something more generic.
> > > > As long as it's discovereable from uevent that's fine to me.
> > > >
> > > > >
> > > > > Darren?
> > >
> > > I would like to see an automated and definiitive way to export WMI
> > > GUIDs. Something we can look at, compare to a set of rules, and say
> > > yay/nay. From that perspective, I like Mario's general proposal. It is
> > > not clear to me if the $driver- prefix adds any value though - would we
> > > ever have need of DRIVER_X-GUID_A and DRIVER_Y-GUID_A ??? I'm thinking
> > > not.
> > >
> > > /dev/wmi/$GUID
> > >
> >
> > I don't think you should allow two drivers to use the same GUID, but what if
> > a driver needs to use multiple GUIDs?
> >
> > This obviously isn't a problem yet.
> > I envision that as we get MOF interpretation as part of the bus we "may" get into
> > that situation with more complicated MOF design.  The vendor driver could
> > register with the bus for each GUID and  request a character device for each but
> > that's meaning userspace has to worry about knowing which GUIDs do what.
> > I think it's potentially asking for a complicated interface to userspace for the
> future.
> >
> > Here's a hypothetical scenario based on some more advanced MOF design I know
> of:
> >
> > Separate GUID provided for each:
> > * All integer settings (data type)
> > * All string settings (data type)
> > * Notifications (event type)
> > * enumeration types (data type)
> > * Applying a Setting (method type)
> > * Managing users (method type)
> >
> > How would a new driver for that look?  I would think you would want one driver
> to register
> > and encapsulate at least all of those GUIDs.
> >
> > I would say all the data should be exported into sysfs, but that you really only
> want
> > one character device that is used for both methods.
> >
> > The interface to userspace would then have two IOCTL's that the driver would
> internally
> > apply to the correct GUID.  Example:
> > "/dev/wmi/$driver" supports 2 different IOCTL's.
> > Internally the driver would then ferry the request through the WMI bus to the
> correct
> > GUID based on the ioctl call number.
> >
> > If you went with the pass the GUID information up and create character device for
> each
> > GUID, userspace will have to know:
> > "I use /dev/wmi/$GUID_X" for applying the setting IOCTL on Acme Inc machine.
> > And
> > "I use /dev/wmi/$GUID_Y" for managing users IOCTL on Acme Inc machine.
> >
> > And what if the notifications are valuable to userspace?  Would you want to
> create another
> > character device for those?  I think you would just want to keep them in the same
> device
> > and add a poll/select file operation.
> >
> 
> Thanks for the concrete example, this helps a lot.
> 
> One guiding principle of this series and something Pali correctly pointed out,
> is that for Linux, we're keeping WMI as the implementation and exposing features
> to userspace through char devs and IOCTLS. You points above are consistent with
> that theme, and the GUIDs are not an appropriate namespace.
> 
> The driver namespace does make more sense as you suggested above:
> 
> /dev/wmi/$driver
> 
> This still has wmi in the name, but given that is the bus name, I think it's a
> reasonable way organize the files - and is still a well-defined naming scheme.
> 

Thanks Darren.  I'll adjust the patch.
Would you like me to document this chosen policy somewhere in Documentation?
If so, where?
Or to put more about our conversation in the commit message? 

RE: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character device for userspace

[Mario.Limonciello]

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Wednesday, September 27, 2017 2:50 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: andy.shevchenko@gmail.com; pali.rohar@gmail.com; linux-
> kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org;
> quasisec@google.com
> Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character
> device for userspace
> 
> On Wed, Sep 27, 2017 at 06:10:55PM +0000, Mario.Limonciello@dell.com wrote:
> > > -----Original Message-----
> > > From: Darren Hart [mailto:dvhart@infradead.org]
> > > Sent: Wednesday, September 27, 2017 1:00 PM
> > > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > Cc: andy.shevchenko@gmail.com; pali.rohar@gmail.com; linux-
> > > kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org;
> > > quasisec@google.com
> > > Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character
> > > device for userspace
> > >
> > > On Mon, Sep 25, 2017 at 05:46:54PM +0000, Mario.Limonciello@dell.com
> wrote:
> > > > > -----Original Message-----
> > > > > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> > > > > Sent: Monday, September 25, 2017 12:58 PM
> > > > > To: Pali Rohár <pali.rohar@gmail.com>
> > > > > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>;
> dvhart@infradead.org;
> > > > > LKML <linux-kernel@vger.kernel.org>; Platform Driver <platform-driver-
> > > > > x86@vger.kernel.org>; quasisec@google.com
> > > > > Subject: Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce
> character
> > > > > device for userspace
> > > > >
> > > > > On Mon, Sep 25, 2017 at 7:31 PM, Pali Rohár <pali.rohar@gmail.com>
> wrote:
> > > > > > On Thursday 21 September 2017 08:57:16 Mario Limonciello wrote:
> > > > > >> This userspace character device will be used to perform SMBIOS calls
> > > > > >> from any applications sending a properly formatted 4k calling interface
> > > > > >> buffer.
> > > > > >>
> > > > > >> This character device is intended to deprecate the dcdbas kernel module
> > > > > >> and the interface that it provides to userspace.
> > > > > >>
> > > > > >> It's important for the driver to provide a R/W ioctl to ensure that
> > > > > >> two competing userspace processes don't race to provide or read each
> > > > > >> others data.
> > > > >
> > > > > >> +What:                /dev/wmi-dell-wmi-smbios
> > > > > >
> > > > > > What about just /dev/dell-smbios? IOCTL provided here is just SMBIOS
> > > > > > related and I think userspace does not have to care if it is via WMI or
> > > > > > direct SMM mode... Important is that it provides character device for
> > > > > > SMBIOS API and not how it is implemented.
> > >
> > > I agree with this point, the implementation (WMI under the covers) is
> > > not relevant. That said, this is an example of exposing WMI
> > > functionality to userspace, and I DO NOT want to have a naming
> > > discussion for every single WMI GUID that we choose to expose.
> >
> > Yes, I agree let's make sure it's stable and automatic for all drivers that will use it.
> >
> > >
> > > > > >
> > > > > > Anyway, Darren, Andy, do we have some convention for naming platform
> > > > > > character devices?
> > > > >
> > > > > For me, looking to this case, seems better to expose a folder like
> > > > > /dev/smbios/
> > > > > with actual vendor device nodes inside like
> > > > > /dev/smbios/dell
> > > >
> > > > I disagree with this.  Dell exposes smbios calling in this kernel interface but
> > > > other vendor drivers may also expose different methods for character devices
> > > > that are not SMBIOS.
> > > >
> > > > I'm envisioning that this is just the first kernel module that will use a WMI
> > > > character device to userspace.  That's why I wanted to use a generic
> namespace.
> > > >
> > > > I would say it could be /dev/wmi-$GUID or /dev/wmi/$driver-$GUID if you
> want
> > > > something more generic.
> > > > As long as it's discovereable from uevent that's fine to me.
> > > >
> > > > >
> > > > > Darren?
> > >
> > > I would like to see an automated and definiitive way to export WMI
> > > GUIDs. Something we can look at, compare to a set of rules, and say
> > > yay/nay. From that perspective, I like Mario's general proposal. It is
> > > not clear to me if the $driver- prefix adds any value though - would we
> > > ever have need of DRIVER_X-GUID_A and DRIVER_Y-GUID_A ??? I'm thinking
> > > not.
> > >
> > > /dev/wmi/$GUID
> > >
> >
> > I don't think you should allow two drivers to use the same GUID, but what if
> > a driver needs to use multiple GUIDs?
> >
> > This obviously isn't a problem yet.
> > I envision that as we get MOF interpretation as part of the bus we "may" get into
> > that situation with more complicated MOF design.  The vendor driver could
> > register with the bus for each GUID and  request a character device for each but
> > that's meaning userspace has to worry about knowing which GUIDs do what.
> > I think it's potentially asking for a complicated interface to userspace for the
> future.
> >
> > Here's a hypothetical scenario based on some more advanced MOF design I know
> of:
> >
> > Separate GUID provided for each:
> > * All integer settings (data type)
> > * All string settings (data type)
> > * Notifications (event type)
> > * enumeration types (data type)
> > * Applying a Setting (method type)
> > * Managing users (method type)
> >
> > How would a new driver for that look?  I would think you would want one driver
> to register
> > and encapsulate at least all of those GUIDs.
> >
> > I would say all the data should be exported into sysfs, but that you really only
> want
> > one character device that is used for both methods.
> >
> > The interface to userspace would then have two IOCTL's that the driver would
> internally
> > apply to the correct GUID.  Example:
> > "/dev/wmi/$driver" supports 2 different IOCTL's.
> > Internally the driver would then ferry the request through the WMI bus to the
> correct
> > GUID based on the ioctl call number.
> >
> > If you went with the pass the GUID information up and create character device for
> each
> > GUID, userspace will have to know:
> > "I use /dev/wmi/$GUID_X" for applying the setting IOCTL on Acme Inc machine.
> > And
> > "I use /dev/wmi/$GUID_Y" for managing users IOCTL on Acme Inc machine.
> >
> > And what if the notifications are valuable to userspace?  Would you want to
> create another
> > character device for those?  I think you would just want to keep them in the same
> device
> > and add a poll/select file operation.
> >
> 
> Thanks for the concrete example, this helps a lot.
> 
> One guiding principle of this series and something Pali correctly pointed out,
> is that for Linux, we're keeping WMI as the implementation and exposing features
> to userspace through char devs and IOCTLS. You points above are consistent with
> that theme, and the GUIDs are not an appropriate namespace.
> 
> The driver namespace does make more sense as you suggested above:
> 
> /dev/wmi/$driver
> 
> This still has wmi in the name, but given that is the bus name, I think it's a
> reasonable way organize the files - and is still a well-defined naming scheme.
> 

Thanks Darren.  I'll adjust the patch.
Would you like me to document this chosen policy somewhere in Documentation?
If so, where?
Or to put more about our conversation in the commit message? 

RE: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI interface

[Mario.Limonciello]

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@kernel.org]
> Sent: Wednesday, September 27, 2017 3:48 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>; dvhart@infradead.org
> Cc: LKML <linux-kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org;
> quasisec@google.com; pali.rohar@gmail.com
> Subject: Re: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI
> interface
> 
> On 09/21/2017 06:57 AM, Mario Limonciello wrote:
> > The driver currently uses an SMI interface which grants direct access
> > to physical memory to the platform via a pointer.
> >
> > Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
> > for a buffer of data storage when platform calls are performed.
> >
> > This is a safer approach to use in kernel drivers as the platform will
> > only have access to that OperationRegion.
> >
> > As a result, this change removes the dependency on this driver on the
> > dcdbas kernel module.
> >
> 
> > +	status = wmi_evaluate_method(DELL_WMI_SMBIOS_GUID,
> > +				     0, 1, &input, &output);
> 
> It might be nice to add a wmidev_method_evaluate(struct wmi_device
> *wdev, ...) function to better aligh with the new world order.  The only
> reason I didn't do it is that I didn't convert any drivers that wanted it.

Great idea.  I'll apply that for my next patch revision.
I'm not about to convert all the existing drivers, but once all existing drivers
conceptualize using the bus, storing a wmi_device pointer internally,and 
using this the old wmi_evaluate_method can be dropped too.

RE: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI interface

[Mario.Limonciello]

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@kernel.org]
> Sent: Wednesday, September 27, 2017 3:48 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>; dvhart@infradead.org
> Cc: LKML <linux-kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org;
> quasisec@google.com; pali.rohar@gmail.com
> Subject: Re: [PATCH 04/12] platform/x86: dell-smbios: Switch to a WMI-ACPI
> interface
> 
> On 09/21/2017 06:57 AM, Mario Limonciello wrote:
> > The driver currently uses an SMI interface which grants direct access
> > to physical memory to the platform via a pointer.
> >
> > Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
> > for a buffer of data storage when platform calls are performed.
> >
> > This is a safer approach to use in kernel drivers as the platform will
> > only have access to that OperationRegion.
> >
> > As a result, this change removes the dependency on this driver on the
> > dcdbas kernel module.
> >
> 
> > +	status = wmi_evaluate_method(DELL_WMI_SMBIOS_GUID,
> > +				     0, 1, &input, &output);
> 
> It might be nice to add a wmidev_method_evaluate(struct wmi_device
> *wdev, ...) function to better aligh with the new world order.  The only
> reason I didn't do it is that I didn't convert any drivers that wanted it.

Great idea.  I'll apply that for my next patch revision.
I'm not about to convert all the existing drivers, but once all existing drivers
conceptualize using the bus, storing a wmi_device pointer internally,and 
using this the old wmi_evaluate_method can be dropped too.

Re: [PATCH 11/12] platform/x86: dell-wmi-smbios: introduce character device for userspace

[Darren Hart]

On Wed, Sep 27, 2017 at 09:12:34PM +0000, Mario.Limonciello@dell.com wrote:
...
> > Thanks for the concrete example, this helps a lot.
> > 
> > One guiding principle of this series and something Pali correctly pointed out,
> > is that for Linux, we're keeping WMI as the implementation and exposing features
> > to userspace through char devs and IOCTLS. You points above are consistent with
> > that theme, and the GUIDs are not an appropriate namespace.
> > 
> > The driver namespace does make more sense as you suggested above:
> > 
> > /dev/wmi/$driver
> > 
> > This still has wmi in the name, but given that is the bus name, I think it's a
> > reasonable way organize the files - and is still a well-defined naming scheme.
> > 
> 
> Thanks Darren.  I'll adjust the patch.
> Would you like me to document this chosen policy somewhere in Documentation?
> If so, where?
> Or to put more about our conversation in the commit message? 
> 

Some justification in the commit message for now would be best. Thanks!

-- 
Darren Hart
VMware Open Source Technology Center