Also add an option to prevent sign_official_build from attempting to re-sign the firmware.
This is needed because we want both the SSD and RECOVERY images to have the same rootfs for delta updates to work correctly.
BUG=chromium-os:7242
TEST=manually verified that rootfs gets replaced correctly (by verifying the rootfs hash).
Change-Id: I2ca4f2bef938ca14301fed6a0b16c1a7dc2ba6d9
Review URL: http://codereview.chromium.org/3529007
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
BUG=chromium-os:7071
TEST=none (will be tested when BIOS is updated)
Change-Id: I7e765175b23dc08adb260a41abf81ba4b999eb34
Review URL: http://codereview.chromium.org/3443030
BUG=chrome-os-partner:1097
TEST=manual + independently verified by drewry@
1) Extract rootfs from the original image.
2) run tune2fs -l <original rootfs> on it. Observe filesystem features has no "needs_recovery"
3) run sign_official_build.sh
4) Extract new rootfs
6) run tune2fs -l <new rootfs>. "needs_recovery" should still not be there (it was before this fix)
Change-Id: I3a03245886844d3dbfe1f8b2b73ce624ec67808f
Review URL: http://codereview.chromium.org/3436010
The fmap_decode tool from flashmap project is deprecated.
mosys provides more functionality and fit better into the
host environment.
BUG=chromium-os:6264
TEST=manually
Change-Id: I513d36c8a8f657fdb4cb10d08a867876c32d36b6
Review URL: http://codereview.chromium.org/3388002
Previously this was hidden behind an environment variable. With this change, the signing script will always try to sign the firmware update if found. If not, it will still perform the remaining steps (rootfs calculation, kernel partition signature etc.).
Also fixed a few minor bugs with the firmware update code.
BUG=chrome-os-partner:925, chrome-os:3496
TEST=created a ToT semi-official build, and ran the signing script on the image. Verified that the firmware got correctly updated (by running chromeos-firmwareupdate on the device). Also tested on images without the packaged firmware update.
Change-Id: I0921ce36a880e18167a8e3a2b63d8f246693d488
Review URL: http://codereview.chromium.org/3292016
Looks like dumpe2fs is not in the path otherwise. Also added a check to look for it as a pre-requisite.
BUG=none
TEST=none
Change-Id: I329c894597bc1638043a67359465e55b2ce6d0f7
Review URL: http://codereview.chromium.org/3355013
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 exact firmware packaging is still very much in flux, not to mention current images don't have the firmware autoupdate package.
BUG=none
TEST=none
Change-Id: Idc60c2c9a8fbc83e0c786b4d4f96f371cdb4a49f
Review URL: http://codereview.chromium.org/3151027
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
Also, update the usage with examples.
BUG=5581
TEST=tested with "quoted arguments with spaces"
Change-Id: I4d3db4f9d4bf254069f08e8154d650d6ce4551f0
Review URL: http://codereview.chromium.org/3164010
Also, rename the script to reflect its specific purpose.
BUG=5580
TEST=ran on an image, installed and tested with new password
Review URL: http://codereview.chromium.org/3175003
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
Forgot to propagate the use of area_offset= pattern for ouput parsing to the unpacking script.
BUG=none
TEST=Tested by running on a firmware image with flashmap enabled. Correctly parsed the section offsets and sizes and output them to files.
Review URL: http://codereview.chromium.org/3050019
Also add a script for splitting a firmware image into component firmware data, vblocks and the GBB.
Note: The script uses fmap_decode, a utility to parse flashmap of a firmware image, and a part of the flashmap project:
http://code.google.com/p/flashmap/
BUG=3496
TEST=Tested with newer builds of firmware images with flashmaps enabled. Steps to verify:
1) Use script to re-sign an existing image with a new set of keys.
2) Use unpack_firmwarefd.sh to get individual firmware data and vblocks.
3) Use vbutil_firmware with the new keys. Verification should succeed with
the newer keys but fail with the older ones.
Review URL: http://codereview.chromium.org/3026018
For use on our signing servers. May merge this with other scripts once we drill down the right workflow.
BUG=3496
TEST=Just a wrapper around vbutil_kernel and works as intended.
Review URL: http://codereview.chromium.org/3020023
Also created a new directory in the vboot_reference source where all signing scripts and related miscellanea will go.
Review URL: http://codereview.chromium.org/2925011
Refactor and restructure reference code into individual self-contain modules. I have revamped the way the code is structured to make it easy to determine which parts belong in the firmware and which are used by userland tools.
common/ - common utilities and stub functions (Firmware)
cryptolib/ - crypto library (Firmware)
misclibs/ - miscellaneous userland libraries (Userland)
sctips/ - Miscellaenous scripts (Userland)
tests/ - Tests (Userland)
vfirmware/ - Verified Firmware Implementation
vfirmware/firmware_image_fw.c (Firmware)
vfirmware/firmware_image.c (Userland)
vkernel/ - Verified Kernel Implementation
vkernel/kernel_image_fw.c (Firmware)
vkernel/kernel_image.c (Userland)
Review URL: http://codereview.chromium.org/1581005
