http://codereview.chromium.org/5878005 modified common.sh but the final checked in CL clobbered some of the variable defintions (most likely due to a manual merge) making the scripts that use it to fail. This CL puts them back.
BUG=chrome-os-partner:1903
TEST=manual; sign_official_build gets hung before, works fine now.
Change-Id: I8d19a086d66b0a0d1e9f7231a14fcf37d42a2f01
Review URL: http://codereview.chromium.org/6104002
Also refactor the other scripts to move more common functions (debug output, etc.) to common.sh.
BUG=chrome-os-partner:1903
TEST=manual; ran on a Chrome notebook, verified the right things got copied.
Review URL: http://codereview.chromium.org/5878005
Change-Id: Ib7131356ecb6f88eee3d529a518f23b94756d0c0
This script preserves the root file system metadata as much as possible
between the specified image and the latest shipping image. It preserves
the metadata by ensuring that the files reuse the same inodes and that they
are located at the same physical location on-disk. This leads to smaller
auto-update delta payload and less disk reshuffling, extending the life
of the SSD.
It is called before the image is signed during the stamping process.
Currently, this only supports x86-mario.
This is a continuation of a previous CL located at:
http://codereview.chromium.org/6058006/
BUG=chromium-os:10188
TEST=Build image, boot image, auto-update to new image, run suite_Smoke
Change-Id: I3270245dc15a074abb3bac250922c30e2e105f92
Review URL: http://codereview.chromium.org/6079004
This adds an optional --force argument which is needed if one attempts to change the password on an image where it is already set.
BUG=chrome-os-partner:1460
TEST=manually tested
Change-Id: I56a95fe4d699ce02c7a68e5be14cc7dce0609a54
Review URL: http://codereview.chromium.org/4480001
Copies the helpers from crosutils.git/common.sh but uses
printf with octals for portability. This should update all
locations where we mount root rw and disable_rw_mounts just before
a final sign.
TEST= in progres; plz help :)
BUG=chromium-os:7972
Change-Id: Ibdd23cb30335942c36d537663aabea605a2f8704
Review URL: http://codereview.chromium.org/3987001
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
The make_dev_firmware.sh is made for devinstall shim to
change firmware rootkey/HWID/BMPFV smoothly.
- HWID will be changed to "$ORIGINAL_FWID DEV" (no change if already postfixed
with DEV)
- rootkey/recoverykey will be changed by keyset from --keys
- FVMAIN/FVMAINB will be resigned by keyset from --keys
- BMPFV will be changed to anything assigned by --bmpfv
If --from and --to are omitted, the system firmware will be changed.
A new ebuild is be created to put all resources (bmpfv and keyset) into devinstall shim (ref: http://codereview.chromium.org/3776003)
BUG=chrome-os-partner:1276
TEST=sudo ./make_dev_firmware.sh --from input_bios.bin --to output_bios.in \
--keys ../../tests/devkeys --bmpfv some_bmpfv.bin
HWID is changed from "XXX MARIO EVT DDDD" to "XXX MARIO EVT DDDD DEV".
System can then boot a USB signed with devkey without developer mode.
Change-Id: Id80126495dcbf4d993a4372af645580cd4b60ca6
Review URL: http://codereview.chromium.org/3822002
There are several procedures in Chrome OS post-processing before being released:
stamping, tagging, mod image for URLs, ... and signing.
We need an integrated script to handle all the stamping / tagging.
This CL can handle empty tag files like /root/.force_update_firmware
or /root/.dev_mode.
This CL deprecates http://codereview.chromium.org/3421040 and moved script
from crosutils to vboot_reference. In the future we may isolate the non-signing
post-processing scripts (set_lsb, tag_image, remove_label, ...) into crosutils.
BUG=none
TEST=manually:
(1) Build a general dev image without firmware updates (default behavior of build_image for x86-generic ToT)
(2) Enter chroot and then execute:
cd ~/trunk/src/platform/vboot_reference/scripts;
./tag_image.sh \
--from ~/trunk/src/build/images/x86-generic/latest/chromiumos_image.bin
Expected: output message:
Update Firmware: disabled
Developer Mode: Enabled
(3) ./tag_image.sh --update_firmware=1 --dev_mode=0 \
--from ~/trunk/src//build/images/x86-generic/latest/chromiumos_image.bin
Expected: output message:
Update Firmware: disabled => Enabled
Developer Mode: Enabled => disabled
Manually verify:
pushd ../../build/images/x86-generic/latest
unpack_partitions.sh chromiumos_image.bin
sudo mount -o loop,ro part_3 rootfs
ls -l rootfs/root/.force_update_firmware # this file should exist
ls -l rootfs/root/.dev_mode # this file should NOT exist (i.e., error)
sudo umount rootfs
(4) ./tag_image.sh --update_firmware=0 --dev_mod=1 \
--from ~/trunk/src/build/images/x86-generic/latest/chromiumos_image.bin
Expected: output message:
Update Firmware: Enabled => disabled
Developer Mode: disabled => Enabled
Manually verify:
pushd ../../build/images/x86-generic/latest
unpack_partitions.sh chromiumos_image.bin
sudo mount -o loop,ro part_3 rootfs
ls -l rootfs/root/.force_update_firmware # this file should NOT exist (i.e., error)
ls -l rootfs/root/.dev_mode # this file should exist
sudo umount rootfs
Change-Id: I96af3c7201372bb904426d10cff142467a1fa2e7
Review URL: http://codereview.chromium.org/3604001
If we just want to read the current lsb-release, we shouldn't need to break rootfs verification.
Change-Id: I5ba6ddbd9f5801783a568b6806392184b683f628
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/3563001
This option will perform verification operations on an image.
1) Check if the RootFS hash is correct.
2) Check if the image will verify using recovery keys (in recovery mode)
3) Check if the image will verify using SSD keys (in non-recovery mode)
2) and 3) are both tested with and without dev mode.
Also re-factor existing code for rootfs calculation and update.
BUG=5830,3496
TEST=manual
Example usage and output follows:
# Verifying an image meant for factory install.
sudo ./sign_official_build.sh verify factory_install_image.sh ../../tests/devkeys/
Verifying RootFS hash...
PASS: RootFS hash is correct
Testing key verification...
With Recovery Key (Recovery Mode ON, Dev Mode OFF): NO
With Recovery Key (Recovery Mode ON, Dev Mode ON): YES
With SSD Key (Recovery Mode OFF, Dev Mode OFF): NO
With SSD Key (Recovery Mode OFF, Dev Mode ON): YES
# Verifying an image meant for recovery mode.
sudo ./sign_official_build.sh verify recovery_image.bin ../../tests/devkeys/
Verifying RootFS hash...
PASS: RootFS hash is correct
Testing key verification...
With Recovery Key (Recovery Mode ON, Dev Mode OFF): YES
With Recovery Key (Recovery Mode ON, Dev Mode ON): YES
With SSD Key (Recovery Mode OFF, Dev Mode OFF): NO
With SSD Key (Recovery Mode OFF, Dev Mode ON): YES
# Verifying an image meant for the SSD drive.
sudo ./sign_official_build.sh verify ssd_image.bin ../../tests/devkeys/
Verifying RootFS hash...
PASS: RootFS hash is correct
Testing key verification...
With Recovery Key (Recovery Mode ON, Dev Mode OFF): NO
With Recovery Key (Recovery Mode ON, Dev Mode ON): NO
With SSD Key (Recovery Mode OFF, Dev Mode OFF): YES
With SSD Key (Recovery Mode OFF, Dev Mode ON): YES
# Image with an incorrect rootfs hash but otherwise validly signed
sudo ./sign_official_build.sh verify ssd_image.bin ../../tests/devkeys/
Verifying RootFS hash...
FAILED: RootFS hash is incorrect.
Expected: ebce345727ca05ea9368d3b8d5ce1c81471d7d3b
Got: 9b092985996bb2422b11487a66929a1a004df4fc
Testing key verification...
With Recovery Key (Recovery Mode ON, Dev Mode OFF): NO
With Recovery Key (Recovery Mode ON, Dev Mode ON): NO
With SSD Key (Recovery Mode OFF, Dev Mode OFF): YES
With SSD Key (Recovery Mode OFF, Dev Mode ON): YES
# Image signed using a different set of keys (but validly signed).
sudo ./sign_official_build.sh verify invalid_image.bin ../../tests/devkeys/
Verifying RootFS hash...
PASS: RootFS hash is correct (70e6f2de0220991fd503a6fcc7edac131b4a48ca)
Testing key verification...
With Recovery Key (Recovery Mode ON, Dev Mode OFF): NO
With Recovery Key (Recovery Mode ON, Dev Mode ON): NO
With SSD Key (Recovery Mode OFF, Dev Mode OFF): NO
With SSD Key (Recovery Mode OFF, Dev Mode ON): YES
Change-Id: I4960cdbbbe93e685346417b882739f9cfd5f6b75
Review URL: http://codereview.chromium.org/3327005
The build signing script will now re-sign the chrome os AU payload in the image rootfs using the new keys. In addition, it will recalculate and update the RootFS hash (in the kernel partition) before re-signing the whole image using the new "official" keys.
BUG=3496, 5264
TEST=manual
>>>>>For testing rootfs hash updates
1) Ensure that image was build with the --enable_rootfs_verification flag
2) Mount the root file fs on the input image, and make a minor change to the root fs (e.g. adding a file)
3) Now boot from this image, drop into the shell and look for logs related to dm-bht in the dmesg output.
4) You should see dm-bht complaining about block hash mismatches
$ dmesg | grep dm
..... <dm-bht errors>.......
<errors of the form "dm-bht: Block hash match failed">
4) Now re-sign the modified image using the sign_official_build script. This will re-calculate and update the rootfs hash.
5) Boot from the re-signed image. Look at dmesg output.
6) You should see NO dm-bht errors.
>>>>>For testing re-signing of firmware payload
Grab the firmware autoupdate shellball from /usr/sbin/chromeos-firmwareupdate in the output image's rootfs partition (number 3). Extract the shellball (--sb_extract flag), and grab the firmware bios.bin from the temporary directory.
$ unpack_firmwarefd.sh bios.bin
$ vbutil_firmware --verify firmwareA.vblock --signpubkey KEY_DIR/firmware.vbpubk --fv firmwareA.data
[Verification should succeed]
$ gbb_utility -g bios.bin --rootkey=rootkey --recoverykey=recoverykey
"rootkey" should be the same as KEY_DIR/root_key.vbpubk
"recoverykey" should be the same as KEY_DIR/recovery_key.vbpubk
KEY_DIR: Directory containing the keys used to generate the output image.
Review URL: http://codereview.chromium.org/3083025
The script sign_official_build.sh does the appropriate signing depending on whether an ssd, recovery or factory-install image is desired.
Also re-factors some common functionality into common.sh.
BUG=3496
TEST=manual
I haven't had a chance to test this on an actual machine running our firmware but will do that before I actually check-in. Thoughts I'd atleast get this out to get the review going.
Review URL: http://codereview.chromium.org/3066034
