This is largely geared for testing for quickly creating a set of loem keys.
BUG=chromium:381862
TEST=`./add_loem_keys.sh 0` converted an existing keyset to a loem keyset
TEST=`./add_loem_keys.sh 3` added three more keysets
TEST=ran sign_official_build.sh with new keysets against a recovery.bin
BRANCH=none
Change-Id: I598b7a453b747a231df850657df50bede01768c2
Reviewed-on: https://chromium-review.googlesource.com/203940
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Forgot to update the bitsizes in the variable constants.
BUG=chromium:454651
TEST=`./create_new_keys.sh` still generates 8k keys
TEST=`./create_new_keys.sh --4k` now generates 4k keys
BRANCH=None
Change-Id: Ie285649f4d58ad2e2cba71f4cab737cc2235e3ab
Reviewed-on: https://chromium-review.googlesource.com/245890
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
While we do this, clean up:
- use braces everywhere
- convert local vars from $VAR to $var
- parse all command line args properly
- run in `set -e` mode
BUG=chromium:454651
TEST=`./create_new_keys.sh` still generates sane keys
TEST=`./create_new_keys.sh --help` shows help output
TEST=`./create_new_keys.sh --asdfasdf` shows an error
TEST=`./create_new_keys.sh` outside chroot (w/out vboot binaries) aborts after first failure
BRANCH=None
Change-Id: I1ba0db0b24c0f2f10cf397b47115f0e98384d991
Reviewed-on: https://chromium-review.googlesource.com/245317
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Add a script that runs sanity checks on the versions in a keyset.
In particular, tests whether the actual key versions match those
in key.versions. Also runs consistency checks (for example: firmware
version should match kernel subkey version).
BUG=none
TEST=run on all of our keysets
BRANCH=none
Change-Id: I5b509ba33127364f6b63252ad167646eb7dce710
Reviewed-on: https://chromium-review.googlesource.com/190790
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Gaurav Shah <gauravsh@chromium.org>
The common.sh file already defines these variables/funcs, so drop them.
BUG=chromium:381862
TEST=`./create_new_keys.sh` created new keys correctly
BRANCH=none
Change-Id: Ie7f0f683d4971c188d4629b520938b4b65bb0a9f
Reviewed-on: https://chromium-review.googlesource.com/203685
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
There's no need to give execute permissions to files that aren't supposed to
executed.
BUG=none
BRANCH=none
TEST=manual
make runtests
Change-Id: I2480b97b39124e98c2f639d56be54cadfdc17f9b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42648
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Part of the recent rewrite dropped changing of the active dir to
${KEY_DIR}. Meant the scripts needed to be run inside of the key
dir since not all functions take the key dir as an argument but
instead assume they're in ${PWD}.
BUG=None
TEST=Ran increment_kernel_subkey_and_key_mp.sh and saw it work
BRANCH=None
Change-Id: Icbc02f123e999d186d9c40fd16528a134397699e
Reviewed-on: https://gerrit.chromium.org/gerrit/35803
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
For firmware and kernel key increment testing we need to be able to
rev only particular keys and verify an autoupdate works.
BUG=None
TEST=Ran it
BRANCH=None
Change-Id: Ic814480b4bf8fbc994132fcd7ba519c3be9b0ccd
Reviewed-on: https://gerrit.chromium.org/gerrit/32458
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Kris Rambish <krisr@chromium.org>
Tested-by: Kris Rambish <krisr@chromium.org>
First, preserve extensions for the backed up keys (and keyblocks). Useful since
our wrapping scripts look at the extension in deciding what needs wrapping.
Second, instead of having to run the script from within a keyset directory,
take the keyset path as an argument and increment the versions for
the keys in there.
BUG=chrome-os-partner:13748
TEST=ran on devkeys
BRANCH=none
Change-Id: I9e8c3e58149e5cb4cd5557521e047e25c06b0cd6
Reviewed-on: https://gerrit.chromium.org/gerrit/32417
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Gaurav Shah <gauravsh@chromium.org>
This just adds the vbutil_ec tool (and a simple test of the library
functions related to it).
BUG=chrome-os-partner:7459, chromium-os:27142
TEST=manual
make
make runtests
Change-Id: I2a2c4e7cfb8ac6ce2229c5de4252a5cc89321fa5
Reviewed-on: https://gerrit.chromium.org/gerrit/21868
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
For key generation, only generate dev firmware keyblocks, if the
--devkeyblock option is passed. For signing, re-use normal firmware
keyblock and data key if no dev keyblocks or data key are found in
the keyset directory.
BUG=chrome-os-partner:6942
TEST=manual
- tested key generation with/without the new flag
- tested signing with or without the presence of dev keyblock
Change-Id: Ic4bf72cb194461e07fcc0f6de39d4e16d1c979a6
Reviewed-on: https://gerrit.chromium.org/gerrit/12038
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Gaurav Shah <gauravsh@chromium.org>
Commit-Ready: Gaurav Shah <gauravsh@chromium.org>
BUG=chromium-os:14904
TEST=manual:
./create_new_keys.sh
verify that keys are created
edit key.versions to change versions to 10 20 30 40
./create_new_keys.sh
verify that keys are created with versions from the file
Change-Id: I459018267883557237ab4cc0de9b443242739346
When we do perform firmware updates, we'd like to change the kernel subkey to ensure that new firmware and Chrome OS image stay in sync. This CL adds a scripts which makes it possible to do this revving in an automated manner.
The current versions rollback versions corresponding to the keyset are stored in key.versions. If we change the kernel subkey (to enforce firmware/Chrome OS lockstep), we must also update the firmware version. Similarly, since we modify the kernel subkey, we also generate a new set of kernel data keys. Thus, we also increment the kernel key version.
Change-Id: I364ab50bda115991dd4f69331d37291f66abbf36
BUG=chrome-os-partner:3274, chromium-os:8016
TEST=Manually tested using a newly generated keyset.
Review URL: http://codereview.chromium.org/6824059
Also re-factor the key generation script to its own directory, including wrappers for generating key pairs and keyblocks without needing to start keyset generation process from scratch. (Useful for generating new kernel keyblocks, and for retroactively adding new keys to an existing keyset - as in this case).
Finally, change hard coded algorithm ids and keyblock modes to bash variables, for each changes and telling keyset configuration from a glance.
BUG=chrome-os-partner:2218
TEST=manually tried the following:
1) Generating an entire new keyset.
2) Generating a new key pair and creating a keyblock from an existing key (for generating dev firmware keyblock for existing PVT keysets)
3) Firmware signing via sign_official_build.sh of an image with a firmware payload/
Change-Id: I4e9bb96ac7e5fe4cc0d95af6162ad6d37bbd4bda
Review URL: http://codereview.chromium.org/6594131
