firmware_keys field in the HWID database also contains hash of recovery
key so need this information as well in order to deprecate firmware_keys
field.
BUG=chromium:763328
TEST=1) ~/trunk/src/platform/vboot_reference/scripts/image_signing/sign_official_build.sh
recovery ./chromeos_10644.0.0_soraka_recovery_dev-channel_mp.bin
./src/platform/vboot_reference/tests/devkeys ./output.bin
2) verify output file - VERSION.signer.
BRANCH=None
Change-Id: If2be93723e95d46fc0546239695be27c3229275c
Reviewed-on: https://chromium-review.googlesource.com/1053334
Commit-Ready: Marco Chen <marcochen@chromium.org>
Tested-by: Marco Chen <marcochen@chromium.org>
Reviewed-by: Wei-Han Chen <stimim@chromium.org>
Reviewed-by: C Shapiro <shapiroc@google.com>
CL:866522 supported the case of loem and uni-build projects but not for
the project with one key only. After this CL, `gooftool finalize` can
refer to VERSION.signer in order to get correct firmware key hash from
recovery image. As the result, firmware_keys field can be removed from
HWID database.
BUG=chromium:763328
TEST=1) ~/trunk/src/platform/vboot_reference/scripts/image_signing/sign_official_build.sh
recovery ./chromeos_10644.0.0_soraka_recovery_dev-channel_mp.bin
./src/platform/vboot_reference/tests/devkeys ./output.bin
2) verify output file - VERSION.signer.
BRANCH=None
Change-Id: I376cd7038c0fe1d5cc71cb39cbabeb5e79994407
Reviewed-on: https://chromium-review.googlesource.com/1051429
Commit-Ready: Marco Chen <marcochen@chromium.org>
Tested-by: Marco Chen <marcochen@chromium.org>
Reviewed-by: Marco Chen <marcochen@chromium.org>
Reviewed-by: C Shapiro <shapiroc@google.com>
Newer versions of util-linux/mount don't like when you create overlapping
loopback files. Since we always create a loopback of the entire image,
this means every mount fails.
We can change the few users in here over to using the existing loopback
partitions rather than continuing to create their own from scratch. This
makes the code a bit simpler.
However, we currently duplicate some of the mount image helpers so that
one version works off of a disk image while the other uses loopbacks.
Cleaning this up requires a number of changes in other files which we'll
want to do eventually, just not right now (to minimize risk).
BUG=chromium:714598
TEST=image signing works on newer gLinux installs
BRANCH=None
Change-Id: I31b35636b3b271e97070d283f8cb74d3183d8ec8
Reviewed-on: https://chromium-review.googlesource.com/1034435
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Jason Clinton <jclinton@chromium.org>
Follow up the code review comments on CL:995174, which was merged as
7dff0105d6
("keygeneration: add support for UEFI key generation")
BUG=b:62189155
TEST=See the following commit.
BRANCH=none
Change-Id: Id642029010e4eea51ec1f7d23240678f3f07e872
Reviewed-on: https://chromium-review.googlesource.com/1024917
Commit-Ready: Edward Jee <edjee@google.com>
Tested-by: Edward Jee <edjee@google.com>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Signature Scheme V2 was introduced in N.
TEST=(prepare)
1. Produce A.img by running the original sign_android_image.sh on a
test image.
2. Produce B.img by running the new sign_android_image.sh on the
same image.
TEST=Check Settings.apk with apksigner. Saw only v1 signature exists
with A.img, and only v2 exists with B.img, as expected.
Certificates on both APKs have the same fingerprint.
TEST=Login with A to create a new /data state, then login with B.
Platform apps still run. No signature error in logcat.
BRANCH=none
BUG=b:67942659
Change-Id: Ibabc399563bfdc92836856a377997405cc660483
Reviewed-on: https://chromium-review.googlesource.com/993153
Commit-Ready: Victor Hsieh <victorhsieh@chromium.org>
Tested-by: Victor Hsieh <victorhsieh@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Whiskers decided to leverage the key format of Hammer therefore this
script calls Hammer's one to generate a key pair and renames them to
key_whiskers*.
BUG=b:78254017
TEST=Run this script in the chroot and verify the generated key pair.
BRANCH=None
Change-Id: Iae7097a3b2da1b134fa1a986c669704bbbaca4e9
Reviewed-on: https://chromium-review.googlesource.com/1018591
Commit-Ready: Patrick Berny <pberny@chromium.org>
Tested-by: Patrick Berny <pberny@chromium.org>
Reviewed-by: Jason Clinton <jclinton@chromium.org>
Reviewed-by: Bob Moragues <moragues@chromium.org>
Wand decided to leverage the key format of Hammer therefore this
script calls Hammer's one to generate a key pair and renames them to
key_wand*.
BUG=b:73799441
TEST=Run this script in the chroot and verify the generated key pair.
BRANCH=None
Change-Id: Id2749d78e0632bee66c09c4ee7aa1930534157b7
Reviewed-on: https://chromium-review.googlesource.com/991532
Commit-Ready: Marco Chen <marcochen@chromium.org>
Tested-by: Marco Chen <marcochen@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Looks like we forgot to update the help text for set_gbb_flags.sh when
adding the DISABLE_FMWP flag. This patch fixes that.
BRANCH=None
BUG=None
TEST=None
Change-Id: Iae45e151ae786565f6a1a695a2e3c3d01f8c1d0a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/976801
Reviewed-by: Randall Spangler <rspangler@chromium.org>
It seems like there are some testing use cases where we want the device
to boot into the recovery installer but it is impractical to fully
simulate a user-triggered recovery. This has become impossible with the
recent change to always require manual recovery to boot an image, even
when the developer mode switch is enabled (CL:924458).
This patch adds a new GBB flag to support this use case. When the flag
is set, all recovery mode is manual recovery mode, regardless of wheter
the developer mode switch is on or not.
Since the GBB_FLAG_ENABLE_SERIAL was killed off before it ever really
worked anyway, we can safely reuse the bit reserved for it.
BRANCH=None
BUG=None
TEST=make runtests, manually confirmed on Kevin
Change-Id: I4f51dfd20b4ff04c522f53596896dccbceee52dc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/976660
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This regenerates packages cache during signing the image once apks are
changed due timestamp and key update.
TEST=Build image, sign it useing devkeys and deploy to device. Perform
user sign-in and enable ARC. Test logcat and everything is clear.
BUG=b:74108152
Change-Id: I4809a1f87c8b8f52094054dbb4c8ba3e059aee89
Reviewed-on: https://chromium-review.googlesource.com/948064
Commit-Ready: Yury Khmel <khmel@google.com>
Tested-by: Yury Khmel <khmel@google.com>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
- move helper functions that detect which keys should be used depending
on the build flavor to a separate lib
- add unit tests for that lib
BUG=b:72947583
TEST=unit tests
TEST=run against caroline image, scripts detects 'cheets' build flavor
TEST=run against novato-arc64 image (SDK), script detects 'cheets' build
flavor
TEST=run against newbie image (AOSP), script detects 'aosp' build flavor
TEST=run against invalid build property 'paosp_cheets_...', script
aborts as expected
BRANCH=None
Change-Id: I5595c10a5a063e7658d0cf17c77dbeead429cd97
Reviewed-on: https://chromium-review.googlesource.com/923097
Commit-Ready: Nicolas Norvez <norvez@chromium.org>
Tested-by: Nicolas Norvez <norvez@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
The original "ro.product.name" of the Android image is modified by the
Chrome OS build process to change it to the CrOS device name instead,
which breaks the detection of the build flavor.
Instead, we now rely on the "ro.build.flavor" property which is not
modified.
If the build flavor is either cheets_* or sdk_google_cheets_*, we expect
the keys to be the cheets keys. AOSP keys are used for aosp_cheets_*
build flavors.
BUG=b:72947583
TEST=run against caroline image, scripts detects 'cheets' build flavor
TEST=run against novato-arc64 image (SDK), script detects 'cheets' build
flavor
TEST=run against newbie image (AOSP), script detects 'aosp' build flavor
TEST=run against invalid build property 'paosp_cheets_...', script
aborts as expected
BRANCH=None
Change-Id: I662436b256b59238b00c7374120f315b538fcd75
Reviewed-on: https://chromium-review.googlesource.com/911905
Commit-Ready: Nicolas Norvez <norvez@chromium.org>
Tested-by: Nicolas Norvez <norvez@chromium.org>
Reviewed-by: Victor Hsieh <victorhsieh@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Following ag/3536780, aosp_cheets targets have their APKs signed with
keys https://android.googlesource.com/platform/build/+/master/target/product/security/
The image signing script now:
- detects if it's an aosp_cheets or cheets build
- checks the correct signing keys have been used in either case
- logs more information about the Android image
BUG=b:72947583
TEST=manually test sign_framework_apks against AOSP and cheets builds
TEST=aosp_cheets builds prior to ag/3536780 are now failing (expected)
TEST=aosp_cheets builds posterior to ag/3536780 are passing
TEST=cheets builds (before and after) are passing
TEST=check that commenting out ro.product.name in build.prop triggers an
error
TEST=check that an invalid value in ro.product.name triggers an error
BRANCH=None
Change-Id: I72abea5182fbfe76820e3f48831be04f39cb334e
Reviewed-on: https://chromium-review.googlesource.com/904726
Commit-Ready: Nicolas Norvez <norvez@chromium.org>
Tested-by: Nicolas Norvez <norvez@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
For the EC supporting EFS boot, the RO section contains a
public key, and the RW is signed. For running FAFT, should
replace the RO key to a known one (the dev key under
vboot_reference), such that FAFT tests can resign the RW
using a known private key.
For BIOS image, we use make_dev_firmware.sh to do a similar
job to replace the key in BIOS. This CL makes the
make_dev_firmware script support changing EC key.
BUG=b:71769443
BRANCH=none
TEST=Modify files
$ # Check the original BIOS and EC images
$ futility show ec.bin
$ futility show bios.bin
$ ./make_dev_firmware.sh --change_ec -f bios.bin -t new_bios.bin \
-e ec.bin -o new_ec.bin --backup_dir backup
$ # Check the new images, using new keys and verification succeeded
$ futility show new_ec.bin
$ futility show new_bios.bin
TEST=Modify live firmware
$ ./make_dev_firmware.sh --change_ec
And then run firmware_ECUpdateId with a Type-C charger.
TEST=Run sign_official_build.sh
$ sign_official_build.sh recovery recovery_image.bin \
~/trunk/src/platform/vboot_reference/tests/devkeys /tmp/out.bin
TEST=make runalltests
Change-Id: Id51e2c411a4e6d016e619cec91453ce918b7fff7
Reviewed-on: https://chromium-review.googlesource.com/889406
Commit-Ready: Wai-Hong Tam <waihong@google.com>
Tested-by: Wai-Hong Tam <waihong@google.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
To record sha1sum of keys in keyset can help loem or unibuild projects to verify
1. whether rekey process is performed correctly during the factory
build.
2. whether HWID database is updated correctly.
BUG=chromium:763328
TEST=1) modify loem.ini to match what coral is.
2) ~/trunk/src/platform/vboot_reference/scripts/image_signing/sign_official_build.sh
recovery ./chromeos_10308.0.0_coral_recovery_dev-channel_mp-v4.bin
./src/platform/vboot_reference/tests/loemkeys ./output.bin
3) verify output file - VERSION.signer.
BRANCH=none
Change-Id: I80deadb04d9dc0eb66fc5ac45dce84e6f41f1a16
Signed-off-by: Marco Chen <marcochen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/866522
Reviewed-by: Simon Glass <sjg@chromium.org>
The helper function - info redirects msg to stderr and appends some
backslash escapes so
1. it can't be redirected to VERSION.signer via stdout again.
2. Even if change to stderr, we also don't want these appended
msg.
BUG=chromium:760879
TEST==~/trunk/src/platform/vboot_reference/scripts/image_signing/sign_official_build.sh
recovery ../build/images/coral/latest/recovery_image.bin
../platform/vboot_reference/tests/devkeys
BRANCH=None
Change-Id: I46d560fb4cb93756fd02e32412410afb3a4db0e2
Reviewed-on: https://chromium-review.googlesource.com/861694
Commit-Ready: Marco Chen <marcochen@chromium.org>
Tested-by: Marco Chen <marcochen@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
We are not zeroing the free space properly before signing official images. This
patch fixes it by using fstrim instead of dd. More info can be found in
CL:751809.
BRANCH=none
BUG=chromium:780291
TEST=used sign_official_build.sh to sign two recovery images (these images produced <zero-space> file) with dev keys. Then generated delta update between the two new images. This time there was no <zero-space> file between the two images.
Change-Id: Ib97fb206f5c8bcfd97c43d075990c7fcdaad6f7e
Reviewed-on: https://chromium-review.googlesource.com/848237
Commit-Ready: Amin Hassani <ahassani@chromium.org>
Tested-by: Amin Hassani <ahassani@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
introduce get_gbb_flags.sh command to make automatic annotation
of power measurements easier.
Also, fix issue where declaring local variables on same line
as executing a command would obfuscate error code, thus not
triggering set -c and continuing execution.
https://github.com/koalaman/shellcheck/wiki/SC2155
Usage:
$ /usr/share/vboot/bin/get_gbb_flags.sh
[...]
ChromeOS GBB set flags: 0x00000329.
$ /usr/share/vboot/bin/get_gbb_flags.sh -e
[...]
ChromeOS GBB set flags: 0x00000329.
ChromeOS GBB set flags listed:
GBB_FLAG_DEV_SCREEN_SHORT_DELAY
GBB_FLAG_FORCE_DEV_SWITCH_ON
GBB_FLAG_DISABLE_FW_ROLLBACK_CHECK
GBB_FLAG_FAFT_KEY_OVERIDE
GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC
BUG=chromium:760267
BRANCH=none
TEST=manual
emerge-soraka vboot_reference
cros deploy <IP> vboot_reference
(on DUT)
/usr/share/vboot/bin/get_gbb_flags.sh -e
<same output as above>
Change-Id: Idb3b993706c03e7f2831eed2cef12a04b9469fea
This patch makes sign_official_build.sh resign ec.bin and store
signed RW copies in bios.bin if the original ec.bin contains
signed RW copies.
BUG=b:66956286
BRANCH=none
CQ-DEPEND=CL:738794,CL:*490792
TEST=sign_official_build.sh recovery recovery_image.bin \
~/trunk/src/platform/vboot_reference/tests/devkeys /tmp/out.bin
Change-Id: I73c7d8da7d8e2f770e5952d0124f8d43bb13e592
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/734295
Let's use the actual command/path used to call make_dev_ssd.sh,
instead of hard-coding './'.
BRANCH=none
BUG=none
TEST=/usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification
outputs a command that can just be copy-pasted:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partitions 4
(instead of:
sudo ./make_dev_ssd.sh --remove_rootfs_verification --partitions 4
)
Change-Id: I903f94acc1fb310926b149c1e79e4017bf513e27
Reviewed-on: https://chromium-review.googlesource.com/737810
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Staff decided to leverage the key format of Hammer therefore this
script calls Hammer's one to generate a key pair and renames them to
key_staff*.
BUG=b:66889892
TEST=Run this script in the chroot and verify the generated key pair.
BRANCH=None
Change-Id: I73162efaba47a8c08336805130ced0be25ab262a
Reviewed-on: https://chromium-review.googlesource.com/688522
Commit-Ready: Marco Chen <marcochen@chromium.org>
Tested-by: Marco Chen <marcochen@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Android master puts that file at a different location, so use similar
logic to official signing script.
TEST="sign_android_image.sh passed locally for both caroline (NYC) &
caroline-bertha (master)."
BUG=b:65610114
BRANCH=none
Change-Id: If33bfbcaa7e6cff95f26ff26a91735c87880f3db
Reviewed-on: https://chromium-review.googlesource.com/686046
Commit-Ready: Garfield Tan <xutan@chromium.org>
Tested-by: Garfield Tan <xutan@chromium.org>
Reviewed-by: Victor Hsieh <victorhsieh@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
If the channel is missing or has whitespace, the test triggers
errors in the script because the test command has bad quoting.
BUG=None
TEST=script no longer fails on an empty lsb-release
BRANCH=None
Change-Id: Ic2e6ab91ca4ec10c298d122aee1f7f7236b52bf2
Reviewed-on: https://chromium-review.googlesource.com/680059
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: David Riley <davidriley@chromium.org>
Nothing needs this, just something I noticed while debugging.
BUG=None
TEST=`ensure_sane_lsb-release.sh` no longer complains about comment lines
BRANCH=None
Change-Id: Ia39e6461db79a387cc59e5f88ec1216984bb4d28
Reviewed-on: https://chromium-review.googlesource.com/680058
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
This feature was originally implemented before go/cros-unibuild-signing.
It only provided basis support to continue testing unibuilds, but didn't
deal with the actual required model specific cases.
Unibuilds have already been migrated away from this, so this feature is
now obsolete.
BUG=None
TEST=~/trunk/src/platform/vboot_reference/scripts/image_signing/sign_official_build.sh
recovery ../build/images/coral/latest/recovery_image.bin
../platform/vboot_reference/tests/devkeys
BRANCH=None
Change-Id: I58b569b97f0bf42a927a851e7bc0559cb1e26200
Reviewed-on: https://chromium-review.googlesource.com/660805
Commit-Ready: C Shapiro <shapiroc@google.com>
Tested-by: C Shapiro <shapiroc@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
For model specific signatures, the root key needs to be copied also for
the development case where the root key can be flashed into the RO
block.
BUG=b:65367246
TEST=./build_image --board=coral dev \
&& ./mod_image_for_recovery.sh --board=coral \
&& ~/trunk/src/platform/vboot_reference/scripts/image_signing/sign_official_build.sh \
recovery ../build/images/coral/latest/recovery_image.bin \
../platform/vboot_reference/tests/devkeys
BRANCH=None
Change-Id: I116850881d3c183b20e7d75e40deb13122f40c7a
Reviewed-on: https://chromium-review.googlesource.com/650546
Commit-Ready: C Shapiro <shapiroc@google.com>
Tested-by: C Shapiro <shapiroc@google.com>
Reviewed-by: C Shapiro <shapiroc@google.com>
The grep pattern was too lenient and allowed for matches with the same
shared root key id. E.g. NASHER also matched NASHER360
This changes the pattern to match exactly to the end of the line.
BUG=b:65284008
TEST=grep -E "[0-9]+ = NASHER$" ~/tmp/loem.ini with actual loem.ini
that will exist on the signers
BRANCH=None
Change-Id: I80a870cd512825d30c7a39e4ac6f3cffc9ea808d
Reviewed-on: https://chromium-review.googlesource.com/647800
Commit-Ready: C Shapiro <shapiroc@google.com>
Tested-by: C Shapiro <shapiroc@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: YH Lin <yueherngl@chromium.org>
updater4.sh uses the /keyset subdir from the firmware updater shellball
to indicate if it should use model specific keys or not. This won't
work for any case where the signers haven't been updated with model
specific keys yet.
Changed the output for unibuilds to be consistent with non-uni builds
where the /keyset subdir won't be created if loem.ini doesn't exist on
the signer.
BUG=b:65128657
TEST=crrev.com/c/626718 and crrev.com/c/636344 test cases, which cover
both the shared and non-shared key use cases
BRANCH=None
Change-Id: I38db1385fa99ac4a9843a750c336c58b74b127b4
Reviewed-on: https://chromium-review.googlesource.com/642031
Commit-Ready: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Tested-by: C Shapiro <shapiroc@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jason Clinton <jclinton@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Updated the current coral config to use the fake keys from the loemkeys
dev keyset (ACME) and then tested/debugged this flow based on that
config.
Fixed issue where key_id wasn't eval'd in bash when it was passed to
grep because it has ' quotes around it.
BUG=b:64842314
TEST=~/trunk/src/platform/vboot_reference/scripts/image_signing/sign_official_build.sh
recovery
../build/images/coral/R62-9877.0.2017_08_25_1030-a1/recovery_image.bin
../platform/vboot_reference/tests/loemkeys
coral_loem_signed_recovery.bin
BRANCH=None
Change-Id: I50a58e512e9a83dc2707951f12d709f9006d67ca
Reviewed-on: https://chromium-review.googlesource.com/636344
Commit-Ready: C Shapiro <shapiroc@google.com>
Tested-by: C Shapiro <shapiroc@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
We would like to have different signature versions for hammer
(1=dev, 2=premp, 3=mp), so we should pass --version to futility.
The default version stays 1.
BRANCH=none
BUG=b:35587169
TEST=openssl genrsa -3 -out key_hammer.pem 2048
futility create --desc="Hammer fake MP key" key_hammer.pem key_hammer
echo firmware_version=2 > key_hammer.version
../vboot_reference/scripts/image_signing/sign_official_build.sh \
accessory_rwsig build/hammer/ec.bin . \
ec-signed.bin key_hammer.version
futility show ec-signed.bin => Version: 0x00000002
TEST=Without passing a version file, version is still 1.
../vboot_reference/scripts/image_signing/sign_official_build.sh \
accessory_rwsig build/hammer/ec.bin . ec-signed.bin
futility show ec-signed.bin => Version: 0x00000001
Change-Id: I0cd9133404fb0d827bd2f0d3bcc71d5dd274734d
Reviewed-on: https://chromium-review.googlesource.com/631757
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
For design context, see go/cros-unibuild-signing
This adds support for multiple, shared firmware images from a unified
build that needs to be signed with different OEM specific keys.
It uses a signer_config.csv file (that is generated by pack_firmware.py)
to determine which images need to be signed with which keys.
BUG=b:64842314
TEST=./build_image --board=coral dev
&& ./mod_image_for_recovery.sh --board=coral
&& ~/trunk/src/platform/vboot_reference/scripts/image_signing/sign_official_build.sh
recovery ../build/images/coral/latest/recovery_image.bin
../platform/vboot_reference/tests/devkeys
BRANCH=None
Change-Id: Id3711bbe73dfe652184bc046b5f642c30b8d1627
Reviewed-on: https://chromium-review.googlesource.com/626718
Commit-Ready: C Shapiro <shapiroc@google.com>
Tested-by: C Shapiro <shapiroc@google.com>
Reviewed-by: C Shapiro <shapiroc@google.com>