Kernel verification will now roll forward the minimum allowable
version in the TPM no farther than the kernel_max_rollforward setting.
Note that CL:765573 changes chromeos-setgoodkernel so it always sets
kernel_max_rollforward to 0xfffffffe when marking a kernel as good.
That ensures that firmware with this setting will behave the same for
now as existing firmware.
BUG=chromium:783997
BRANCH=none
CQ-DEPEND=CL:765573
TEST=make runtests
Manual testing:
crossystem tpm_kernvel --> print current kernel version in TPM
- Resign the kernel with a higher version
- Reboot
- Wait a minute for chromeos-setgoodkernel to run
crossystem kernel_max_rollforward=0
- Reboot
crossystem tpm_kernvel --> has not changed
- Wait a minute for chromeos-setgoodkernel to run
crossystem kernel_max_rollforward -> 0xfffffffe
- Reboot
crossystem tpm_kernvel --> has changed to the higher version
Change-Id: Ia32ecb7fa4078548cd311541ccbe120570cf1bc5
Reviewed-on: https://chromium-review.googlesource.com/765574
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
This just adds the kernel_max_rollforward field to the nvstorage
libraries and crossystem. The firmware does not use it yet; that's
coming in a subsequent CL.
16 of the fields's 32 bits are taken from unused bytes of the kernel
field. This has no effect on existing usage.
BUG=chromium:783997
BRANCH=none
TEST=make runtests
Also manual testing. In a root shell:
crossystem kernel_max_rollforward --> Should default to 0
crossystem kernel_max_rollforward=0xfffffffe
crossystem kernel_max_rollforward --> Should be 0xfffffffe
(Note that setting it to 0xffffffff is indistinguishable from the
-1 value that the crossystem library uses to indicate error, so
0xffffffff isn't actually usable as a max rollforward limit. But
0xfffffffe is, and if we ever get so close to the limit that we
need to use 0xffffffff, something has already gone horribly wrong
with our versioning strategy...)
Change-Id: I008f412e6ed3c0b59beb9881268585af69d1ff2e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/765572
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch makes sign_official_build.sh resign ec.bin and store
signed RW copies in bios.bin if the original ec.bin contains
signed RW copies.
BUG=b:66956286
BRANCH=none
CQ-DEPEND=CL:738794,CL:*490792
TEST=sign_official_build.sh recovery recovery_image.bin \
~/trunk/src/platform/vboot_reference/tests/devkeys /tmp/out.bin
Change-Id: I73c7d8da7d8e2f770e5952d0124f8d43bb13e592
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/734295
CL:693008 changed check_ac_active so that we ask CR50 to verify EC
is in RO. While this is the right decision, on some platforms ECs
can't reset EC_IN_RW. This causes check_ec_active to set IN_RW
wrongly when EC is in RO after reboot.
This patch replaces VbExTrustEC with VbExEcRunningRW. If RW is
owned it may say it's in RO. Then, the software sync will proceed
and flash RW while the EC is running RW copy.
It also removes redundant checks for VbExTrustEC() when deciding
whether to allow developer mode to be enabled from the INSERT
screen. The INSERT screen can only be reached by manual recovery,
which resets the EC, we don't need to check again before going to
TODEV.
BUG=b:67976359
BRANCH=none
TEST=make runtests
Change-Id: Ide722146ca8683411dd9072a39387aa9531f6cfc
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/740878
Depthcharge currently asks EC whether recovery was requested manually
or not without verifying EC is in RO or not. If EC-RW is compromised,
recovery switch state can be spoofed.
This patch makes Depthcharge check EC_IN_RW to determine whether EC
is in RO or not. Only if it's in RO and it says recovery button was
pressed at boot, we proceed to the recovery process.
All other recovery requests including manual recovery requested by a
(compromised) host will end up with 'broken' screen.
BUG=b:66516882
BRANCH=none
TEST=Boot Fizz. make runtests.
Change-Id: I01d2df05fe22e79bbc949f5cb83db605147667b3
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/693008
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This change makes futility write out a EC_RW image to the filesystem.
It also allows the command to run without '--prikey' option. When a
private key isn't provided, the command copies the previous signature.
This can be used to extract EC_RW without changing the key or the
signature. Since data only mode doesn't have a previous signature,
the command returns error if '--prikey' isn't specified (as done
before).
BUG=b:65027647
BRANCH=none
TEST=Run futility as follows
futility sign --type rwsig ec.RW.flat ec.RW.sig (Missing key error, expected)
futility sign --type rwsig ec.bin (EC_RW.bin is produced)
futility sign --type rwsig EC_RW.bin
futility sign --type rwsig --prikey key.vbprik2 ec.RW.flat ec.RW.sig
futility sign --type rwsig --prikey key.vbprik2 ec.bin (EC_RW.bin is produced)
futility sign --type rwsig --prikey key.vbprik2 EC_RW.bin
make runfutiltests
Change-Id: I8c1e0cef147967cfd6d28aa7272b88c03e109e0d
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/647804
Reviewed-by: Randall Spangler <rspangler@chromium.org>
vb2_public_key_read_keyb cannot be used for VB2.1 public keys
(especially not for 2048 exponent 3 or F4, as their size is the
same so the algorithm cannot be guess).
Instead, do what futility/rwsig does and derive the public key from
the private RSA key.
BRANCH=none
BUG=b:64854892
TEST=make runlongtests
Change-Id: Ie81f40e6076cd0c234012b9af58e39425f8b717c
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/628177
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Caveh Jalali <caveh@google.com>
Add tpm_lite library support for the IFX specific TPM_FieldUpgrade
subcommand "FieldUpgradeInfoRequest2". Expose this via tpmc so it can
be used from shell scripts.
BRANCH=none
BUG=chromium:728130
TEST=Builds and tpmc ifxfieldupgradeinfo prints plausible results.
Change-Id: Ie58ebccef7fe90f7fca65d7cd9c78e1f16f9f29a
Reviewed-on: https://chromium-review.googlesource.com/562772
Commit-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
call VbExUpdateAuxFw() uncontidionally, instead of when we know we
need to do an update. Vb*AuxFw() already maintains state, so this
doesn't change when we (attempt) to update firmware.
however, this does allow us to iterate over all firmware drivers to
call their .protect() method. previously, we would only call
.protect() after an actual firmware update.
updated unit tests to match the new logic.
BRANCH=none
BUG=b:35585700
TEST=verified i2c tunnels are protected on reef using
ectool i2cprotect N status.
Change-Id: I9244db28ed181f568d117092307293202257735b
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/620281
Reviewed-by: Julius Werner <jwerner@chromium.org>
For detachables, the short delay is to fast to them to read/choose
options. Setting timeout to 30 seconds once user starts scrolling
through the menu. If no action is taken by the user, will retain
the short delay timeout.
BUG=b:63056097, b:35585623
BRANCH=None
TEST=reboot with gbb flag bit 1 enabled and ensure using short delay.
reboot and press volume button and make sure using long delay.
reboot and make sure short delay performed again upon reboot.
reboot and make sure gbb flag bit 1 = 0 and make sure long delay
still working as expected.
Change-Id: I31e3ca8aff6b29abca70ca9587deae7f6443d837
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/563817
Reviewed-by: Randall Spangler <rspangler@chromium.org>
this adds calls to depthcharge (using callbacks) to do auxiliary
firmware updates. in particular, this is intended to trigger TCPC
updates, but other programmables could also be updated.
no firmware updates take place until a board file has actually
registered a firmware update "driver". board file updates to follow.
TEST="COV=1 make" passes.
depthcharge boots on snappy.
with additional follow-on CLs, we can update the ps8751.
the companion depthcharge changes are here:
https://chromium-review.googlesource.com/c/498150/
the working design doc is here:
https://docs.google.com/a/google.com/document/d/1uzS0b3O3Us1QI2Sx7LDkjEfHmuhYB2BolrAoNwCVoc0/edit?usp=sharing
these features depend on vboot API updates:
CQ-DEPEND=CL:498150
BUG=b:35586896
BRANCH=none
Change-Id: If0d634eab08b429a8e7e80f5fe11eab3705bba0f
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/505260
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Replace commands using gbb_utility by the new 'gbb' futility command.
BRANCH=none
BUG=None
TEST=USE=test emerge-$BOARD vboot_reference
Change-Id: I8c1547d295a955373413482509a33964b0e0c06f
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/538442
Reviewed-by: Stefan Reinauer <reinauer@google.com>
This also adds the required tests (keys, testcases), and some
additional tests in vb2_rsa_utility_tests.c that were not
added when 2048-bit exponent 3 support was added.
BRANCH=none
BUG=chromium:684354
TEST=make runtests
Change-Id: I56d22302c2254ef500b9d2d290a79d8c8bc39942
Reviewed-on: https://chromium-review.googlesource.com/449060
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If an FMAP is detected in the rwsig image file, use it
to determine the location of:
- RW region
- RW signature
- public key in RO region
futility show uses that information to verify the signature,
and futility sign uses it is correctly resign the image,
and replace the public key a well.
This also adds tests for this use case. hammer_dev.bin sample
image uses huge RO public key and RW signature regions to make
sure all keys up to RSA-8192 can be used.
BRANCH=none
BUG=chrome-os-partner:62321
TEST=make -j
TEST=./build/futility/futility --debug show \
--pubkey hammer.vbpubk2 hammer.bin
TEST=./build/futility/futility --debug show hammer.bin
TEST=cp hammer.bin hammer.bin.orig
./build/futility/futility --debug sign \
--prikey hammer.vbprik2 hammer.bin
diff hammer.bin hammer.bin.orig => identical
TEST=openssl genrsa -3 -out hammer2.pem 2048
futility create --desc="Hammer 2nd key" hammer2.pem \
hammer2
./build/futility/futility --debug sign \
--version 2 --prikey hammer2.vbprik2 hammer.bin
These 2 commands succeed, but show different keys:
./build/futility/futility --debug show hammer.bin
./build/futility/futility --debug show hammer.bin.orig
TEST=make runtests
Change-Id: I2cebc421eaf97d1b92c9a58afc238d41487d0f6d
Reviewed-on: https://chromium-review.googlesource.com/445536
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This tests that futility can correctly create and verify rwsig images.
Note that we do not test RSA 8192, as the signature is longer than
1024 bytes, and the test logic would need to be changed.
BRANCH=none
BUG=chromium:684354
TEST=make runfutiltests
Change-Id: I690e59fe8fa3e273dd81176211c58e1677fa720f
Reviewed-on: https://chromium-review.googlesource.com/438950
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This calls gen_test_cases.sh in the proper environment.
Also, prevent gen_test_cases.sh from overriding test_file, to
provide stable signature (and avoid large git diff for no reason).
BRANCH=none
BUG=chromium:684354
TEST=make gentestcases -j8; git diff => no changes
Change-Id: I556285fd1a07a4d84f4ebd3fd7881ae06743716e
Reviewed-on: https://chromium-review.googlesource.com/439064
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The original VBDEBUG macro used doubly-nested parens to work with
MSVC, which didn't support varargs in macros. We now only use more
modern compilers, so replace it with the VB2_DEBUG macro and get rid
of the ugly and fragile double parens.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; build_packages --board=reef chromeos-firmware
Change-Id: Ifc0cb0733b14daaa1fde095fab7da4215a538c77
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/425133
Reviewed-by: Shelley Chen <shchen@chromium.org>
This cleans up the vboot functions which handle display so they don't
need to pass it around. Eventually, it'll be absorbed by vb2_context.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; build_packages --board=reef chromeos-firmware; boot reef
Change-Id: I58169dfd37abe657f9b9aa339cc72ffa398329e0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414288
Reviewed-by: Shelley Chen <shchen@chromium.org>
Previously, the EC software sync process called VbDisplayScreen() from
several function calls deep. Refactor software sync so that the UI
decisions are at a higher level (in ec_sync_all.c) and isolated from
the low-level EC software sync functionality (in ec_sync.c).
This is one in a series of changes which are more clearly separating
out the UI, to make it easier to support multiple UI across a range of
devices.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; build_packages --board=reef chromeos-firmware; boot reef
Change-Id: I40597abeb5b0cc8f5d8fc2098e4acbed4bf59bf6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/411921
Reviewed-by: Shelley Chen <shchen@chromium.org>
Passing the vb2 context around allows using more of the vb2 functions in
future changes, and prepares for a future where we directly use the
context as it was set up in firmware verification.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I8efa606dbdec5d195b66eb899e76fdc84337ad36
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404997
Reviewed-by: Shelley Chen <shchen@chromium.org>
This was previously done inside vboot_api_kernel. But it has nothing to
do with kernel verification; that's just the only place where we could
easily put it given that vboot (currently) owns the firmware UI.
No outwardly-visible functionality changes.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I8a434eb4449a5a86b129ecac61ad81d0ad55549c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404920
Now that LoadKernel() uses a stream API for its partition data, it
doesn't care about those fields. They're blindly passed to
cgptlib_internal, which does similar checks in CheckParameters() and
CheckHeader(). So, don't duplicate the checks.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I72375496e5df7b7c17df25d358f2555fe41fe520
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/407053
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
LoadKernel() was a big function which did everything from looping over
partitions on a drive to loading the data within them to calling the
low-level verification functions on that data. Split it apart into more
manageable chunks. This also reduces indentation of the inner parts of
the code, whic increases readability.
No outwardly-visible functionality changes.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: Iea79e70163f5d9f1a9d0d897e4a9bacc925a742d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404919
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This new recovery reason will instruct the calling firmware in
vboot_select_and_load_kernel to reboot the device (under the assumption
that training of memory has already been performed by the firmware). On
seeing the return code VBERROR_REBOOT_REQUESTED, calling firmware should
perform a reboot.
BUG=chrome-os-partner:59352
BRANCH=None
TEST=make -j runtests successful
Change-Id: I110a735e612665cb2378bd71ca01a111edaf58e3
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/407656
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously, vb2_unpack_key() actually unpacked a key buffer. Callers
that had a vb2_packed_key had to typecast it back to a uint8_t buffer to
unpack it. Rename vb2_unpack_key() to vb2_unpack_key_buffer(), and make
vb2_unpack_key() unpack a vb2_packed_key.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge;
emerge-samus and boot it
Change-Id: I9ee38a819c59cc58a72ead78cf5ddf3d0f301ae7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400906
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Originally, vboot1 code used VbExMalloc() and VbExFree() since it needed
to talk to EFI firmware that didn't have standard malloc() and free().
Now, coreboot and depthcharge implement them as wrappers around those
standard calls. vboot2 code already calls them directly, so let vboot1
code do that too.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I49ad0e32e38d278dc3589bfaf494bcf0e4b0a4bd
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400905
Now that the vboot1 cryptolib code is gone, nothing uses stateful_util.
Remove it and its unit tests.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I75b6014be00c5266545db10e87c1d9485fd1444b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400904
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
At this point, all that's left are a few constants in the cryptolib
header files, and they're only used by host-side code. So move them to
a host-side header file and get rid of cryptolib.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I2235f0e84e13fef313afe54e749b73744b157884
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400903
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
The old vboot1 cryptolib hard-coded many of its padding arrays in a
padding.c file. Use the equivalent vboot2 apis instead.
This change is almost exclusively on the host and test side; the only
firmware impact is on a single line of debug output.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: If689ffd92f0255847bea2424950da4547b2c0df3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400902
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This change makes run_test_scripts.sh dump stderr to the terminal
so that the failed test can be debugged. This is necessary to
analyze a failing test on build servers.
BUG=none
BRANCH=none
TEST=sudo FEATURES=test emerge vboot_reference && FEATURES=test
USE=minimal emerge-samus vboot_reference && make runtests
Change-Id: Id9ae0fb174cfe382ec30a1175f54c0891543c46e
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403428
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Another in a continued stream of refactoring. This change removes more
of the vb1 rsa library code and associated tests, in favor of their vb2
equivalents. This change touches only host-side code and its tests, not
firmware.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I1973bc2f03c60da62232e30bab0fa5fe791b6b34
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400901
No need to have two implementations of this now.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I18bac928eb09971c37f3e1d7cbfd2009999b1f31
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400899
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
No need to have two implementations of this now.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: Id3348eae80c5d85451981a44729164ff59f88648
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/399121
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Originally, we didn't trust the firmware to provide these functions from
a standard library. Now, with coreboot, we do.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I4e624c40085f2b665275a38624340b2f6aabcf11
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/399120
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This change makes futility show command to dump data header information
in a BDB. # of hashes is used to verify 'futility bdb --add' can add a
hash in the unit test.
BUG=chromium:649554
BRANCH=none
TEST=make runtests. run futility show tests/futility/data/bdb.bin
BDB Header:
Struct Version: 0x1:0x0
BDB key digest: c7895611c24efb2249d97376189eeee07def6bcd8ab162a3850d279354f08ddf
size: 1176
Data Header:
Struct Version: 0x1:0x0
# of Hashes: 2
Hash Entry Size:56
Signed Size: 272
Description:
Hash #0:
Offset: 0x2
Size: 35
Partition: 3
Type: 1
Load Address: 0x4
Digest: 72bcf33f448465f035bd58e4b61501db925e67c89feb4a70cb909d8b425861f4
Hash #1:
Offset: 0x2
Size: 35
Partition: 3
Type: 1
Load Address: 0x4
Digest: 72bcf33f448465f035bd58e4b61501db925e67c89feb4a70cb909d8b425861f4
Change-Id: I88934b761236f36a5d607c96f6f2543a62e50b68
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/392949
bdb_get_hash_by_index returns a hash entry from a BDB using an index.
bdb_get_hash is also renamed to bdb_get_hash_by_type. bdb_get_hash
is deprecated. Callers are expected to call bdb_get_hash_by_index(buf, 0)
instead.
BUG=none
BRANCH=none
TEST=make runtests
Change-Id: Id99926123c0ac9094574eb057c63f79eceda2867
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/392947
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When --ignore_key_digest is specified, futility bdb --verify command
returns success even if the key digest didn't match. Warning message
will be printed to remind the digest wasn't checked.
BUG=chromium:649554
BRANCH=none
TEST=Tested as follows:
$ build/futility/futility bdb --verify tests/futility/data/bdb.bin \
--ignore_key_digest
BDB is valid. Key digest doesn't match but ignored.
$ echo $?
0
Change-Id: I996b0a4f7bbbcf546e2d958f28c5ee8fb251fb99
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/392946
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Currently, test macros print out 'desc' regardless 'comment' is specified
or not. This patch makes TEST_EQ print 'desc' only if 'comment' is not
supplied.
BUG=none
BRANCH=none
TEST=make runtests
Change-Id: I9cc3c9a9561534352ae0315dfea983f2c212b909
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388859
Reviewed-by: Randall Spangler <rspangler@chromium.org>
