BUG=chrome-os-partner:2316
TEST=tried signing firmware with old style and new style fmap and verified that it works.
Change-Id: I9076fe60308bdb787440486d592c9d5e72602199
Review URL: http://codereview.chromium.org/6516004
Versions are (optionally) read from a file with the format
firmware_version=<firmware version>
kernel_version=<kernel version>
The new scripts and arguments are compatible with older versions of the script.
Change-Id: I502df69d6c02caee75cdf010e61812be408a64e0
BUG=chromium-os:8016
TEST=manually tested all invocations of sign_official_build {verify|usb|ssd|install|recovery} with and without versions.
Review URL: http://codereview.chromium.org/6368064
Change-Id: Ib8061ba35afd9681dc70fe1a1459ff9a00f74c3f
BUG=chrome-os-partner:2181
TEST=./ensure_sane_lsb-release.sh chromiumos_base_image.bin (passes)
Also tested each of the "test fail" possibilities:
* Tested by changing various values in the .config file to force each mismatch/failure
* Tested lsb_syntaxcheck by isolating it and having it check a mock bad lsb-release file
containing each of the possible syntax violations.
Review URL: http://codereview.chromium.org/6246037
Change-Id: Iad5578031e4d62435a27c92651b1c91075987078
BUG=chrome-os-partner:1991
TEST=Ran manually against current mario images, 'base' img passes, 'test' fails, as expected
Review URL: http://codereview.chromium.org/6264023
Also make the script able to run at other directory.
BUG=chromium-os:11384
TEST=as follow:
$ cd /tmp
$ ~/$CHROMEOS/src/platform/vboot_reference/scripts/bitmaps/make_bmp_images.sh 'x86 HWID 1234' '1366x768' true
processing BlankBmp ...
processing DeveloperBmp ...
processing RecoveryBmp ...
processing RecoveryMissingOSBmp ...
processing RecoveryNoOSBmp ...
$ file out_x86_HWID_1234/DeveloperBmp/DeveloperBmp.bmp
out_x86_HWID_1234/DeveloperBmp/DeveloperBmp.bmp: PC bitmap, Windows 3.x format, 800 x 600 x 24
$ ~/$CHROMEOS/src/platform/vboot_reference/scripts/bitmaps/make_bmp_images.sh 'arm HWID 1234' '1366x768' false
processing BlankBmp ...
processing DeveloperBmp ...
processing RecoveryBmp ...
processing RecoveryMissingOSBmp ...
processing RecoveryNoOSBmp ...
$ file out_arm_HWID_1234/DeveloperBmp/DeveloperBmp.bmp out_arm_HWID_1234/DeveloperBmp/DeveloperBmp.bmp: PC bitmap, Windows 3.x format, 1366 x 768 x 8
Change-Id: Ia96a4e64f34350f8bd5fec51657d3cec85c4ab1c
Review URL: http://codereview.chromium.org/6273012
Change-Id: I8ffedf8afa00862d135f80db9350927cc0332979
BUG=chrome-os-partner:1991
TEST=Have run it manually with various config data producing test-pass and the different sources of test-fails
Review URL: http://codereview.chromium.org/6253014
Revert "This change define the data structure of bmp block and implements the create more of bmpblk_utility. It reads a YAML config file, parse the informations, and creates bmpblock file as output."
This reverts commit 95b0ae01ea.
BUG=none
TEST=emerge-x86 vboot_reference
TBR=waihong@chromium.org
Change-Id: If1692ca12ddb61b7814ca7dddccee5a395c8bed1
The list mode and extract mode will be implemented later.
Change-Id: I2b34b323814b1d6b0a369b0e4b2bfa7cf960ff4a
BUG=chromium-os:11017
TEST=build and run, use bvi to check its output.
Review URL: http://codereview.chromium.org/6307007
The current version always fails - and generates false positives. (This is not
the version that is on the live signer, so we are good.)
Change-Id: I7cb14cdcaf4d96bc2911e596224ead9a3738aa18
BUG=chromium-os:1459
TEST=manually tested
Review URL: http://codereview.chromium.org/6322006
Change-Id: I044331dc3558a4f7428b75fe43ef739498d65803
BUG=chromium-os:10836
TEST=scripts that use common.sh seem to work, would appreciate help in testing Chrome OS client scripts!
Review URL: http://codereview.chromium.org/6294002
Complete the missing part of "checking (and disabling) write protection status.
This also helps to prevent erasing RW regions on system with WP enabled and
then causing boot failure.
BUG=chrome-os-partner:1276
TEST=(1) On CR-48 with WP enabled, run make_dev_firmware.sh without turning off WP.
Result: Error message "Write protection is still enabled. Please verify
that hardware write protection is disabled." (as expected)
(2) Disable WP and run again.
Result: firmware has been changed successfully.
Change-Id: Iaf2243cb2cd3c7f83ce4f36543ea3da1e3ca55a1
Review URL: http://codereview.chromium.org/5987010
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
BUG=chromium-os:10213
TEST=manual
From a shell, run
cd /tmp
/usr/share/vboot/bin/make_dev_ssd.sh --save_config foo
You should see messages about kernel A, kernel B, and kernel C. It doesn't
matter what those messages are (well, it does, but testing that is way too
complicated and only useful for dev-mode hacking).
Change-Id: I32aaeae18fb9dd957ab17a452d1ea6d7cd8fe788
Review URL: http://codereview.chromium.org/5698004
Change-Id: I691e6e62f5d5d9b6671fd05f172829b84d503b77
BUG=9934
TEST=manual
1. From a root shell, on a device signed with developer keys:
make_dev_ssd.sh --save_config=foo
This should create a foo.2 file with a kernel command line. It'll be
similar to the one in /proc/cmdline. It may create a foo.4 file, if
kernel B is also valid.
2. Modify the command line in foo.2 (and foo.4, if it exists).
Suggest adding "blah2" to foo.2, and "blah4" to foo.4 if it
exists.
3. From a root shell:
make_dev_ssd.sh --set_config=foo
4. Reboot.
5. Check the kernel command line.
cat /proc/cmdline
If you booted from kernel A, you should see "blah2" in the command
line. If B, you should see "blah4".
Review URL: http://codereview.chromium.org/5567003
BUG=chromium-os:9578
TEST=manually tested before and after the change (echo $? after running verify on an image)
Change-Id: I7d7e36b63482ef3a447cf07b09abdc6fb37b22c1
Review URL: http://codereview.chromium.org/5273010
This mirrors the change made for cros_make_image_bootable.
BUG=chromium-os:9578
TEST=manually ran verify on signed images including those with known rootfs corruptions.
Change-Id: I5dfdf1bfa975fbbbb4e010cd2adc6a3a7f08da15
Review URL: http://codereview.chromium.org/5367004
The remove_rootfs_verification was corrupted by several issues:
1. enable_rw_mount (ext2 RO bit hack) should be performed on every rootfs
and only after we successfully resigned the kernel.
2. for latest images, we must first resign again before changing
boot parameter, otherwise verification would fail.
Both fixed and verified.
BUG=chromium-os:8629
TEST=(1)built a ToT image, install by USB boot, then
./make_dev_ssd --remove_rootfs_verification; then reboot.
rootdev shows /dev/sda3 and is writable.
(2)install by factory setup and then wipe so that root = sda5
./make_dev_ssd --remove_rootfs_verification; then reboot.
rootdev shows /dev/sda5 and is writable.
Change-Id: I27d92964f3fbe160a207069a39516a879de64245
Review URL: http://codereview.chromium.org/4525002
Earlier we used to reuse the recovery kernel data key in the installer, however now we make them different, and so installer keyblock nolonger corresponds to the recovery kernel data key. This CL fixes that.
BUG=7202
TEST=manually tested by using the new key generation scripts, and verifying that the old install signing no longer worked. Making the fix again makes the image verify only in dev mode.
Change-Id: Ic83e90397132da9f88b36e69198773350eb3691f
Review URL: http://codereview.chromium.org/4527004
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
BUG=chromium-os:8686
TEST=manual
Follow all the steps to validate
http://code.google.com/p/chromium-os/issues/detail?id=8679
While booted from the USB image, open a shell and run (as chronos)
/usr/sbin/chromeos-install
Reboot, and the device should boot the image installed from the USB.
Change-Id: Iedd595de8dbafabb3e9c8b638cb7e75eea02f165
Review URL: http://codereview.chromium.org/4457001
We still need a way to re-sign non-installer images so that they can be
booted directly from USB.
BUG=chromium-os:8679
TEST=manual, from within the build chroot
Obtain a chromiumos_base_image from buildbot or your own build. Ensure that
it's signed with the dev-keys (it should be).
Modify it somehow. For example:
(cros-chroot)$ cd src/platform/vboot_reference/scripts/image_signing
(cros-chroot)$ ./set_chronos_password.sh chromiumos_base_image.bin mypassword
Now resign the image:
(cros-chroot)$ cd src/platform/vboot_reference/scripts/image_signing
(cros-chroot)$ ./sign_official_build.sh usb chromiumos_base_image.bin \
/usr/share/vboot/devkeys usb_image.bin
Then copy the usb_image to a USB stick:
sudo dd if=usb_image of=/dev/WHATEVER
The resulting USB stick should boot in recovery mode, and assuming you
changed the password as shown above, should let you use that password to get
a shell.
Change-Id: I3aaa2b8787c52940249fd15007e075de7e017d78
Review URL: http://codereview.chromium.org/4424003
BUG=chrome-os-partner:1573
TEST=Manually tested with the latest signed release build. Recovery installer successfully completed and installed the image on the SSD.
Change-Id: I92706e957a1d339db516600ef0d86141d914b0d2
Review URL: http://codereview.chromium.org/4262004
This CL modifies the bitmap generation script as follows:
- allow to specify required geometry of the images and to
generate a single set per FWID instead of generating all
geometries for all FWIDs
- store the images and the zip archive in a directory with
the name derived from FWID.
The CL also adds a wrapper, which given the path to the tree
containing already released GBB firmware volumes would find
all valid (as verified by the CRC in the file name) FWIDs
and generate new images for all detected FWIDs.
The geometry of the generated images is based on the FWID
contents, Marios get 1280x800 and ZGAs - 1366x768.
Once this script stops running, the scripts/bitmaps
directory contains a set of subdirectories, one per
generated set of images.
Another script ran by cygwin on a windows machine was used
to pick up all image sets and regenerate GBB firmware
volumes, will be published under a separate CL.
BUG=chrome-os-partner:792
TEST=see below:
Ran the following command:
./process_all_targets.sh ../../../chromeos-internal/third_party/autotest/files/client/site_tests/
After command completed, the following out_* directories showed up:
(bitmaps 144) ls -1d out*
out_ACER_ASPIREONE_001_8012/
out_ACER_ASPIREONE_001_DEV_0393/
out_ACER_ASPIREONE_002_0710/
out_ACER_ASPIREONE_002_DEV_1017/
out_IEC_MARIO_FISH_2330/
out_IEC_MARIO_PONY_6101/
out_IEC_MARIO_PONY_DEV_3342/
out_IEC_MARIO_PONY_DVT_8784/
out_IEC_MARIO_PONY_EVT_3495/
out_IEC_MARIO_PONY_PREDVT_6766/
with typical directory contents as follows:
(bitmaps 145) tree out_ACER_ASPIREONE_001_8012/
out_ACER_ASPIREONE_001_8012/
|-- 1366x768.zip
|-- BlankBmp
| `-- BlankBmp.bmp
|-- DeveloperBmp
| `-- DeveloperBmp.bmp
|-- RecoveryBmp
| `-- RecoveryBmp.bmp
|-- RecoveryMissingOSBmp
| `-- RecoveryMissingOSBmp.bmp
`-- RecoveryNoOSBmp
`-- RecoveryNoOSBmp.bmp
5 directories, 6 files
Review URL: http://codereview.chromium.org/4147008
Change-Id: I4620966554ca26ea91b01e65fd441c9c09db2a83
BUG=chrome-os-parter:792
TEST=none
As with every previous change to the BIOS bitmaps, you'll have to
1) get a new factory-install shim with the bitmaps embedded
2) run the factory-install shim to change the screens on the device
3) boot in developer and/or recovery mode to see the screens
There is no direct test for this particular bug alone.
Review URL: http://codereview.chromium.org/4158003
The rootfs offset was not converted to bytes. This changes fixes that.
BUG=none
TEST=ran it on an image and it found the ext2 magic
Change-Id: I814c3b89bf5246e3ceab851f80c4a4d4d7e63919
Review URL: http://codereview.chromium.org/4071002
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
Provide more clear instruction on how to use the backup files,
and to try more effort to store backup files
BUG=none
TEST=emerge-x86-generic vboot-reference; executed make_dev_firmware and got correct message
Change-Id: I2062f45dd3019d0e56adc18bdd1861991aafe5ed
Review URL: http://codereview.chromium.org/3785014
Found a trailing space in souce comments, remove it for coding style (and to
force ebuild version bump)
BUG=none
TEST=none
Change-Id: Ie7cb295085b73fe9e274a89e5b4ee5eda9aae66f
Review URL: http://codereview.chromium.org/3799006
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
To extend the usage of tag_image, added --forget_usernames and --leave_core.
Output is also refined to clarify the category of each tag parameters.
BUG=none
TEST=./tag_image.sh --from $PATH_TO_IMAGE; leave_core seems working fine.
Change-Id: I7c6517bc98af260411518c743093ade3124b76b9
Review URL: http://codereview.chromium.org/3796003
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
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
