Attention is currently required from: Nico Huber, Michał Żygowski, Paul Menzel.
2 comments:
File ite_ecfw.c:
Patch Set #29, Line 495: (uint8_t *)
To be honest I don't see such modifications in the flashrom tool. Wouldn't mind […]
I did a bunch of tests on the autoload feature and read datasheets and leaked ec code again. It seems, all this is meant to be a recovery mechanism in case something goes wrong during flashing. Since under normal circumstances the external flash is not being modified at all, there is always a working firmware image present.
The autoload feature is copying the external flash contents to the eFlash on power-on and it is controlled by
The signature is used for determining the code base address, internal/external clock selection and configuring autoload. The relevant bits and bytes for autoload are:
byte 7:
byte 13 :
The signature initially (when the eFlash is empty) is located on the external flash. When autoload is enabled (b7[5]=0) and len (b13) > 0, the EC copies len+1 blocks from the external flash to eFlash, then starts executing from the eFlash.
On the next power cycle the EC evaluates BOTH signatures! Tests showed that:
ITE's reference firmware / fw framework disables autoload on the first startup by writing 0x00 to b13. They call it "mirror once". Vendors like Clevo or Lenovo usually keep this mechanism.
If any (older?) firmware image is missing that "mirror once" mechanism, this might lead to overwriting the flashed image on the next power cycle. Maybe that's the reason for the options in the vendor tool?
=> Anyway, the risk is low, since the worst thing that could happen is a downgrade of the firmware to the one on the external flash. If required we can try to find a solution if such case is being reported.
The signature(s) is/are generated during firmware build and we should expect the clock / code base settings to be correct. We shouldn't mess with these settings, even though the vendor tool does. If anyone wants to modify them, they could use a hex editor or adapt the source code (if built from source).
=> Let's drop patching any of these bits.
If someone really wants to force-off autoload manually, they could use a hex editor for now or write a simple tool for it.
=> I still need to test this to be 100% sure but I'm pretty confident now that we can drop any patching of the signature without affecting the function of this safeguard feature.
File ite_ecfw.c:
if (ctx_data->support_ite5570)
return ite_ecfw_chunkwise_erase(ctx_data, blockaddr, blocklen);
hm, I wonder why this is only done for it5570. (I know, the vendor tool does it... but why?). at least clevo l140cu/l140mu firmware provide the full erase function as well.
To view, visit change 55715. To unsubscribe, or for help writing mail filters, visit settings.