Re: [PATCH] platform/chrome: wilco_ec: Add telemetry data char device interface

[Duncan Laurie]

On Mon, Apr 15, 2019 at 1:04 AM Enrico Weigelt, metux IT consult
<lkml@xxxxxxxxx> 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