Storing nvram in SPI Flash becomes more and more popular. Retrieving
it takes quite a while due to various flashrom issues. While flashrom
still needs to be improved to minimize its running time, a good speed
up can be achieved by caching the nvram contents in crossystem.
The cache is invalidated each time nvram is written (this could be
optimized by updating the local copy, but probably is not worth the
extra effort).
BRANCH=storm
BUG=chrome-os-partner:33592
TEST=crossystem runs much faster now:
localhost var # time /var/tmp/crossystem
. . .
real 0m1.669s
user 0m0.790s
sys 0m0.170s
localhost var #
Change-Id: Ie4a483efc189257ff58c92bdc39871b917c89727
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228655
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Use struct vb2_signature2 objects to hold the hashes of firmware
components, rather than a separate vb2_fw_preamble2_hash struct.
Better for code reuse.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Ia9e23c1488a884f2d6fab4c4be51b25d3ff25c2f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228241
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
When a work buffer is passed to a function, and duplicated inside that
function, allocations made against the duplicate are automatically
freed when the duplicate goes out of scope. Make that explicit in the
comments. And pass in const struct workbuf * instead of struct
workbuf *, to make it clear that the passed-in work buffer pointer is
not being altered by the function.
Also, comment that the value of min_offset becomes undefined if
vb2_verify_common_member() or vb2_verify_common_subobject() fails.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Icc6010e6ef786f78cd2176a59d4d0e6e14905a11
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227524
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This adds the vb2_signature2 equivalents of vb2_verify_digest() and
vb2_verify_data(), including support for bare hash signatures.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I372c9e5f0be926a833e4ca8f84665cfb05907481
Reviewed-on: https://chromium-review.googlesource.com/226950
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Randall Spangler <rspangler@chromium.org>
This reduces duplicated code in the test functions. (Well, not so
much duplicated code yet, but it will when more tests are added in the
next CL. And it's easier to review this piece separately from the
added tests.)
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I863cdfd44d35b55df9799fd45a6cf8e40dd1ad21
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226925
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Previously, we had a mix of sig_algorithm and sig_alg member names,
and it was hard to remember which struct used which variant. Prefer
sig_alg because of the 80-column limit. Same with hash_alg
vs. hash_algorithm
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Ifbb60f3172549e29efc0fb1f7f693efa51eb7cc3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226943
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Add functions for verifying object integrity using common header size
fields. Convert vb2_packed_key2 to use the the new functions. This
isn't much prettier for packed keys; the benefit is more obvious for
keyblocks (coming next).
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I0c09533368abb7ced3b5ac622a15e62832413b7f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226874
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This was deleted in the previous commit and breaks building
with MOCK_TPM=1
BUG=chrome-os-partner:32698
BRANCH=all
TEST=build with MOCK_TPM=1
Change-Id: Ie437f9fb4c60161a95ca1cf992035858f02e3f19
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227220
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The rest of the system software expects dev mode to be
orthogonal to recovery mode. However, vb2_fw_phase1() was
only checking recovery mode. The caller would then not
call vb2_fw_phase2() which checked the developer mode settings.
Fix this by doing the necessary steps in vb2_fw_phase1().
BUG=chrome-os-partner:33264
BRANCH=None
TEST=None yet.
Change-Id: I06da388c3ca33754ddb5937a2877fbc287946490
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/225906
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Some devices may use rootdev=/dev/dm-1 as root device (the default one was
dm-0, according to build scripts). Running make_dev_ssd.sh
--remove_rootfs_verification on these devices will fail changing rootdev kernel
command line, and cause people not able to re-mount root device as writable.
To support running make_dev_ssd on these devices, we want to change the rootdev
pattern to dm[0-9].
BUG=chromium:428041.
TEST=make_dev_ssd.sh --remove_rootfs_verification
BRANCH=none
Change-Id: Idfd251c58e7d39b0b80ec1fc68989c2f49bdd1b2
Reviewed-on: https://chromium-review.googlesource.com/226782
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Originally, we designed the vboot data structures so that some of them
had sub-structures. Then the variable-length data for each of the
structures was at the end. So:
struct vb2_keyblock {
struct vb2_packed_key
struct vb2_signature
}
// Followed by variable-length data for keyblock
// Followed by variable-length data for packed key
// Followed by variable-length data for signature
This had the weird side effect that the header and data for the
sub-structs were not contiguous. That wasn't too bad before, but it
gets more complicated with the new data structures. Each structure
now can also have a description. And keyblocks can have a list of
signatures.
Structures also couldn't really know their own size, since a
sub-struct might have a 20-byte header, but then 2K of other data in
between that and the data for the sub-struct itself.
So, un-nest all the data structures. That is, the keyblock now
contains the offset of the signature struct, rather than the signature
struct itself. And then all the variable-length data for each struct
immediately follows the struct itself. So:
struct vb2_keyblock2 {
// Offset of packed key
// Offset of first signature
}
// Followed by variable-length data for keyblock
struct vb2_packed_key
// Followed by variable-length data for packed key
struct vb2_signature2
// Followed by variable-length data for signature (desc, sig data)
Verifying and traversing these objects is much more straightforward.
And each struct can now know its own size.
This first change rearranges the structures. Descriptions now
immediately follow the fixed size structure headers.
The next change adds better verification of the structures, using the
fixed_size and total_size fields in the common header.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Ieb9148d6f26c3e59ea542f3a95e59d8019ccee21
Reviewed-on: https://chromium-review.googlesource.com/226824
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Randall Spangler <rspangler@chromium.org>
Signatures with VB2_SIG_NONE are unsigned hashes. To make it easier
to locate these signatures in the keyblock's list of signatures,
define GUIDs for them.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I5bf9424107d7703b1a191b1bdf02954192ffc583
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226813
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
When GptLoad() fails to validate a header, it will not load the
corresponding entry array, and hence will not allocate memory. The
"*_entries" pointer then stay NULL. This CL checks for NULL pointer in
CheckEntries() in the same way that CheckHeader() does.
BUG=none
BRANCH=none
TEST=unittest
Change-Id: I9f72e843590fbcbcf90d55640f86c782446e8755
Reviewed-on: https://chromium-review.googlesource.com/226778
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
GBB header v1.2 adds a digest of the HWID string to the blob (and
maintains it when updated with the current futility/gbb_utility).
This CL causes VbSelectFirmware() to extend PCR1 with that HWID
digest (only for GBB header v1.2 and later, of course).
Tests are updated.
This also adds a "pcr" command to futility to help determine that
the change is working on the hardware (adds 4K bytes or fewer to
the size of the executable).
BUG=chromium:415714
BRANCH=ToT (and maybe others?)
TEST=make runtests, manual install on HW
To test on hardware, build and update a system with this change
(both the disk image and the RO firmware).
NOTE: The BIOS image must be built in a chroot that is using the
current version of futility. You may need to update your chroot
if your BIOS image still produces v1.1 GBB headers. Check with:
futility show <firmware_image.bin> | grep -B1 'digest:'
Boot the new system with a new test image, then follow these steps:
Read the BIOS:
# flashrom -r /tmp/bios.bin
Make sure the GBB has a valid digest for the HWID.
# futility show /tmp/bios.bin | grep -B1 'digest:'
HWID: SAMUS TEST 8028
digest: 4172d24f40bf72cc0ab8... <valid>
#
Extract only the sha1sum-sized part of the HWID digest:
# futility show /tmp/bios.bin | awk '/digest:/ {print $2}' | colrm 41
4172d24f40bf72cc0ab878b4c589b8fe9cf4405e
#
Simulate extending that value in a PCR using the futility "pcr"
command:
# futility pcr 4172d24f40bf72cc0ab878b4c589b8fe9cf4405e
PCR: 0000000000000000000000000000000000000000
+ 4172d24f40bf72cc0ab878b4c589b8fe9cf4405e
PCR: b6e5ffd2d898a7b15236ad22ca25f53ac1f40776
#
Finally, look at the value of PCR1. It should match the last line
of the futility pcr output:
# head /sys/class/misc/tpm0/device/pcrs | grep PCR-01
PCR-01: B6 E5 FF D2 D8 98 A7 B1 52 36 AD 22 CA 25 F5 3A C1 F4 07 76
#
Change-Id: I09cf855f1a24616cc1a9ddb676670edbc76827d2
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226408
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This unpacks new-style packed keys.
For now, it can also handle old-style packed keys by passing them to
the old unpacking function. Once we've switched over to new-style
keys in the signing scripts, we'll remove the old format to save code
size.
Also added is a test library which converts from old to new struct
formats. That should eventually get absorbed into futility, and the
test keys directory should have both old and new format packed keys in
it.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I0fe31f124781d1ea1efedab65dcd6130bfca18dd
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225490
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
All new-style structs have a common header. This adds a verification
function for that common header, and tests for it.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I668486e77f7200c10b43aa2d17b4dd6639e5538e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225459
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
For kernel NAND support, some vboot/cgptlib functionality is
needed from depthcharge. This patch moves certain function
declarations to a new header in firmware/include and puts
their definitions in a common place.
TEST=make runalltests passes and packages build
BRANCH=none
BUG=chromium:403432
Change-Id: Idd42b1f9f531651d78bb4afb80ca90c24aae93d9
Reviewed-on: https://chromium-review.googlesource.com/224996
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Daniel Ehrenberg <dehrenberg@chromium.org>
Tested-by: Daniel Ehrenberg <dehrenberg@chromium.org>
Move packed key functions to their own file, in preparation for
introducing support for vb2_packed_key2.
Rename the awfully-named vb2_verify_fw_preamble2() function to
vb2_load_fw_premable(), since the new structs actually have a
vb2_fw_preamble2 struct and that would be very confusing.
Rename vb2_verify_fw_keyblock() to vb2_load_fw_keyblock(), so it
matches.
No functional changes, just renaming.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Ia914e48e6c5814ab3205b999ceda1aa2452206ff
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225458
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This changes the internals of vboot2 to use the enumerated type for
signature algorithm. The conversion from crypto algorithm is done
only when unpacking the key. This is preparation for the vboot2 data
types, which separate signature and hash algorithms into their own
fields.
There is no external change in the calling API to vboot, and no change
to the external data structures.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I2e176d186d88cc7541644e001e720b4aee456be0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225209
This changes the internals of vboot2 to use the enumerated type for
hash algorithm. The conversion from crypto algorithm is done only
when unpacking the key (and ok, in checking the rsa padding, but that
goes away in the next change). This is preparation for the vboot2
data types, which separate signature and hash algorithms into their
own fields.
There is no external change in the calling API to vboot, and no change
to the external data structures.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I9c6de08d742dab941beb806fbd2bfc1e11c01e2c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225208
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Looks like vboot2 currently never outputs the current recovery reason
anywhere, which is annoying for debugging devices without working
display (where you could press TAB). This patch adds log messages both
when deciding to go into recovery mode and when picking up an existing
recovery request from NVRAM, for maximum visibility.
Also removes the "Both slots are bad." part of the vb2_fail() message,
since this is not necessarily true and can be confusing (there are many
other possible reasons why it might want to go into recovery).
BRANCH=ToT
BUG=None
TEST=Manual
Change-Id: Ic98c61223dce00e830ea0f199878d47b214bb224
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225160
Reviewed-by: Randall Spangler <rspangler@chromium.org>
These structures allow for simplication and feature expansion in
vboot. They are NOT backwards-compatible with old vboot1 structs.
This CL simply adds the new structs and unit tests for struct packing;
future CLs will add support for them in the firmware library and
futility.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I22532acf985dd74316bd30f17e750f993b6c53d7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224820
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
vboot2 supports only GBB header versions 1.1+. When the GBB header
was rev'd to 1.2, this broke the compatibility check for 1.1.
However, the test was written in such a way that wasn't detected. Fix
the check and the test.
BUG=chromium:415227
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Ifeb1f21bf5cf3cc05d31ac7912693e090eb8fd5e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225110
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This removes code duplicated between 2common.c and 2rsa.c. This is in
preparation for adding new unsigned hash algorithms.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make -j runtests
Change-Id: Ic9c542ae14d3b7f786129c1d52f8963847a94fb8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224780
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This adds a field in the GBB header to store the sha256 digest of
the HWID string, and updates gbb_utility so that it stores the
digest when it modifies the HWID. Because this is a new field,
the GBB_MINOR_VER is incremented.
BUG=chromium:415227
BRANCH=ToT
TEST=make runtests, VBOOT2=1 make runtests
Since the GBB is in the RO firmware, there should be no side
effects for existing devices (but even without that, they should
handle a minor version change without complaint).
Change-Id: Icdb2a0b564677b0b65e58df897d2ec5af3964998
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221360
The current logic for finding a GPIO expects only one gpiochip
entry to exist in /sys/class/gpio. With Samus there is a second
entry because the codec also exports a set of GPIOs.
To solve this we can use the gpiochip#/label file and compare
against the GPIO controller name described in ACPI.
This adds support for that detection method, as well as a new
GPIO controller entry for INT3437:00 which is used in Broadwell
systems.
BUG=chrome-os-partner:33098
BRANCH=samus
TEST=crossytem wpsw_cur works on samus (TOT with enabled codec)
Change-Id: Ib06f25c7c7e1451a3ab3bb00fd063e23b4d75878
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224156
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Currently ReadFileInt assumes that an integer value read from a file
is never going to be "-1" and uses that value to indicate failure.
In particular for GPIO values that may be returned by the kernel it
is possible for them to be not simply 0 or 1 but instead a bit within
the GPIO status register that indicates the value.
The function semantics are changed to have the caller pass in the
variable to store the integer in, and use the return code explicitly
as a pass or fail condition.
This requires all the callers of ReadFileInt to be changed to use the
new scheme, and the x86 ReadGpio function is changed to normalize the
GPIO value that is read from the kernel instead of assuming it is
always 1 for active high values.
BUG=chrome-os-partner:32645
BRANCH=samus,auron
TEST=build for samus, check crossystem output and ensure that all
values are properly reported and that wpsw_cur is correct now.
Also tested to ensure no changes in output on: x86-alex, daisy,
peach_pit, lumpy, stumpy, nyan_big, nyan_blaze, rush_ryu, panther,
wolf, zako, auron, rambi, squawks, parrot_ivb, veyron_pinky
Change-Id: I824152eed5f96cf1faaa18ba31a01f4d346ad172
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223009
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This will be needed by other algorithms, so should not live inside the
rsa module. Also added explicit unit tests for it.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I92c8c6484964a93d755ac2ee93b57511794540e9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224111
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This CL validates the GPT headers before continue loading its fields.
BRANCH=none
BUG=chromium:422469
TEST=unittest
TEST=cpgt show on a random file. There should be some warnings.
TEST=boot from SD/USB on a device. cgpt show that boot device. It should
not fail.
Change-Id: I1e5e986cc46620643ec8ec6914fa696a3d04d23a
Reviewed-on: https://chromium-review.googlesource.com/223800
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
In order to display the slow EC update screen on x86 devices
in normal mode it is necessary to request a reboot where the
VGA Option ROM is loaded.
This needs a bit of plumbing to pass the OPROM_MATTERS and
OPROM_LOADED flags into shared data so they can be consumed
in the VbEcSoftwareSync() function. It also needs the VbInit()
function to not immediately request a reboot if the VGA Option
ROM was loaded in normal mode and the SLOW_EC flag is set as it
will still need to be used during software sync.
A FIXME in VbEcSoftwareSync() is implemented and the comment is
removed, and two extra checks are done. First, if rebooting to
RO then also check if the VGA Option ROM is needed to save an
extra reboot, and second when exiting the software sync function
request a reboot without the VGA Option ROM if it was done in
normal mode and the option rom was needed+loaded.
The request for a reboot from VbEcSoftwareSync() is saved when
doing EC update in case there is an (optional) PD software sync
that may also need to display the screen.
BUG=chrome-os-partner:12257,chrome-os-partner:32379
BRANCH=samus
TEST=all tests pass, manual testing:
1) in normal mode, with EC/PD in RW, ensure that they are rebooted
to RO and the VGA Option ROM is loaded and the wait screen is
displayed, and then the system is rebooted at the end and the
VGA Option ROM is not loaded.
2) same as #1 with EC/PD in RO already, same result
3) same as #1 with system in developer mode, same result except
there is no reboot at the end of software sync
4) same as #1 with system in developer mode and EC/PD in RO,
ensure that there is no extra reboot at the beginning or end of
software sync.
Change-Id: Id592181efd640f4cd37a986cd1dcc29f3ca45104
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223718
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
ChromiumOS images have recently changed the installable vblock from stateful
partition to kernel + vblock in slot B. sign_official_build script should
follow that layout so other scripts (ex, cros_generate_update_payload) won't
find wrong blob.
BRANCH=none
BUG=chrome-os-partner:32156
TEST=for image_t in ssd usb install recovery; do
./sign_official_build.sh $image_t IMAGE KEYDIR output$image_t.bin
./sign_official_build.sh verify output$image_t.bin
done
# Also boots images without problem.
Change-Id: I04e2b50f3f3355263ba6de9567b4a82c040c5826
Reviewed-on: https://chromium-review.googlesource.com/221890
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
And add a few hash tag types we'll be supporting soon.
No functional changes; just moving an enum from one header to another.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I6f0fa54ee85fd857c4037856b81e2159e92f1ea9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223532
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This allows the algorithm list to be shared by code which simply needs
to look at the vboot structures.
No functional changes; just moving enums around and adding comments.
BUG=chromium:423882
BRANCH=none
TEST=make runtests; VBOOT2=1 make runtests
Change-Id: Ia8cefeffb28d5eceb290540195193ea13e68e2c1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223541
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Now that futility is pretty much working as intended, we don't
have to be quite so picky in the way it's being invoked. Up until
now, it's only worked when invoked as "futility" or as one of the
built-in commands, such as "dump_fmap".
This change removes those restrictions. You can invoke futility
under any name you wish. If it recognizes the name as a built-in
command, great. Otherwise it will require a valid command as the
first arg, just like it always has.
BUG=none
BRANCH=ToT, Samus
TEST=make runtests
In addtion to the new test included with this CL, I manually ran
lddtree --copy-to-tree=blah --generate-wrappers /usr/bin/futility
./blah/usr/bin/futility dump_fmap -h tests/futility/data/bios_peppy_mp.bin
Before this CL, the wrapper didn't work because the binary was
being invoked as futility.elf, which was rejected. After this CL,
the wrapper works fine.
Change-Id: Iafdaff6e07ed294a7d29e4cff599ace0a3089229
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223386
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This is necessary to support reading the kernel from raw NAND flash,
where the driver may need to skip over bad sectors, and absolute
sector addressing is thus not practical.
The impact is relatively minor. Vboot only did two reads per kernel
anyway, one for the first 64KB of the partition and a second for the
rest of the kernel data.
Firmware which uses vboot will need to implement the streaming APIs.
Or, as a really easy workaround, just copy the implementation from
firmware/stub/vboot_api_stub_stream.c, which translates from the new
streaming API to the old sector-based disk API.
BUG=chromium:403432
BRANCH=none
TEST=make runtests; passes.
CQ-DEPEND=CL:221992, CL:222885, CL:222945
Change-Id: I7437b489650c95c09ac68b67d4d86f9e15c2fa73
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222410
Reviewed-by: Daniel Ehrenberg <dehrenberg@chromium.org>
This patch adds three functions called from vboot into depthcharge to
support NAND. NAND needs to stream rather than be accessed randomly
in order to skip bad blocks. The intended flow from vboot1 is:
- Read the GPT from a NAND disk handle, and depthcharge will silently
fill it in with reads from from SPI
- When a partition is selected, open a stream on the volume to access
NAND
- Sequentially read the NAND partition
- Close the NAND stream
This can be done multiple times when trying different partitions. The
stream is associated with the GPT by reading/opening a stream from the
same disk handle.
This patch includes stub implementations by rspangler to translate the
stream calls to block device calls.
To reduce vboot code duplication, this flow will be done for all media
types eventually, but a STREAMING flag is included to ease the transition.
The draft depthcharge code can be found at
https://chromium-review.googlesource.com/#/c/222312/
BUG=chromium:403432
TEST=stub implementations pass unit tests; together with upcoming depthcharge
and vboot code, actually boots a kernel. This compiles by itself.
BRANCH=none
Change-Id: I660a89594390c72c2ef6ea2564367ce62bd90cf2
Reviewed-on: https://chromium-review.googlesource.com/221992
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Daniel Ehrenberg <dehrenberg@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Randall Spangler <rspangler@chromium.org>
This is just a cosmetic tweak to make it a bit clearer that
mosys is the underlying interface for these particular vbnv
read/write functions.
BUG=none
BRANCH=none
TEST=it still compiles
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ide172bfecf608a30489d25026268aedfc421ce4d
Reviewed-on: https://chromium-review.googlesource.com/222062
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This handles VBNV data stored in SPI flash which happens to be
the exact same way we handle VBNV data stored in the EC.
BUG=chrome-os-partner:31529
BRANCH=none
TEST=with CL:221349 applied, crossystem on storm no longer
spews tons of errors
Change-Id: I021d9f430acfac34dff44a927361a5a0e5ae2ff8
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222061
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If we try to sign an image w/out Chrome, this file won't exist.
Run grep with the -s flag to silence those warnings.
BUG=chromium:418817
TEST=`cbuildbot storm-release` no longer warns
BRANCH=None
Change-Id: Ibac0978e3e4d9f89c00206a2dd21c1d71544f710
Reviewed-on: https://chromium-review.googlesource.com/221184
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
This gives recovery mode information on two boots back instead of one,
which may be handy for debugging.
It also allows determining whether a failure of the current boot
should try the other slot or go to recovery, using only information
stored in NV storage.
Added crossystem support for printing the fields, and unit tests.
BUG=chrome-os-partner:32585
BRANCH=none
TEST=make runtests; VBOOT2=1 make runtests
Change-Id: Ia9f4186210d30217b902db7c513ae4ab8851f8f4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221230
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Any of these:
make xrefs
make tags
make TAGS
should create "build/cscope.files", containing a list of the
source files used in preparing to run tests (minus any test
sources). If the 'ctags' or 'etags' programs are installed in the
chroot, they'll be run too.
BUG=none
BRANCH=ToT
TEST=manual
make xrefs
cat build/cscope.files
Change-Id: If1173af7edb41742bb348b728238d800ef66ad55
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221425
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously, we only kept that slot info in RAM. We read it from NV
storage, but never wrote it back.
Added a test to confirm proper behavior (and made sure it failed
before patching 2misc.c with the fix).
BUG=chrome-os-partner:32583
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Ie12124d9cbe417914fbde14ea5086380d637240f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221214
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This just involves deleting the "set -o pipefail" line. With
bash, that meant that any program failure in a pipe would be
fatal. Without it, only the last program matters. This usually
means that the last command simply gets no input, in which case
the program just appears to do nothing instead of complaining
about whatever the problem was.
Since vbutil_what_keys is generally only used to help debug a
failure to boot, that's not a major problem.
BUG=chromium:419773
BRANCH=ToT
TEST=manual
Tried on a Pit, it works:
localhost ~ # /tmp/vbutil_what_keys /dev/mmcblk0
-e
IMAGE: /dev/mmcblk0
part 2 kernel: d6170aa480136f1f29cf339a5ab1b960585fa444 (!DEV DEV !REC) developer keys
part 4 kernel: d6170aa480136f1f29cf339a5ab1b960585fa444 (!DEV DEV !REC) developer keys
localhost ~ # flashrom -r /tmp/bios.bin
flashrom v0.9.4 : 904e8a5 : Sep 22 2014 20:47:40 UTC on Linux 3.8.11 (armv7l), built with libpci 3.1.10, GCC 4.8.x-google 20140307 (prerelease), little endian
Reading flash... SUCCESS
localhost ~ # /tmp/vbutil_what_keys /tmp/bios.bin
-e
BIOS: /tmp/bios.bin
hwid: PIT D3A-D4Q-A3L
root key: a026a7a4a0bf0fa32d6b7aa90a80d5ef01a3b799 Daisy MP-v3, Peach-Pi MP, Peach-Pit MP-v2, Snow MP
recovery key: 6d9a2ca8b3080a97e1e5a4efbc5386ead77c3c7f Peach-Pit MP-v2
localhost ~ #
Change-Id: I171da3bf688032f469d7a5cdb42278d8028b7e0d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221176
Reviewed-by: Mike Frysinger <vapier@chromium.org>
BUG=chromium:419773
BRANCH=ToT
TEST=manual
make MINIMAL=1 DESTDIR=FOO install
make MINIMAL= DESTDIR=BAR install
find FOO BAR -name vbutil_what_keys
It should only install the script into BAR/.
Change-Id: I48d3a780533c5b72cc18720d39b18ac286b07fd9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221177
Reviewed-by: Mike Frysinger <vapier@chromium.org>
When disabling verity with make_dev_ssh.sh, a bug in
vbutil_kernel caused the re-signed kernel size to be the entire
kernel partition instead of just the necessary bits. Until we can
improve the test coverage, I'm rolling back the changes that
introduced this bug.
BUG=chromium:418647
BRANCH=ToT
TEST=manual
Created a new test image with these changes. You can install it
and disable dm-verity and it works (although there seems to be an
unrelated browser startup issue on ToT).
Change-Id: I48e8427b05e191c9894c42056429a79d57bfc78d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220935
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In AllocAndReadGptData() the code was changed to use the GPT header
to determine the LBA of the GPT entries. This change did not account
for devices that have an invalid header and it can attempt to read
from invalid block addresses on a device.
This commit happened here:
a2d72f7 vboot: cgpt: Refer to partition entries by entries_lba.
https://chromium-review.googlesource.com/213861
The subsequent steps in vboot, LoadKernel->GptInit->GptRepair will
fix a missing header and entries, so it is only necessary for one of
the headers to be valid.
This is commonly the case with a new USB stick that has an image
written to it as only the primary header will be valid in this case.
However it is also true if the primary header has been corrupted and
the secondary header is still valid.
The code has been changed to call CheckHeader() on the primary and
secondary headers before attempting to use the 'entries_lba' field
to read the entries from the device. AllocAndReadGptData() now only
fails if both headers are invalid.
A number of new unit tests are created to check for these failure
conditions. In order to support this I had to extend the vboot_kernel
test infrastructure to have a buffer for the mocked disk data instead
of just ignoring reads and writes. This is because many of the existing
tests assumed they could have an invalid GPT header and still pass.
Now that the header is checked it is necessary for a valid header to
be created before the tests can pass.
BUG=chrome-os-partner:32386
BRANCH=samus,auron
TEST=All unit tests pass when running 'make runtests'
In addition real-world testing was done by corrupting the primary
and/or secondary headers of USB stick to ensure that it will
successfully boot if one of the headers is valid.
Change-Id: I7f840a44742fa3ba9a124df29ab5749e4c5a40c1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220757
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Nam Nguyen <namnguyen@chromium.org>
This adds a --strict mode to the show command, which requires
that all signatures be valid in order to exit cleanly. It also
creates a "verify" command, which is really just an alias for
"show --strict".
BUG=none
BRANCH=ToT
TEST=make runtests
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I1fed7db7fe7128191bcab0c615706ef4fe2709f5
Reviewed-on: https://chromium-review.googlesource.com/219732
Reviewed-by: Randall Spangler <rspangler@chromium.org>
