This is done at RO stage. If the rollback region is unprotected, update
it to match the version in the RW image.
If the rollback region is protected, we can't do that update, so we wait
for RW to unlock that region (presumably after AP has verified that image
is somewhat functional) before updating it.
BRANCH=none
BUG=b:35586219
TEST=flashwp true; reboot => hammer reboots twice
flashinfo shows RO+rollback protected:
Flags: wp_gpio_asserted ro_at_boot ro_now rollback_at_boot rollback_now
Protected now:
YYYYYYYY YYYYYYYY Y....... ........
TEST=Hack version.c to add "+1" to rollback_version, check that RO updates
ROLLBACK info block on first boot.
TEST=Use hack above, convert rwsig to separate task, add 5000 ms delay in
rwsig just before rollback information is updated. Then:
Quickly type: flashwp true; reboot; flashwp all; reboot
=> Wait for system to jump to RW
rollbackinfo => minimum version 0
flashwp norb; reboot; wait for jump to RW
rollbackinfo => minimum version 1
Change-Id: I78e502315c611c5edaf34b8d70a12fedd3e57bdf
Reviewed-on: https://chromium-review.googlesource.com/452816
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Implement actual rollback protection. First, we add a new field
in the version structure, which is an incrementing integer
(we'll start by shipping images with version 0, and gradually
increase the number as required). This allows us to release
new versions of the EC without necessarily bumping the rollback
protection.
For the rollback protection block itself, it contains 2 sub-blocks
of equal size (normally, 2k), that are individually erasable.
The rollback code looks at both, and takes the most restrictive one
to determine the desired rollback minimum version. The blocks
are also allowed to be erased (full of 1's), in which case the
rollback minimum version is assumed to be 0.
We also add an FMAP entry, in case we later decide to allow the
signer to increment the rollback version.
Also note that, like any version_data struct change, this change
breaks compatibility between old and new RO/RW.
Follow-up code will take care of auto-updating the rollback block
as required, and properly manage block protection.
BRANCH=none
BUG=b:35586219
TEST=Flash hammer
rollbackinfo => 1 version 0 block, 1 empty block, RW verifies
correctly.
rollbackupdate 0; rollbackinfo => No change
rollbackupdate 1; reboot => RO refuses to jump to RW
rollbackupdate 2, 3, 4; rollbackinfo => Writes alternate
between the 2 blocks.
rollbackupdate 2 => Refuses to downgrade version
Change-Id: Ia969afb481a93deb912b9153bdd95ace01ad8fa7
Reviewed-on: https://chromium-review.googlesource.com/452815
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
