Attention is currently required from: Felix Singer, Nico Huber, Michał Żygowski, Paul Menzel, Angel Pons.
1 comment:
Patchset:
Knowing the mainboard avoids running the code on the wrong board where it's more likely to do harm. It's not about the flashing process, flash contents or the contents to be flashed. The code starts with `ec_write_reg(0xf9, 0x20, EC_MAX_STATUS_CHECKS)`. There may be EC firmware that reacts badly to such a write (or chips that completely misunderstand what is written to their registers). Knowing the board it runs on, makes it much less likely to hit such a case.
That's the exact reason why I have put DMI checks. I don't want people complaining on flashrom bricking/damaging someone's device and losing trust in this project.
That's what SVID/SDID can be used for, too, since it identifies the mainboard as DMI does. Neither of them can replace the check for the correct EC being present but avoid confusing other chips, like Nico mentioned.
To be effective, the DMI checks should happen as part of programmer initialisation. Looks like they do now, which is good.If we still want some possibility to probe the EC, aware of the risks, we could use the `force` flag from the CLI to forcefully send those commands under a warning that it may brick their device.
Sounds like a reasonable compromise.
Sounds good.
> I am in favor of not breaking things wherever possible. Flashrom is not only an utility to change flash contents for hackers and developers right now (it probably was earlier). It is also used as a plugin in fwupd for example, where reliability and safety of the update is in the first place.Definitely.
To view, visit change 55715. To unsubscribe, or for help writing mail filters, visit settings.