The dev_firmware* was created for legacy devices having different RW
firmware - A for devmode and B for normal, like Alex and ZGB.
All other Chromebooks, including the CR48, were not doing that.
Signer scripts relied on checking if RW A/B are equivalent to decide if
they should select <dev_firmware* for A, firmware* for B> or <firmware*
(normal) for both A and B>. This worked for a long time until Skylake
family joined.
Skylake FSP has some limitation that we have to execute code in-place,
which leads to making RW A != B (due to addresses and offsets), and
triggers signer to incorrectly use dev_firmware*.
The production images are using keyset folders on signerbot, which only
Alex/ZGB keyset folders have dev_firmware*; so the images for Skylake
boards are signed correctly. But for people running firmware related
tests using tests/devkey keyset, for example
platform/dev/fm_and_key_version_test_prep.sh, having dev_firmware* in
devkey may produce incorrect output.
There is currently no easy way for signer scripts to figure out if the
image should use dev_firmware or not except looking into keyset folder.
Since Alex and ZGB are pretty old and no one plans to run key change
tests anymore on them, the recommended solution is to remove
dev_firmware.* from devkeys folder.
BRANCH=none
BUG=chrome-os-partner:52568
TEST=platform/dev/fm_and_key_version_test_prep.sh -b sentry -i \
/tmp/chromiumos_test_image.bin -f 8530.69.0 -s /tmp/image.bin -v \
Google_Sentry.7820.156.0
Change-Id: Ief37dd482875efc8e808460f3ad00041b5f3b3a2
Reviewed-on: https://chromium-review.googlesource.com/378661
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
sign_android_image.sh is the main script that signs the image. It makes
similar changes to an image like the Android official signing tool
(sign_target_files_apks.py) does, but more Chrome OS specific.
TEST=./sign_official_build.sh recovery recovery_image.bin \
../../tests/devkeys/ out_img
TEST=Same above but with a recovery image without Android image.
Android signing was skipping.
TEST=Same above but with a M53 image. Android signing was skipped.
TEST=Unpack the image and diff the before and after. Looks correct.
BUG=b:29915721
Change-Id: I0ae5f0ad8d2b05e485d60262558517ea563bf527
Reviewed-on: https://chromium-review.googlesource.com/366794
Commit-Ready: Victor Hsieh <victorhsieh@chromium.org>
Tested-by: Victor Hsieh <victorhsieh@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Move around the test keys used for standalone accessories signing
unittesting, so they are easier to use.
BRANCH=smaug, samus
BUG=chrome-os-partner:46635
TEST=run cros-signing unittests (./signing_unittests.py)
Change-Id: I02fcf444ec76bf6ebf6eb477e1236869aa877210
Reviewed-on: https://chromium-review.googlesource.com/309967
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
My previous patch using futility to re-sign standalone accessory
firmware images had a mistake in the key directory path : fix it.
Also add RSA-2048 'accessory' keys for signer unit testing.
BRANCH=smaug, samus
BUG=chrome-os-partner:46635
TEST=run cros-signing unittests (./signing_unittests.py)
Change-Id: Ia2f641c85337c67f81968be4730643a6ad5f22cf
Reviewed-on: https://chromium-review.googlesource.com/309530
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Signing test of firmware for non-t210 targets fails when PKC
keys are present so separate devkeys into two keysets where only
one has the PKC key.
BUG=chrome-os-partner:44227
TEST=sign_official_build.sh nv_lp0_firmware tegra_lp0_resume.fw tests/devkeys-pkc tegra_lp0_resume.fw.signed versions.default
BRANCH=signer
Change-Id: Ie0670638d30d17692f1113b5a9f0309ea610d72a
Signed-off-by: David Riley <davidriley@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/298091
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Signer was calling sign_official_build.sh in a manner that wasn't
being accepted correctly. Also add test keys from firmware branch.
BUG=chrome-os-partner:44227
TEST=sign_official_build.sh nv_lp0_firmware tegra_lp0_resume.fw tests/devkeys tegra_lp0_resume.fw.signed versions.default
BRANCH=signer
Change-Id: Icd298ac75e3da746220826dc2fb9cc2466e41f1d
Signed-off-by: David Riley <davidriley@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/297802
Reviewed-by: Furquan Shaikh <furquan@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>
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
The existing keys are kept the same, so that old dev kernels and
firmware remain compatible with new kernels and firmware.
Change-Id: I4177d1868904a477d79b9f2e6de88ed756ed57b4
BUG=chrome-os-partner:2218
TEST=manual:
Build firmware with new keys.
Boot with dev switch on.
Run 'crossystem mainfw_act mainfw_type'.
Should see "A developer"
Boot with dev switch off.
Run 'crossystem mainfw_act mainfw_type'.
Should see "B normal"
Review URL: http://codereview.chromium.org/6580035
This change makes dumpRSAPublicKey directly accept a public key in PEM format. This makes it possible to avoid the unnecessary step of generating a self-signed certificate to dump the public key in .keyb format.
The old style certificate input is still accepted.
Using certs (as done previously):
dumpRSAPublicKey -cert <certfile>
Directly using public keys:
dumpRSAPublicKey -pub <pubfile>
Change-Id: Ic35b59aff6613d145d7947212650da281f734b74
BUG=7576
TEST=manual
$ openssl genrsa -F4 -out test.pem 4096
$ openssl rsa -in test.pem -out test.pub
$ dumpRSAPublicKey -pub test.pub >test.pub.keyb
Verify that this matches the output we get using the old style <cert> input.
$ openssl req -batch -new -x509 -key test.pem -out test.cert
$ dumpRSAPublicKey -cert test.cert >test.cert.keyb
$ diff test.pub.keyb test.cert.keyb
$
Review URL: http://codereview.chromium.org/4215006
The make_dev_ssd.sh is made for devinstall shim to
change SSD kernels to be signed by dev keys.
- Kernel A, B will be resigned with dev keys (ignore if A/B seems not bootable)
- Adding param --remove_rootfs_verification can even disable rootfs hash check
This CL also includes some shared refine/fix to make_dev_firmware.sh
BUG=chrome-os-partner:1276
TEST=sudo ./make_dev_ssd.sh; (seeing Kernel A is resigned and B is ignored)
then reboot without developer mode (OK),
rootdev shows /dev/dm-0, rootdev -s shows /dev/sda3
sudo ./make_dev_ssd.sh --remove_rootfs_verification;
then reboot without developer mode (OK), rootdev shows /dev/sda3
Change-Id: Ic20f734b2af42e50a43c19a565a166a39d57a7fd
Review URL: http://codereview.chromium.org/3772013
Make vbutil_keyblock handle unsigned blocks. Also enable --unpack option and
add tests for it.
Modify vbutil_kernel to allow unsigned keyblocks, correct usage message,
and fix the --debug option which was somehow disabled.
Update load_kernel_test to accept /dev/null for the public key, to test
non-signed kernel keyblocks.
Review URL: http://codereview.chromium.org/3124004
