Fix assert() macro to only be defined #ifdef VBOOT_DEBUG
Change-Id: I4a65c408544cd4319628c4ad20ed46eafebe69c9
BUG=chrome-os-partner:1207
TEST=manual
Review URL: http://codereview.chromium.org/3446025
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
Change-Id: I2e798ac8898852aa44a8979e67dfa4de385a6e34
BUG=none
TEST=ran the autotest on a CRB with special firmware
Review URL: http://codereview.chromium.org/3389029
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
While trying to debug/test some vbutil_kernel changes
(coming in a different CL) it was noticed that this utility
is not covered by tests, and the script which runs it to set
up further testing (tests/gen_fuzz_test_cases.sh) fails
because of the key format mismatch.
Some investigation has shown that this was left behind when
vboot_reference key storage format was changed.
To make gen_fuzz_test_cases.sh work again a new set of test
keys is required, the keys are generated by
tests/gen_test_keys.sh. This utility had to be changed to
generate the proper set of wrapped public and private keys.
Actually code in tests/gen_test_keys.shgenerate_keys() is
copied in pasted in many scripts in this tree, this has to
be refactored, but under a different CL.
Once the changes were made, two scripts were run:
./tests/gen_test_keys.sh
./gen_test_cases.sh
resulting in the new and updated keys generated.
firmware/stub/tpm_lite_stub.c was edited to fix compilation
warning issued when compiling with debugging enabled.
Change-Id: I26a45cbad00d21a29195f2a89b4df7d3559133fe
BUG=chromium-os:7178
TEST=described below
The following commands succeed:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
make
make runtests
./tests/gen_fuzz_test_cases.sh
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note that ./tests/gen_fuzz_test_cases.sh was failing
before this change.
The upcoming CL modifying vbutil_kernel will make sure
gen_fuzz_test_cases.sh is executed when tests are run and
will enhance it to cover vbutil_kernel testing.
Review URL: http://codereview.chromium.org/3423022
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
Also change tpmc to return the TPM error code, or 255.
Change-Id: Ie5fc107ff50efd4480c2a47b91f3b8a93b4f95e3
BUG=none
TEST=ran it on a TPM
Review URL: http://codereview.chromium.org/3479003
Change-Id: Idb081dccdcba17005cd3edc059e58b78316c3dbe
BUG=none
TEST=ran the ebuild (separate CL) and verified that the targets are created
Review URL: http://codereview.chromium.org/3480004
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
Change-Id: I4c9b7a937103f3978cbed6629ee4057018b80eae
More cleanup. Also allow some tests to run even when TPM is already started.
Change-Id: I23558b96a1de55bbeca42dbf2e44f6802a0ec85b
Reorganize and standardize behavior of tests.
Change-Id: Id32fd09211a72deaa66a3dd0f973d35506ff96f2
BUG=433
TEST=ran all the tests I could run without TPM-free BIOS
Review URL: http://codereview.chromium.org/3389004
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
Change-Id: Id353323d268835cbcc1fb13c8669cee420c8fb6a
BUG=chrome-os-partner:1046
TEST=manual
Make sure your chromeos install on the hard drive has 2 good kernel
partitions. Do:
sudo cgpt show /dev/sda
If partition 2 has success=1, do:
sudo dd if=/dev/sda2 of=/dev/sda4 bs=1M
sudo dd if=/dev/sda3 of=/dev/sda5 bs=1M
cgpt add -i 4 -S 1 -P 2
(if instead partition 4 has success=1, do:)
sudo dd if=/dev/sda4 of=/dev/sda2 bs=1M
sudo dd if=/dev/sda5 of=/dev/sda3 bs=1M
cgpt add -i 2 -S 1 -P 2
Reboot and do the following:
sudo cgpt show /dev/sda
If the partition you just marked active still has success=1
priority=2, the bug is fixed. If it has success=0 priority=0, the bug
is still there.
Review URL: http://codereview.chromium.org/3324014
This adds some tools to help us figure out why a particular kernel isn't
booting. Often we suspect it's because it was signed with the wrong keys, or
has flags restricting its use to certain boot modes. This change adds some
tools to extract and display all the keys from the BIOS, and try them on the
various kernels. We also display the sha1sum of all the keys we find, to
make comparing them easier.
Change-Id: I38e447bf95cb6c3a0b87aa949611bb135f2f94b4
BUG=chromeos-partner:888
TEST=manual
To test, obtain a root shell, and run dev_debug_vboot. You should see lots
of useful information go by.
Review URL: http://codereview.chromium.org/3303018
Change-Id: I4785a6326017c63d83a8eb153d6b90ee82e5f839
BUG=chromeos-partner:222
TEST=manual (build FW, make sure system boots and tpmc prints good values)
Review URL: http://codereview.chromium.org/3367020
Change-Id: I26d7d725cb429394e24be40a2f362b7ff160f4ee
BUG=none
TEST=make && make runtests (and build into test BIOS)
Review URL: http://codereview.chromium.org/3337017
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
Update list of scripts and test binaries - slightly more involved since the test runner scripts and the test binaries themselves reside in different directories.
BUG=none
TEST=manual (Ran make, went into the tests/ directory and ran the tests)
Change-Id: I97bd36d806726f6005e35490173cfcd0300add95
Review URL: http://codereview.chromium.org/3326014
* The files it needs to build are here
Change-Id: I95973a9d96e7be6d7359a44b44337fdb9bfe0d92
BUG=
TEST=
Review URL: http://codereview.chromium.org/3335010
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
We now display the sha1sum of the public key contained in .vbpubk files,
and the --copyto option can be used to extract a minimal-sized .vbpubk or
.vbprivk from a file with extra padding on the end, to make comparisons
easier.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/3300006
Change-Id: Id465bf4f6f7d0545456a86968accc87964a769ef
This makes the sequence of pictures shown to the user slightly less
confusing, but the whole process needs a bit more cleanup. Some of the work
has to be done in the BIOS code, not just here. This is better, but it's not
complete.
Change-Id: If0b3ecc92716020a06031866849d83411d7f0db8
BUG=chrome-os-partner:903
TEST=manual
Review URL: http://codereview.chromium.org/3249009
BUG=2083
TEST=manual
Compiled with DISABLE_ROLLBACK unset. I need help testing this change - in particular, if the PCR 0 value is actually different in dev mode off vs. dev mode on. This can be done by invoking 'tpm_pcrread -p 0' at the shell. tpm_pcrread is part of the tpm_tools package.
Change-Id: I0728fb776a0c9cb90d885e7a1c76ff6a1a41a17b
Review URL: http://codereview.chromium.org/3195018
Add some extra cases to SanityCheckTest() to test both header and entries
being garbled at either end of the disk.
Add DuplicateUniqueGuidTest() to check that GPTs having duplicate
UniqueGuids in the entries are rejected. We can only check this per-disk, of
course.
Made some changes to the library to enforce the UniqueGuid requirement that
I just started testing for.
BUG=chromium-os:4854
Review URL: http://codereview.chromium.org/3135044
Change-Id: I86458faf9cc99aa3f29aac0d5b144dbd05067181
