This function will be used to generate some entropy using the
Clock Recovery System.
BRANCH=none
BUG=b:38486828
TEST=make BOARD=hammer -j tests
./util/flash_ec --board=hammer --image=build/hammer/test-entropy.bin
EC console: runtest
TEST=Test fails when no USB connection is active
TEST=Test passes when USB connection is active
TEST=Pasting the values into:
tr ';' '\n' | awk 'BEGIN { e = 0; tot=16384.0 }
{ p = $1/tot; if (p > 0) { e -= p*log(p)/log(2) } }
END { print e }'
shows an entropy > 4 bits per sample.
Change-Id: I2363c7bce42c72c33ef0bf3f099d709ee9c13d13
Reviewed-on: https://chromium-review.googlesource.com/518608
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For pairing purpose, we want to store some secret random number in
the base. The most convenient location for this is the rollback
region.
Since the rollback region can now be updated without incrementing
rollback_min_version (when we add entropy to the secret), we need
to add an increasing id to tell the code which rollback region is
the latest.
We also add console commands to manually add entropy.
BRANCH=none
BUG=b:38486828
TEST=Flash hammer (with or without CONFIG_ROLLBACK_ENTROPY_SIZE set)
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
only when CONFIG_ROLLBACK_ENTROPY_SIZE is set:
rollbackinfo => Secret is [00..00] on both blocks (so the data
was copied correctly)
rollbackupdate 2, 3, 4; rollbackinfo => Writes alternate
between the 2 blocks.
rollbackupdate 2 => Refuses to downgrade version
TEST=From blank secret [00..00], 'rollbackaddent Hello' updates it
to [ba..fa], which matches the output of:
(dd if=/dev/zero bs=1 count=32; echo -n Hello) | sha256sum
Change-Id: I79c3e790e56e21958cc1b4ba05bd4e5f359d3090
Reviewed-on: https://chromium-review.googlesource.com/511985
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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>
