linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] platform/chrome: wilco_ec: Add telemetry data char device interface
@ 2019-04-12 22:45 Nick Crews
  2019-04-15  8:04 ` Enrico Weigelt, metux IT consult
  0 siblings, 1 reply; 3+ messages in thread
From: Nick Crews @ 2019-04-12 22:45 UTC (permalink / raw)
  To: enric.balletbo, bleung
  Cc: linux-kernel, dlaurie, derat, groeck, dtor, sjg, bartfab, lamzin,
	jchwong, Nick Crews

The Wilco Embedded Controller is able to send telemetry data
which is useful for enterprise applications. A daemon running on
the OS sends a command to the EC via write() to char device,
and can read the response with a read() request.
Both the request and the response are in an opaque
binary format so that information which is proprietary to the
enterprise service provider is secure.

The character device will appear as /dev/wilco_telemN, where N is some
small non-negative integer, starting with 0. Only one process may have
the file descriptor open at a time. The calling userspace program needs
to keep the device file descriptor open between the calls to write() and
read() in order to preserve the response. Either 32 or 256 bytes of data
are expected for arguments, and the same number of bytes will be
returned.

For testing purposes, if the EC receives a byte sequence beginning with
0, it will return an inverted copy of the input sequence. For an
example, run the simple python script from
https://gist.github.com/52ab07c8519b56c0ec671d3338760516

Signed-off-by: Nick Crews <ncrews@chromium.org>
---
 drivers/platform/chrome/wilco_ec/Kconfig     |   7 +
 drivers/platform/chrome/wilco_ec/Makefile    |   2 +
 drivers/platform/chrome/wilco_ec/core.c      |  13 +
 drivers/platform/chrome/wilco_ec/telemetry.c | 312 +++++++++++++++++++
 include/linux/platform_data/wilco-ec.h       |   2 +
 5 files changed, 336 insertions(+)
 create mode 100644 drivers/platform/chrome/wilco_ec/telemetry.c

diff --git a/drivers/platform/chrome/wilco_ec/Kconfig b/drivers/platform/chrome/wilco_ec/Kconfig
index e09e4cebe9b4..7846f6146b78 100644
--- a/drivers/platform/chrome/wilco_ec/Kconfig
+++ b/drivers/platform/chrome/wilco_ec/Kconfig
@@ -18,3 +18,10 @@ config WILCO_EC_DEBUGFS
 	  manipulation and allow for testing arbitrary commands.  This
 	  interface is intended for debug only and will not be present
 	  on production devices.
+
+config WILCO_EC_TELEMETRY
+	tristate "Enable querying telemetry data from EC"
+	depends on WILCO_EC
+	help
+	  If you say Y here, you get support to query opaque binary
+	  telemetrydata from /dev/wilco_telem using write() and then read().
diff --git a/drivers/platform/chrome/wilco_ec/Makefile b/drivers/platform/chrome/wilco_ec/Makefile
index 063e7fb4ea17..b4aa6d26a3df 100644
--- a/drivers/platform/chrome/wilco_ec/Makefile
+++ b/drivers/platform/chrome/wilco_ec/Makefile
@@ -4,3 +4,5 @@ wilco_ec-objs				:= core.o mailbox.o
 obj-$(CONFIG_WILCO_EC)			+= wilco_ec.o
 wilco_ec_debugfs-objs			:= debugfs.o
 obj-$(CONFIG_WILCO_EC_DEBUGFS)		+= wilco_ec_debugfs.o
+wilco_ec_telem-objs			:= telemetry.o
+obj-$(CONFIG_WILCO_EC_TELEMETRY)	+= wilco_ec_telem.o
diff --git a/drivers/platform/chrome/wilco_ec/core.c b/drivers/platform/chrome/wilco_ec/core.c
index 05e1e2be1c91..517d9627fecc 100644
--- a/drivers/platform/chrome/wilco_ec/core.c
+++ b/drivers/platform/chrome/wilco_ec/core.c
@@ -89,8 +89,20 @@ static int wilco_ec_probe(struct platform_device *pdev)
 		goto unregister_debugfs;
 	}
 
+	/* Register child device that will be found by the telemetry driver. */
+	ec->telem_pdev = platform_device_register_data(dev, "wilco_telem",
+						       PLATFORM_DEVID_AUTO,
+						       NULL, 0);
+	if (IS_ERR(ec->telem_pdev)) {
+		dev_err(dev, "Failed to create telemetry platform device\n");
+		ret = PTR_ERR(ec->telem_pdev);
+		goto unregister_rtc;
+	}
+
 	return 0;
 
+unregister_rtc:
+	platform_device_unregister(ec->rtc_pdev);
 unregister_debugfs:
 	if (ec->debugfs_pdev)
 		platform_device_unregister(ec->debugfs_pdev);
@@ -102,6 +114,7 @@ static int wilco_ec_remove(struct platform_device *pdev)
 {
 	struct wilco_ec_device *ec = platform_get_drvdata(pdev);
 
+	platform_device_unregister(ec->telem_pdev);
 	platform_device_unregister(ec->rtc_pdev);
 	if (ec->debugfs_pdev)
 		platform_device_unregister(ec->debugfs_pdev);
diff --git a/drivers/platform/chrome/wilco_ec/telemetry.c b/drivers/platform/chrome/wilco_ec/telemetry.c
new file mode 100644
index 000000000000..6b3dc84bd0f2
--- /dev/null
+++ b/drivers/platform/chrome/wilco_ec/telemetry.c
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Telemetry communication for Wilco EC
+ *
+ * Copyright 2019 Google LLC
+ *
+ * The Wilco Embedded Controller is able to send telemetry data
+ * which is useful for enterprise applications. A daemon running on
+ * the OS sends a command to the EC via a write() to a char device, and
+ * can read the response with a read() request. Both the request
+ * and the response are in an opaque binary format so that information
+ * which is proprietary to the enterprise service provider is secure.
+ *
+ * The character device will appear as /dev/wilco_telemN, where N is some
+ * small non-negative integer, starting with 0. Only one process may have
+ * the file descriptor open at a time. The calling userspace program needs
+ * to keep the device file descriptor open between the calls to write() and
+ * read() in order to preserve the response. Either 32 or 256 bytes of data
+ * are expected for arguments, and the same number of bytes will be
+ * returned.
+ *
+ * For testing purposes, if the EC receives a byte sequence beginning with
+ * 0, it will return an inverted copy of the input sequence. For an
+ * example, run the simple python script from
+ * https://gist.github.com/52ab07c8519b56c0ec671d3338760516
+ */
+
+#include <linux/cdev.h>
+#include <linux/device.h>
+#include <linux/fs.h>
+#include <linux/module.h>
+#include <linux/platform_data/wilco-ec.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/uaccess.h>
+
+#define TELEM_DEV_NAME		"wilco_telem"
+#define TELEM_CLASS_NAME	TELEM_DEV_NAME
+#define DRV_NAME		TELEM_DEV_NAME
+#define TELEM_DEV_NAME_FMT	(TELEM_DEV_NAME "%d")
+static struct class telem_class = {
+	.owner	= THIS_MODULE,
+	.name	= TELEM_CLASS_NAME,
+};
+
+/* Keep track of all the device numbers used. */
+#define TELEM_MAX_DEV 128
+static int telem_major;
+static DEFINE_IDA(telem_ida);
+
+/**
+ * struct telem_device_data - Data for a Wilco EC device that queries telemetry.
+ * @cdev: Char dev that userspace reads and polls from.
+ * @dev: Device associated with the %cdev.
+ * @ec: Wilco EC that we will be communicating with using the mailbox interface.
+ * @available: Boolean of if the device can be opened.
+ */
+struct telem_device_data {
+	struct device dev;
+	struct cdev cdev;
+	struct wilco_ec_device *ec;
+	atomic_t available;
+};
+
+/**
+ * struct telem_session_data - Data that exists between open() and release().
+ * @dev_data: Pointer to get back to the device data and EC.
+ * @request: Argument buffer of opaque binary data sent to EC.
+ * @response: Response buffer of opaque binary data from EC.
+ * @msg_size: Number of bytes in request and response.
+ * @has_msg: Is there data available to read from a previous write?
+ */
+struct telem_session_data {
+	struct telem_device_data *dev_data;
+	u8 request[EC_MAILBOX_DATA_SIZE_EXTENDED];
+	u8 response[EC_MAILBOX_DATA_SIZE_EXTENDED];
+	int msg_size;
+	bool has_msg;
+};
+
+/**
+ * telem_open() - Callback for when the device node is opened.
+ * @inode: inode for this char device node.
+ * @filp: file for this char device node.
+ *
+ * We need to ensure that after writing a command to the device,
+ * the same userspace process reads the corresponding result.
+ * Therefore, we increment a refcount on opening the device, so that
+ * only one process can communicate with the EC at a time.
+ *
+ * Return: 0 on success, or negative error code on failure.
+ */
+static int telem_open(struct inode *inode, struct file *filp)
+{
+	struct telem_device_data *dev_data;
+	struct telem_session_data *sess_data;
+
+	/* Ensure device isn't already open */
+	dev_data = container_of(inode->i_cdev, struct telem_device_data, cdev);
+	if (atomic_cmpxchg(&dev_data->available, 1, 0) == 0)
+		return -EBUSY;
+
+	sess_data = kzalloc(sizeof(*sess_data), GFP_KERNEL);
+	if (!sess_data) {
+		atomic_set(&dev_data->available, 1);
+		return -ENOMEM;
+	}
+	sess_data->dev_data = dev_data;
+	sess_data->has_msg = false;
+
+	nonseekable_open(inode, filp);
+	filp->private_data = sess_data;
+
+	return 0;
+}
+
+static ssize_t telem_write(struct file *filp, const char __user *buf,
+			   size_t count, loff_t *pos)
+{
+	struct telem_session_data *sess_data = filp->private_data;
+	struct wilco_ec_message msg;
+	int ret;
+
+	if (count != EC_MAILBOX_DATA_SIZE &&
+	    count != EC_MAILBOX_DATA_SIZE_EXTENDED)
+		return -EINVAL;
+	sess_data->msg_size = count;
+
+	if (copy_from_user(sess_data->request, buf, count))
+		return -EFAULT;
+
+	if (sess_data->msg_size == EC_MAILBOX_DATA_SIZE) {
+		msg.type = WILCO_EC_MSG_TELEMETRY_SHORT;
+		msg.flags = 0;
+	} else {
+		msg.type = WILCO_EC_MSG_TELEMETRY_LONG;
+		msg.flags = WILCO_EC_FLAG_EXTENDED_DATA;
+	}
+	msg.request_data = sess_data->request;
+	msg.request_size = sess_data->msg_size;
+	msg.response_data = sess_data->response;
+	msg.response_size = sess_data->msg_size;
+
+	ret = wilco_ec_mailbox(sess_data->dev_data->ec, &msg);
+	if (ret < 0)
+		return ret;
+	if (ret != sess_data->msg_size)
+		return -EMSGSIZE;
+
+	sess_data->has_msg = true;
+
+	return count;
+}
+
+static ssize_t telem_read(struct file *filp, char __user *buf, size_t count,
+			  loff_t *pos)
+{
+	struct telem_session_data *sess_data = filp->private_data;
+
+	if (!sess_data->has_msg)
+		return -ENODATA;
+	if (count != sess_data->msg_size)
+		return -EINVAL;
+
+	if (copy_to_user(buf, sess_data->response, sess_data->msg_size))
+		return -EFAULT;
+
+	sess_data->has_msg = false;
+
+	return sess_data->msg_size;
+}
+
+static int telem_release(struct inode *inode, struct file *filp)
+{
+	struct telem_session_data *sess_data = filp->private_data;
+
+	atomic_set(&sess_data->dev_data->available, 1);
+	kfree(sess_data);
+
+	return 0;
+}
+
+static const struct file_operations telem_fops = {
+	.open = telem_open,
+	.write = telem_write,
+	.read = telem_read,
+	.release = telem_release,
+	.llseek = no_llseek,
+	.owner = THIS_MODULE,
+};
+
+/**
+ * telem_device_probe() - Callback when creating a new device.
+ * @pdev: platform device that we will be receiving telems from.
+ *
+ * This finds a free minor number for the device, allocates and initializes
+ * some device data, and creates a new device and char dev node.
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+static int telem_device_probe(struct platform_device *pdev)
+{
+	struct telem_device_data *dev_data;
+	dev_t dev_num;
+	int error, minor;
+
+	/* Get the next available device number */
+	minor = ida_alloc_max(&telem_ida, TELEM_MAX_DEV-1, GFP_KERNEL);
+	if (minor < 0) {
+		error = minor;
+		dev_err(&pdev->dev, "Failed to find minor number: %d", error);
+		return error;
+	}
+
+	dev_data = devm_kzalloc(&pdev->dev, sizeof(*dev_data), GFP_KERNEL);
+	if (!dev_data) {
+		ida_simple_remove(&telem_ida, minor);
+		return -ENOMEM;
+	}
+
+	/* Initialize the device data */
+	dev_data->ec = dev_get_drvdata(pdev->dev.parent);
+	atomic_set(&dev_data->available, 1);
+	platform_set_drvdata(pdev, dev_data);
+
+	/* Initialize the device */
+	dev_num = MKDEV(telem_major, minor);
+	dev_data->dev.devt = dev_num;
+	dev_data->dev.class = &telem_class;
+	dev_set_name(&dev_data->dev, TELEM_DEV_NAME_FMT, minor);
+	device_initialize(&dev_data->dev);
+
+	/* Initialize the character device and add it to userspace */;
+	cdev_init(&dev_data->cdev, &telem_fops);
+	error = cdev_device_add(&dev_data->cdev, &dev_data->dev);
+	if (error) {
+		ida_simple_remove(&telem_ida, minor);
+		return error;
+	}
+
+	return 0;
+}
+
+static int telem_device_remove(struct platform_device *pdev)
+{
+	struct telem_device_data *dev_data = platform_get_drvdata(pdev);
+
+	cdev_device_del(&dev_data->cdev, &dev_data->dev);
+	ida_simple_remove(&telem_ida, MINOR(dev_data->dev.devt));
+
+	return 0;
+}
+
+static struct platform_driver telem_driver = {
+	.probe = telem_device_probe,
+	.remove = telem_device_remove,
+	.driver = {
+		.name = DRV_NAME,
+	},
+};
+
+static int __init telem_module_init(void)
+{
+	dev_t dev_num = 0;
+	int ret;
+
+	ret = class_register(&telem_class);
+	if (ret) {
+		pr_warn(DRV_NAME ": Failed registering class: %d", ret);
+		return ret;
+	}
+
+	/* Request the kernel for device numbers, starting with minor=0 */
+	ret = alloc_chrdev_region(&dev_num, 0, TELEM_MAX_DEV, TELEM_DEV_NAME);
+	if (ret) {
+		pr_warn(DRV_NAME ": Failed allocating dev numbers: %d", ret);
+		goto destroy_class;
+	}
+	telem_major = MAJOR(dev_num);
+
+	ret = platform_driver_register(&telem_driver);
+	if (ret < 0) {
+		pr_warn(DRV_NAME ": Failed registering driver: %d\n", ret);
+		goto unregister_region;
+	}
+
+	return 0;
+
+unregister_region:
+	unregister_chrdev_region(MKDEV(telem_major, 0), TELEM_MAX_DEV);
+destroy_class:
+	class_unregister(&telem_class);
+	ida_destroy(&telem_ida);
+	return ret;
+}
+
+static void __exit telem_module_exit(void)
+{
+	platform_driver_unregister(&telem_driver);
+	unregister_chrdev_region(MKDEV(telem_major, 0), TELEM_MAX_DEV);
+	class_unregister(&telem_class);
+	ida_destroy(&telem_ida);
+}
+
+module_init(telem_module_init);
+module_exit(telem_module_exit);
+
+MODULE_AUTHOR("Nick Crews <ncrews@chromium.org>");
+MODULE_DESCRIPTION("Wilco EC telemetry driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:" DRV_NAME);
diff --git a/include/linux/platform_data/wilco-ec.h b/include/linux/platform_data/wilco-ec.h
index 1ff224793c99..ec0f9c06be01 100644
--- a/include/linux/platform_data/wilco-ec.h
+++ b/include/linux/platform_data/wilco-ec.h
@@ -32,6 +32,7 @@
  * @data_size: Size of the data buffer used for EC communication.
  * @debugfs_pdev: The child platform_device used by the debugfs sub-driver.
  * @rtc_pdev: The child platform_device used by the RTC sub-driver.
+ * @telem_pdev: The child platform_device used by the telemetry sub-driver.
  */
 struct wilco_ec_device {
 	struct device *dev;
@@ -43,6 +44,7 @@ struct wilco_ec_device {
 	size_t data_size;
 	struct platform_device *debugfs_pdev;
 	struct platform_device *rtc_pdev;
+	struct platform_device *telem_pdev;
 };
 
 /**
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] platform/chrome: wilco_ec: Add telemetry data char device interface
  2019-04-12 22:45 [PATCH] platform/chrome: wilco_ec: Add telemetry data char device interface Nick Crews
@ 2019-04-15  8:04 ` Enrico Weigelt, metux IT consult
  2019-04-18 15:35   ` Duncan Laurie
  0 siblings, 1 reply; 3+ messages in thread
From: Enrico Weigelt, metux IT consult @ 2019-04-15  8:04 UTC (permalink / raw)
  To: Nick Crews, enric.balletbo, bleung
  Cc: linux-kernel, dlaurie, derat, groeck, dtor, sjg, bartfab, lamzin,
	jchwong

On 13.04.19 00:45, Nick Crews wrote:
> The Wilco Embedded Controller is able to send telemetry data
> which is useful for enterprise applications. 

What kind of "enterprise applications" exactly ?

> A daemon running on
> the OS sends a command to the EC via write() to char device,
> and can read the response with a read() request.
> Both the request and the response are in an opaque
> binary format so that information which is proprietary to the
> enterprise service provider is secure.

In other words: a direct backdoor for the "provider", who can do
anything he wants remotely on the user's machine, w/o the user having
a chance of seeing what's actually going on ?

Seriously ?!

In some of your previous mails (*1) you indicate that it sends some
diagnostics information (eg. "dock is not working"). WTH does that
have to be "proprietary", IOW: encrypted = kept secret from the owner ?

If I *own* such a device, this is some information, I *need* to know,
I *deserve* to know, and it is *my* data, as it's a state of *my*
device. And that's some kind of information that *nobody* else has
any business with that. Period.

Seems you folks (Google) still didn't learn the fundamental difference
between ownership and just a license to use. And the recent multi
billion fines against Google still haven't been enough, so I'm looking
forward Mrs. Vestager's next strikes.


I'd like to remind you of the famous words of JR. Oppenheimer:
""Now I am become Death, the destroyer of worlds."
(quoted from the Bhagavad Gita, when he recognized the desatreous
consequences of his work)


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] platform/chrome: wilco_ec: Add telemetry data char device interface
  2019-04-15  8:04 ` Enrico Weigelt, metux IT consult
@ 2019-04-18 15:35   ` Duncan Laurie
  0 siblings, 0 replies; 3+ messages in thread
From: Duncan Laurie @ 2019-04-18 15:35 UTC (permalink / raw)
  To: Enrico Weigelt, metux IT consult
  Cc: Nick Crews, Enric Balletbo i Serra, Benson Leung, linux-kernel,
	Daniel Erat, Guenter Roeck, Dmitry Torokhov, Simon Glass,
	bartfab, Oleh Lamzin, Jason Wong

On Mon, Apr 15, 2019 at 1:04 AM Enrico Weigelt, metux IT consult
<lkml@metux.net> wrote:
>
> On 13.04.19 00:45, Nick Crews wrote:
> > The Wilco Embedded Controller is able to send telemetry data
> > which is useful for enterprise applications.
>
> What kind of "enterprise applications" exactly ?
>
> > A daemon running on
> > the OS sends a command to the EC via write() to char device,
> > and can read the response with a read() request.
> > Both the request and the response are in an opaque
> > binary format so that information which is proprietary to the
> > enterprise service provider is secure.
>
> In other words: a direct backdoor for the "provider", who can do
> anything he wants remotely on the user's machine, w/o the user having
> a chance of seeing what's actually going on ?
>
> Seriously ?!
>
> In some of your previous mails (*1) you indicate that it sends some
> diagnostics information (eg. "dock is not working"). WTH does that
> have to be "proprietary", IOW: encrypted = kept secret from the owner ?
>
> If I *own* such a device, this is some information, I *need* to know,
> I *deserve* to know, and it is *my* data, as it's a state of *my*
> device. And that's some kind of information that *nobody* else has
> any business with that. Period.
>

We on the Chrome OS team happen to strongly agree with you, which is
why Chromebooks are the only mass market devices to ship with an open
source Embedded Controller.

For devices with the Wilco EC we are working with an OEM who builds
specific computers for "enterprise" scenarios where a company owns or
leases the device and is responsible for the management of it, while
the end user is an employee or contractor who does not own the device
they are using.  For various business reasons we are not able to get
our usual open source EC firmware on this board, so we are forced to
rely on the vendor's closed EC firmware.

The reality is that this is exactly what a standard EC firmware is
today: a black box with an opaque mailbox interface that provides
hundreds of undocumented commands.  Typically this mailbox interface
is hidden behind the BIOS with SMI and WMI and the user has no idea
that these even exist.

We are attempting to cope with this closed EC by fitting these mailbox
commands into standard kernel interfaces wherever possible, rather
than go the traditional route of hiding it in the BIOS or simply
exposing an opaque /dev node and letting user space send whatever
commands it wants.  Our intent is for the interface to the EC to be
intentionally limited by the kernel driver and to be very clear what
commands are available and what they do.  The drivers are also modular
so that if an end user does acquire one of these devices they can
choose not to load some modules and further limit what EC interfaces
are exposed to the OS.

This specific telemetry command provides hardware information about
the device, such as voltages, fan speeds, temperatures, power numbers,
etc.  This is the one command where the vendor we are working with is
not willing to document the returned data format publicly (or even to
us) as they consider the hardware diagnostic data that they gather
here, and the analytics that they run on it, to be critical IP for
their enterprise device replacement program.

It is clear from feedback that this telemetry command is still too
opaque, and we will continue to work with the vendor to try and come
up with a more flexible command set that still allows us to implement
the interface in the kernel without resorting to the usual tricks to
hide it from the user.

-duncan

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-04-18 15:35 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-12 22:45 [PATCH] platform/chrome: wilco_ec: Add telemetry data char device interface Nick Crews
2019-04-15  8:04 ` Enrico Weigelt, metux IT consult
2019-04-18 15:35   ` Duncan Laurie

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).