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