ec: Add component-FW-update host command / ectool sequence |
|||||
Issue descriptionFor test / development, we'd like to have the capability to update the FW of various components (eg. TCPCs) attached to a chip running cros-ec. Each component will have its own custom method for entering FU mode, and the FU interface may vary. We will need to implement a host command similar to EC_CMD_USB_PD_FW_UPDATE (or maybe we can rename / reuse that host command as a generic update command) with sub-commands like "enter FU mode", "flash erase", "flash write" and "leave FU mode". We should then implement an ectool sub-command which sends the proper sequence of host commands to flash a given component with a given FW image on the host file system.
,
Sep 14 2016
Assuming the low level TCPC FW update code will reside in EC TCPC driver (anx74xx.c for example), can we avoid exposing the flash update logic to open source? So far we have been sharing patch via crosbug, is there a way to setup private overlay for EC?
,
Sep 14 2016
I didn't realize there were concerns regarding secret update commands / protocols. We will bring it up with this particular vendor tomorrow. My strong opinion is that all update code (and all cros-ec code in general) should be open source.
,
Sep 14 2016
I do not know each vendor's policy and whether it is a secret or not. Just a security risk concern in general if someone can hack it especially it doesn't have the RO/RW concept. Also if the chip uses OTP vs NAND, then it could be forever blocked from future programming once hacked.
,
Sep 14 2016
Security through obscurity isn't. We have to ship the binary, and it's remarkably easy to disassemble to reverse-engineer the protocol. It's better for the logic to be in an open source tree where we can use our standard toolchain and build system to test it against Coverity scans, etc.
,
Sep 14 2016
And just to add, we can (and probably will) lock out this feature on devices which are 'locked' (protected at factory), so updating TCPC FW in the field will require physical access to the device to remove the WP screw / switch. We take similar precautions for certain other host commands (eg. for generic i2c write).
,
Jan 10 2017
FWIW, ANX7688 updating code (from AP-FW) is open-source, and here: https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/master/src/drivers/ec/anx7688 . We then lock the bus (i.e. prevent access on the I2C bus/address to provides the updating service) to make sure AP cannot update the firmware (as long as WP is on, even developer mode can't update the FW). FW can be updated in the field (and not only for dev/testing purpose). I highly recommend we do that for all PD chips.
,
Jan 10 2017
The assigned owner "vprupis@chromium.org" is not able to receive e-mails, please re-triage. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 11 2017
,
Apr 7 2017
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by reinauer@chromium.org
, Sep 8 2016Status: Assigned (was: Untriaged)