This patch converts TEST_* functions to macros, which print file name
and line # of the check. This will allow us to locate a failed test
quickly.
New TEST_* macros also automatically generate a test name if
testname == NULL. This will save us time to think of a name for
every single check we write in a test.
BUG=none
BRANCH=tot
TEST=make runtests
Change-Id: Ibdeb99681985c3f348836d256fa3484f2f0c315f
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/343233
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch adds HMAC. HMAC will be used to sign/verify NVM structures.
Hash algorithms can be selected from those supported
by enum vb2_hash_algorithm (i.e. SHA1, SHA256, or SHA512).
BUG=chrome-os-partner:51907
BRANCH=tot
TEST=make runtests
Change-Id: I6d349bc807874fe2a5512aabcd7fbf67a4eaa40a
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/342880
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds RW firmware support for the optional firmware management
parameters TPM space.
System-level tests require CL:339262 to add cryptohome support.
BUG=chromium:601492
BRANCH=baytrail and newer platforms
TEST=make -j runtests
Or better, COV=1 make, and then make sure all new code is covered.
Change-Id: Ifaf644c80809552d5961615be6017c2a332a034b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/339234
vba_bdb_init initializes the vboot context and decides what to do next
based on the vboot register content. Possible actions are:
1. proceed to verify the current slot
2. reset to try the other slot
3. reset to recovery mode
bdb_sprw_test demonstrates these actions.
BUG=chrome-os-partner:51907
BRANCH=tot
TEST=make runtests
Change-Id: If72cdd575d09b9162a871f088064ca853b7fd74d
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/342604
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch replaces subkey with datakey to make name use consistent
with the design document.
BUG=chrome-os-partner:51908
BRANCH=tot
TEST=make runtests
Change-Id: I3690abd51e6c18c5a1094a8449f375d803c7e0b2
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/342199
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BDB has its own implementation of SHA256. This patch replaces it with
the one implemented in vb2 library.
BUG=chrome-os-partner:51908
BRANCH=tot
TEST=build runtests
Change-Id: Ida19dd49153a038fc2b2ce481cedf828818aaeaa
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/342121
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Now that we have support for the IGNOREME signature in cgpt, we need a
way to set it on an existing disk. The easiest option is to shoehorn
this into the cgpt legacy command, because that's already made to modify
GPT header signatures (really, it would be nice to rename it to cgpt
signature or something, but let's not break existing uses for now).
BRANCH=None
BUG=chrome-os-partner:52595
TEST=unit tests
Change-Id: If2835fec28a9c39373abd050e2e057f73e5ec700
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/340073
Reviewed-by: Nam Nguyen <namnguyen@google.com>
This patch makes cgpt aware of a special "IGNOREME" GPT header signature
string that may appear in either the primary or the secondary GPT and
cause cgpt (and other cgptlib clients) to completely ignore that GPT. It
will continue to function correctly for all other purposes (using the
data from the non-ignored GPT), but never write any data back to the
ignored GPT.
BRANCH=None
BUG=chrome-os-partner:52595
TEST=unit tests
Change-Id: I7e53542385ae9d8d24dc25b75e91f4ff4917f66f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/340072
Reviewed-by: Nam Nguyen <namnguyen@google.com>
For x86 systems, which resume through the boot reset vector, to
implement vboot verification of the memory init code one needs
check that the slot chosen on the resume path is the same as
the original boot path. That check is done by storing the
resulting hash of the slot. However, vb2api doesn't export
the resulting hash from vb2api_check_hash(). Thus, provide
a variant which saves the resulting digest in the supplied
buffer.
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Suspended and resumed on chell. Also, tested with an EC build
which returns a bad hash to ensure that is properly caught.
Change-Id: Ic20be2024afedabc2d8bc767f1b794376348523c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/323460
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Allow the AP to sync and verify the EC read only image after updating
the rewritable image.
BUG=chrome-os-partner:48703
BRANCH=none
TEST=manual
1. Update EC to a new version
2. rebuild EC code
3. Update AP firmware
4. Reboot and check that the RO image is updated after the RW image is
updated.
CQ-DEPEND=CL:319213
Change-Id: I774ef25320103f20d8c7d1c180a220dd0819c04d
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/320614
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This change will be used to support EC-RO software sync by allowing for
access to the readonly region of firmware. Currently only the writable
section is accessed by vboot using VB_SELECT_FIRMWARE_A and B.
BUG=chrome-os-partner:48703
BRANCH=none
TEST=built on jerry and check that the RO hash can be read and the image
can be updated.
CQ-DEPEND=CL:319185,CL:320425,CL:320598
Change-Id: Ic3942d86b65da3123798cfd11a78056f5dab6699
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/319213
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This flag will be used by the firmware updater to indicate that RO
software sync should be attempted.
BUG=chrome-os-partner:48703
BRANCH=None
TEST=make runtests
Change-Id: I42090ac47da45c724e66334648ab447ad3c21178
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/320621
Reviewed-by: Randall Spangler <rspangler@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>
FASTBOOT_FULL_CAP set
This change allows developers to boot dev-signed boot images in
unlocked mode if DEV_BOOT_FASTBOOT_FULL_CAP is set in VbNvStorage or
GBB_FLAG_FORCE_DEV_BOOT_FASTBOOT_FULL_CAP is set.
BUG=chrome-os-partner:47002
BRANCH=None
TEST=Compiles successfully. make -j runtests
Change-Id: I56e3879594da1b57051dfe242ff347ac970c96bb
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/309606
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
VbExGetLocalizationCount is a callback function which is supposed to
return the number of screen locales supported by VbExDisplayScreen.
After this change, we still try to get the number of locales from GBB
first but when it fails, VbExGetLocalizationCount is called. The error
code from VbGbbReadBmpHeader will be masked, similarly to the error from
VbDislayScreenFromGBB.
BUG=chromium:502066
BRANCH=tot
TEST=Tested on Samus. make runtests
Change-Id: I04ef8bf1ea02b1aaa05e65673b57bcea1932d8b0
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304376
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add support for PEM file containing a RSA Public key in futility "show"
and "create" commands.
When "futility create" is given a PEM file with only a RSA public key,
generate the proper .vbpubk2 rather than failing.
BRANCH=smaug
BUG=none
TEST=make runtests
and run manually
futility show tests/testkeys/key_rsa4096.pub.pem
futility show tests/testkeys/key_rsa4096.pem
Change-Id: I707ceca54c80ba21f53869ad86c86fa23b31e665
Reviewed-on: https://chromium-review.googlesource.com/306683
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Verify the size of the buffer read from the file before trying to use 1KB of
it for the new rwsig format detection.
Add a new test case with a short file containing only 4 bytes of unknown
data and run "futility show" on it.
BRANCH=smaug
BUG=none
TEST=futility show foobar.pub.pem
where foobar.pub.pem is a 451-byte file.
check that "make runtests" passes with the fix
and fails without it with the following message :
test_file_types.sh ... failed
FAIL: 13 / 14 passed
Change-Id: Ia9d68c6b528c2b3a595ea6791c907374616d051f
Reviewed-on: https://chromium-review.googlesource.com/306682
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This change makes VbDisplayScreen read the last saved locale from nvram
and pass it to VbExDisplayScreen so that it can draw locale dependent
screens.
BUG=chromium:502066
BRANCH=tot
TEST=Tested on Samus. make runtests.
CQ-DEPEND=CL:304382,CL:306100,CL:306110
Change-Id: I9782ec5a8a9f8393998aa8a0d64e88ad1809233b
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304375
This adds the "rwsig" type, with initial support for RO+RW
firmware images that need to verify themselves instead of using
software sync. This uses our vb2 structs instead of raw binary
blobs. That will help us locate, identify, and verify the keys
and signatures in the signed firmware images.
BUG=chrome-os-partner:46254
BRANCH=smaug,ToT
TEST=make runtests
I also hacked up a test board with the EC-side signature
verification routines from a preliminary CL and tested this
signing scheme with that. It works.
Additional work is needed to make this seamless, but you can try
it out like so:
futility create ./tests/testkeys/key_rsa2048.pem foo
futility sign --type rwsig --prikey foo.vbprik2 --pubkey foo.vbpubk2 ec.bin
Change-Id: I876ab312a2b0b36411c5f739fe3252529728d034
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305394
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In developer mode, this option will make the system try to boot into
a legacy OS first after the 30 second timeout. This removes the need to
press a key during boot to try legacy mode and the need to remove the
write protect screw to boot legacy as default.
BUG=chromium:310697
BRANCH=none
TEST=make runtests
Change-Id: I9a9f64c14ad015e21d08eec36e8fc187189cd2f2
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304077
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In the new recovery process, a user will see 'broken' screen
instead of 'remove' screen, where usb stick presence is no longer
detected. A user instead has to hit esc+refresh+power to proceed
to recovery mode.
BUG=chromium:501060
BRANCH=tot
TEST=make runtests
Change-Id: Icd511c1ca892628b96befbb0a34c2c84b881c857
Reviewed-on: https://chromium-review.googlesource.com/304404
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The firmware for the USB Type-C power adapters uses raw binary
blobs for the public keys and signatures instead of
readily-identifiable structs. We've been able to sign these
firmware images for some time, but verifying the result generally
required testing them on hardware.
This CL adds some futilty support for recognizing and verifying
those images too. It just tries various sig and hash algorithms,
until it finds a combination for which the image is
self-consistent (where the pubkey blob verifies the signature
blob).
BUG=none
BRANCH=none
TEST=make runtests
This change also adds additional tests for usbpd1 images. We
ensure that we correctly recognize and verify an MP-signed
firmware, plus test signing and verifying usbpd1 images using
multiple signature and hash algorithms.
Change-Id: I4fbe8b37a694992f635d5469ae1c2449b1610dfd
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302415
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In recovery mode, the TPM may be bad / corrupt. This prevents access to
the soft developer switch stored in secdata. But it should not prevent
setting dev mode via GBB or context flags. Those flags may be set
during manufacturing or testing, and override the contents of secdata
anyway.
BUG=chrome-os-partner:45511
BRANCH=ryu
TEST=make runtests
Change-Id: I242714528203cc7cf78a714c660b7f8bbd0e04d0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/300621
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
When a TPM goes from the disabled state to the enabled state, it must
reboot after being enabled, before it can be initialized. In vboot1,
TLCL was part of vboot and this was handled internally. In vboot2, the
caller must set a context flag, so that vboot can decide whether to
allow the reboot, or whether to go directly to recovery mode. This
check is necessary to handle the following cases:
1) The device is booting normally, but the TPM needs a reboot. This
should simply reboot, without going to recovery mode.
2) The device is booting in recovery mode, but the TPM needs a reboot.
If this is the first time it asked us, allow the reboot.
3) The TPM asked for a reboot last time, so we did. And it's still
asking. Don't reboot, because that runs the risk that whatever is wrong
won't be fixed next boot either, and we'll get stuck in a reboot loop
that will prevent recovery. Boot into recovery mode.
Add a new NvStorage bit to track whether the TPM requested a reboot on
the previous boot. That's better than what we did in vboot1, where we
used a special recovery request. Vboot1 couldn't track getting stuck in
a reboot loop in normal mode, only in recovery mode. The new code can
catch both.
BUG=chrome-os-partner:45462
BRANCH=ryu
TEST=make runtests
Change-Id: I2ee54af107275ccf64a6cb41132b7a0fc02bb983
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/300572
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Julius Werner <jwerner@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>
1. Change offset 8 to hold all misc settings (fastboot, boot_on_ac
detect) instead of only fastboot settings.
2. Add flag to hold state of boot_on_ac_detect (If set to 1, AP should
start booting as soon as AC is connected in off-state).
BUG=chrome-os-partner:41680
BRANCH=None
TEST=Compiles successfully. make runtests successful.
Change-Id: I64b3fc69bd52cbcaf5899c953ccafa2e81b5b8a5
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/289900
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
When one of GPT headers is invalid the corresponding partition table
is not loaded and corresponding pointers in GptData are NULL.
GptRepair will try to memcpy one entries table to another which
results in SIGSEGV.
This change fixes it by freeing and then reallocating bad copy of
partition table. This potentially fixes problems which would occur
if two tables have different size.
Change that initially introduced this problem by not always allocating
secondary_entries:
https://chromium-review.googlesource.com/223800
TEST="cgpt repair" works where it previously didn't
TEST=make runtests
BUG=brillo:1203
BRANCH=none
Change-Id: Ibb2fcf33faa5ba157b0865d04c90ee3f26eee113
Reviewed-on: https://chromium-review.googlesource.com/276766
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Andrey Ulanov <andreyu@google.com>
Tested-by: Andrey Ulanov <andreyu@google.com>
This allows the caller to load the kernel partition and then pass it
to vboot for verification, rather than having vboot assume the kernel
partitions are all on a block storage device.
Next up, APIs for the caller to parse partition information from a GPT
(yes, that's cgptlib, but we'll make it more easily callable by
depthcharge).
BUG=chromium:487699
BRANCH=none
TEST=make -j runtests
Change-Id: I388085c7023f4c76d416f37df0607019bea844ac
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/275646
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This can be used by implementations that want to request vboot to
favor a particular kernel entry for booting without affecting the
checks for rollback protection and image verification.
CQ-DEPEND=CL:274716, CL:274932, CL:275171
BUG=None
BRANCH=None
TEST=Compiles successfully. make -j runtests successful.
Change-Id: I6a4600020354f5d4118c17f083c353c2585c4181
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/274558
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Commit-Queue: Nicolas Boichat <drinkcat@chromium.org>
Trybot-Ready: Nicolas Boichat <drinkcat@chromium.org>
This patch reintroduces a vb2_secdata->struct_version check similar to
the one that was removed in CL:244846. The CRC is not a reliable way to
detect zeroed buffers, so this check helps vboot fail earlier and more
clearly in certain situations.
BRANCH=kitty,smaug,storm,veyron
BUG=chrome-os-partner:40778
TEST=make runtests. Rebooted Jerry with 'mem w 0xff7601b0 0xfdb9', saw
that recovery reason was now 0x2b (VBNV_RECOVERY_VB2_SECDATA_INIT).
Change-Id: Ic4376d127e6d14d4ef9c2f53c83090040ca4cb68
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/274138
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add support for functions to request unlock and lock of devices in
response to fastboot oem unlock/lock commands. Unlock operation is
equivalent to enabling dev mode and lock operation is equivalent to
leaving dev mode. It is the responsibility of the caller to ensure
that user confirmation is obtained before unlock/lock operations.
BUG=chrome-os-partner:40196
BRANCH=None
TEST=Compiles successfully and fastboot lock/unlock operations work as
expected on smaug. Added tests to ensure lock/unlock operations are
covered. Verified using make -j runtests.
Change-Id: Ibafe75abdd1202473009208a414f3996d537db4f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/273182
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
When the lid is closed and external power is applied
the system may boot and shut down faster than required
for the OS to determine that things were alright.
In timed charging setups this led to systems ending up
to consider the current version broken because it "failed"
repeatedly.
Remain generic about the reason for not counting boots
since there may be more situations in which we want to
handle the situation optimistically.
BRANCH=none
BUG=chromium:446945
TEST=none
Change-Id: Iea350e3c98d5c00156da682e52c90a882ba017c0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249150
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This API allows fastboot boot from memory command to verify that the
image loaded in memory is signed properly using recovery keys. Thus,
only officially signed recovery images can be booted using fastboot
boot command in recovery mode.
However, if GBB_FLAG_FORCE_DEV_BOOT_FASTBOOT_FULL_CAP is set, then
this routine will not perform any check and return okay for any image
sent by fastboot boot.
BUG=chrome-os-partner:40196
BRANCH=None
TEST=Compiles successfully. With GBB override for FASTBOOT_FULL_CAP
set any signed image is allowed to boot. With FASTBOOT_FULL_CAP not
set, then only officially signed image is allowed to boot. (make -j
runtests successful)
Change-Id: I78028853bd1ad09d3c610a687f327560557d5681
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/272696
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
These are slightly more complex than the firmware versions, because
they need to deal with developer-signed keyblocks and keyblock flags.
BUG=chromium:487699
BRANCH=none
TEST=make -j runtests
Change-Id: I682c14ddfe729984f2629dfbe66750e5cd5ab75e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/272541
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This is necessary for the next change, which adds keyblock hash checking.
Also clean up some other assorted comments, and move the diagnostic
check of root key to see if it's the checked-in one earlier in
firmware preamble validation so it's closer to where the root key is
loaded.
No functional or higher-level API changes; just shuffling around code
under the covers.
BUG=chromium:487699
BRANCH=none
TEST=make -j runtests
Change-Id: Ibc3960a4d882dc2ad8684e235db4b9d066eac080
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/272223
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This also checks that the bootloader and vmlinuz headers, if present,
are within the signed part of the kernel blob; the vboot1 routines
didn't do that. That wasn't harmful at firmware boot time because the
vboot1 routines would only load as much data as was signed, but in
vboot2 loading the kernel data is the responsibility of the caller so
we need to check.
BUG=chromium:487699
BRANCH=none
TEST=make -j runtests
Change-Id: I73eb4831e5d3d7a642b6cb85cb55857d87fcc0af
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270797
Add a new flag to nvstorage for controlling fastboot capabilities
offered in firmware in dev-mode. By default, value of this flag would
be ignored in normal mode. Thus, when fastboot-based recovery is
entered from normal mode, only limited capability would be available
in firmware.
After switching to dev-mode, this flag can be set automatically by
user script after performing the wipe or it can be set manually using
crossystem. When fastboot-based recovery is entered from dev mode and
this flag is set, it will provide full fastboot capability in the
firmware.
BUG=chrome-os-partner:40196
BRANCH=None
TEST=Compiles successfully for smaug. make runalltests successful.
Change-Id: I761a9ab304dd90f0b73081acc9ce1f8d9052325f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/271369
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Looks like the DISABLE_FW_ROLLBACK_CHECK GBB flag (0x200) was forgotten
in the vboot2 implementation. It's too late for Veyron now, but let's at
least fix it for future devices.
BRANCH=none
BUG=None
TEST=make runtests
Change-Id: I867f7aada28be3897efda73a6bdc3b0848c23dca
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/271419
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
