Following changes are done to the cgptlib API in order to allow backend
component of fastboot to perform erase and write operations on
partitions and manipulate GPT entries:
GptFindNthEntry - Returns the nth entry in GPT that matches provided
GUID.
GptGetEntrySizeLba - Returns size of a partition in lba.
GptGetEntrySizeBytes - Returns size of a partition in bytes.
GptUpdateKernelWithEntry - Given kernel entry is updated using the
provided update_type. GptUpdateKernelEntry calls this function with
entry for current_kernel.
Add flags GPT_UPDATE_ENTRY_RESET and GPT_UPDATE_ENTRY_INVALID for
calls to GptUpdateKernelEntry. These operations are used by write
image and erase partition respectively.
BUG=chrome-os-partner:35861
BRANCH=None
TEST=Compiles successfully and all the newly added functions work as expected.
Change-Id: I82c87e4c97de2d207e80209dbd4922b4bcd5880a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/240268
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Adding functionality to allow for rebuilding of vmlinuz after it
has been processed into vblock and header stripped. Basically appends
the 16-bit header of a vmlinuz image onto the end of the vblock.
BUG=chromium:438302
BRANCH=none
TEST=Successfully ran "make runalltests".
Also, ran:
1. Repack kernel block (so that 16-bit header is included):
"vbutil_kernel --pack kern_0 ..."
2. Verify kernel: "vbutil_kernel --verify kern_0 ... ". This should
be done before booting into kernel, but not necessary for it to work.
3. Rebuild vmlinuz image:
"vbutil_kernel --get-vmlinuz kern_0 --vmlinuz-out vm.out"
4. Set up kexec with vmlinuz (this should complete with no errors):
"kexec -l vm.out (other kernel cmd line args)"
5. Boot into kernel:
"kexec -e"
Change-Id: Iaa1582a1aedf70b43cdb3a56cde1fb248f1793d4
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232750
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The verify_kernel command is used only in a host-side test. It
doesn't need to be built into futility. This makes it a separate
executable used just for that test.
BUG=chromium:231547
BRANCH=none
TEST=make runtests
Note that the load_kernel_tests.sh still passes, using the
external verify_kernel executable.
Change-Id: I309d2561d65af7eb4f3708e9bc024852238deeec
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235480
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Now that the underlying bug is fixed (commit 64ef69c), this
replaces the old vbutil_kernel command implementation with the
new one that we rolled back in commit f1dba02.
BUG=chromium:418647
BRANCH=none
TEST=make runtests
I've also built an image with this change, installed it on a
Chromebook, ran make_dev_ssd.sh, make_dev_firmware.sh, recovered,
etc. Everything still works.
Change-Id: I8996e674a24b5d994658a6be2973ef3623cd659b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235429
Reviewed-by: Randall Spangler <rspangler@chromium.org>
flashrom spills out "Reading flash... SUCCESS" and so on to stdout. This
affects scripts calling to "cgpt". So this CL sets stdout to CLOEXEC
before exec'ing flashrom. It still leaves stderr and stdin unclosed.
BUG=None
BRANCH=None
TEST=cgpt show /dev/mtd0 2>/dev/null will not show any unnecessary text
Change-Id: Ide1414c56f63ffe8bc2385a797f166476dacd732
Reviewed-on: https://chromium-review.googlesource.com/242295
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@google.com>
Because we do not use "execvp", "cgpt.bin" is not resolved to the same
directory as "cgpt". So we need to resolve the original command to its
absolute path first, then append ".bin" to it.
BUG=None
BRANCH=None
TEST="cgpt" no longer fails.
Change-Id: Id22c2d97616867125e9744c00bbf527f8a176df4
Reviewed-on: https://chromium-review.googlesource.com/242294
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@google.com>
We always wrote back the rw_gpt file to NOR flash. This operation is too
slow. This CL compares if the original file has been changed by cgpt.bin
before writing the file back to NOR.
BUG=None
BRANCH=None
TEST=/usr/bin/cgpt show /dev/mtd0 now does not write back to NOR
Change-Id: I4c63f0d4da72f3674e06a896fa329f5fc964a885
Reviewed-on: https://chromium-review.googlesource.com/242293
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@google.com>
When working on NAND, we do not actually work with one device name. We
work on a temporary file instead. Moreover, depending on the type of the
partition, we need to show different devices.
BUG=None
BRANCH=None
TEST=All commands must be run on storm_nand
TEST=/usr/bin/cgpt.bin find -t kernel should print out /dev/mtd2
TEST=/usr/bin/cgpt.bin find -t rootfs should print out /dev/ubiblock5_0
TEST=/usr/bin/cgpt.bin find -t data should print out /dev/ubi1_0
Change-Id: Ia36777ffa6a9cfc7c8ec4b128e49ece140428238
Reviewed-on: https://chromium-review.googlesource.com/242291
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@google.com>
This CL adds a "cgpt_wrapper" binary that will forward to "cgpt" binary
as needed to transparently support NAND.
The idea is that if we are working with an MTD device, this binary will
exec out to "flashrom" to read in the GPT section, then exec out to the
actual "cgpt" binary to work on that file, and finally write it back
with "flashrom".
This CL introduces a make target "install_mtd" to install this wrapper.
The corresponding ebuild should use this make target when "mtd" USE flag
is on.
BUG=chromium:442518
BRANCH=none
CQ-DEPEND=CL:239573
TEST=unittest and some trial runs with mtdram
TEST=test on a real device with NOR flash and NAND
Change-Id: I54534afa9a970ec858f313f698c0eb210c827477
Reviewed-on: https://chromium-review.googlesource.com/239580
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Reviewed-by: Daniel Ehrenberg <dehrenberg@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
The shar utility changed the flag name and newer versions no longer
accept -w. Mung the shellball on the fly to use the newer flag.
BUG=chrome-os-partner:33719
TEST=signing old firmware shellball inside chroot passes
BRANCH=none
Change-Id: If5c2da3062bd72062baa779bb26ea56304c31558
Reviewed-on: https://chromium-review.googlesource.com/241064
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Add a STATIC knob to easily get static builds of all binaries.
We want this for the signer system.
We also need to fix the bmpblk utility to look up its libraries
via pkg-config.
BUG=chromium:447051
TEST=`make STATIC=1` works now
BRANCH=none
Change-Id: Icaef1f19f4618b0ce2b934735796749539081a02
Reviewed-on: https://chromium-review.googlesource.com/241041
Trybot-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@google.com>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This patch changes the FMAP detection mechanism in host utilities to use
the same algorithm as flashrom: try to check the offset with the largest
possible alignment first, then subsequently check other offsets in the
order of larger to smaller alignments. This provides consistency between
the tools and makes the chance of finding the "wrong" FMAP (e.g. a bit
pattern that just looks like an FMAP header, maybe from a piece of
source code that tries to look for the same) less likely, since we
usually try to prefer large alignments for the FMAP offset (for flashrom
efficiency).
BRANCH=None (should be updated on the signers... is that a branch?)
BUG=chromium:447051
TEST='make runtests'. Manually ran the new dump_fmap on all images in
tests/futility/data, and on a "known broken" Veyron_Pinky image that had
a "fake" FMAP header at a 4-byte aligned offset.
Change-Id: I15873573a93f3926c70136679dccd626e5038614
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240750
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
And include it in vb2_api.h if VB20 internals are needed.
This allows coreboot to get at the fields more cleanly for now, rather
than duplicating the field definitions. In the long run, we should
have APIs for this rather than having coreboot peek at the bits
directly.
BUG=none
BRANCH=none
TEST=emerge-veyron_pinky coreboot && make -j runtests
Change-Id: Ic308c3470773b91191bf682ff1b3cfce8864d26a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240285
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This patch extends the vboot2 API by three callback functions that the
platform firmware may implement to offer hardware crypto engine support.
For now we only support this for hash algorithms, and we will only allow
it for firmware body hashes (not the keyblock or preamble which are too
small to matter execution-time-wise anyway). The API is similar to the
vb2api_*_hash() functions used to start body hashing in the first place,
but we still take this round trip through vboot to allow it to do
key/signature management and retain full control of the verification
process. We also add a new preamble flag to explicitly disable this
feature, so that we can later return to a solely software-based
verification path through a firmware update in case a hardware crypto
engine turns out to be insecure.
CQ-DEPEND=CL:236435
BRANCH=None
BUG=chrome-os-partner:32987
TEST='make runtests VBOOT2=1'. Manually booted on Pinky with and without
HW crypto support and with the preamble flag set to confirm expected
behavior. lib21/ parts untested except for compiling and new unit tests.
Change-Id: I17c7d02f392089875a5942a5aafcf6a657354863
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236453
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When vboot eliminates trivially small disks, it checks the GPT size for
external GPT disks. For upcoming NAND devices, the GPT size is 8kB. This
patch changes the definition of trivially small disks to be those under
8kB so that NAND can be booted from.
BUG=chromium:433433
TEST=make runalltests
TEST=Booted and saw a kernel from NAND selected on from an 8kB GPT.
BRANCH=none
Change-Id: I5047b9b642d564d5e4d77dd0b6dafb9eea09176a
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238463
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch makes some small modifications to cgpt and vboot to
root out the last vestigates of a fixed 128-entry GPT:
- Get rid of the TOTAL_ENTRIES_SIZE constant and all users.
- Reduce MAX_NUMBER_OF_ENTRIES to 128 (which is what the GPT
spec specifies) so that this can be used for things like memory
allocations without additional overhead.
- Base the amount of GPT read/written on the number of entries
specified in the GPT header on disk/flash.
BUG=chromium:433433
TEST=make runalltests
TEST=Modified fmap to make an 8k RW_GPT, wrote a GPT with cgpt, then
rebooted and found that the GPT was correctly read after restarting
and the appropriate mtd partitions were present.
BRANCH=none
Change-Id: I45317377da20259caf04a7a4fa077a892b03c45f
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238245
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Handle GBB_FLAG_DISABLE_LID_SHUTDOWN to disable lid-triggered system
shutdown.
BUG=chromium:434462
BRANCH=Auron
TEST=Manual on Auron, with corresponding depthcharge change. Set GBB
flag 0x1000 and disable powerd launch on boot. Close lid and issue
'reboot' command over ssh. Verify system reboots successfully into OS.
Change-Id: Id2731508296a5ba9229f969f8224565d64f3d4a3
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234995
Reviewed-by: Randall Spangler <rspangler@chromium.org>
As pointed out by Daniel in CL:234996, the half_size_sectors should have
been checked in both places.
This CL reworks that part of the code to read easier.
BUG=none
BRANCH=none
TEST=unittest
Change-Id: I8faea3b094c375e4fd1a604a8fe759af88943fdf
Reviewed-on: https://chromium-review.googlesource.com/235792
Reviewed-by: Daniel Ehrenberg <dehrenberg@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
This patch reinstates the external GPT support which was previously
committed and reverted. Improvements since last time include:
- Cleaned-up internal interface based on code review
- Function correctly on legacy bootloaders (e.g., depthcharge before
NAND-related patches are added)
- Better comments
- Treat new field values = 0 -> not use new feature
- Tests are added to ensure external GPT flag is passed down properly
The original commit had change-id
I5a77e417aea8ee9442d18c200d1b073aa5375ecf
Its commit message is reproduced below, and then an additional test.
----
To support an external GPT, disks have two new attributes:
- A binary flag indicating whether the GPT is in the same address
space as the payloads or a separate one.
- The number of sectors of the streaming portion of storage, as
opposed to the portion containing the GPT.
These have been added elsewhere to GptData (in cgptlib) and BlockDev
(in depthcharge). This patch adds the plumbing between those, including
in the DiskInfo interface between the firmware and vboot.
BUG=chromium:425677
BRANCH=none
TEST=Interactively wrote the GPT with cgpt and observed the following
boot with depthcharge to read the GPT from SPI and then read from
the proper locations in NAND flash.
TEST=make runalltests passes.
TEST=boots from USB with depthcharge from HEAD.
Change-Id: Ia7956517a7b9da0301f01fac5a10204f6d78cf4f
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234640
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The standard says that entries table must be at least 16384 bytes. On
some of our devices, the NOR section is only 8 KiB and used to store
both primary and secondary tables. On this device, we can only store 24
entries.
Therefore, this CL adds support for non-standard entry table. It adjusts
the MIN_NUMBER_OF_ENTRIES to 16, and replaces GPT_ENTRIES_SECTORS with
CalculateEntriesSectors.
BUG=chromium:441812
BRANCH=none
TEST=unittest
Change-Id: I6b85b35ce5612c7abb22142f8252bd0d45b676c5
Reviewed-on: https://chromium-review.googlesource.com/234996
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Over in depthcharge, IsEntryUnused will be useful for presenting the
partition table to the kernel. This patch moves that function to
gpt_misc.[ch] for export to depthcharge.
TEST=Booted a kernel on NAND with all this compiled in
TEST=make runtests passed
BRANCH=none
BUG=none
Signed-off-by: Dan Ehrenberg <dehrenberg@google.com>
Change-Id: I56445d1a420fec4d8385ddffc5469b7d77eab576
Reviewed-on: https://chromium-review.googlesource.com/231455
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Daniel Ehrenberg <dehrenberg@chromium.org>
Tested-by: Daniel Ehrenberg <dehrenberg@chromium.org>
- Rename drive_sectors to streaming_drive_sectors, to contrast with
gpt_drive_sectors
- Replace stored_on_device field with flags field for future
extensibility
BUG=chromium:433433
TEST=make runtests
BRANCH=none
Change-Id: I785a3b735b8eb96f647a334659329db3ee43eb80
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234283
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The dev_debug_vboot program can sometimes interfere with
automated firmware testing because it takes too long to read the
BIOS flash. Limiting the sections of flash that are read may
help, but in some cases skipping this program entirely may be
better.
This CL does three things:
1. dev_debug_vboot will read only some sections of the BIOS
flash, falling back to reading the whole thing only if it
fails at that.
2. dev_debug_vboot will source /etc/default/vboot_reference if it
exists. Putting DEV_DEBUG_FORCE=1 in that file will prevent
dev_debug_vboot from reading the flash at all unless it's
invoked with --force option.
3. The Makefile will create the /etc/default/vboot_reference file
in the install directory, setting DEV_DEBUG_FORCE to the value
in effect at build time. This will let a future CL change the
default behavior for each target.
BUG=chromium:438854
BRANCH=none
TEST=manual
Built and tested on Samus. /etc/default/vboot_reference was
present, containing "DEV_DEBUG_FORCE=". The dev_debug_vboot
script ran normally.
Manually changing /etc/default/vboot_reference to contain
"DEV_DEBUG_FORCE=1" and rebooting caused dev_debug_vboot to stop
before reading the BIOS flash.
I also manually forced various flashrom invocations to fail to
test each part of the new flow.
Change-Id: Ib319dd16b9026162d01f435f15570ec8ba99c512
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233228
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Now that lib20 and lib21 are distinct, they can have overlapping
struct names. This will be cleaner in the long run, since vboot 2.0
(lib20) is just a temporary stepping stone to vboot 2.1 (lib21). It
would be a shame to need to carry around the overhead of that extra
digit forever.
No functional changes, just a lot of renaming.
BUG=chromium:423882
BRANCH=none
TEST=make runtests && VBOOT2=1 make runtests (works with/withoug VBOOT2 flag)
And compile firmware for veyron_pinky
Change-Id: I25f348fd31e32d08ca576836dfdd1278828765a1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233183
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This is part 4 of a series of changes to rearrange the vboot2 library
so that it's possible to start using the new-style data structs. This
change moves knowledge of the old vboot1 data structs into lib20; 2lib
now contains only code which is common to both vboot2.x libraries
(that is, code which is data structure version agnostic).
No functional changes; just rearranging code and tests.
BUG=chromium:423882
BRANCH=none
TEST=make runtests && VBOOT2=1 make runtests (works with/withoug VBOOT2 flag)
And compile firmware for veyron_pinky
CQ-DEPEND=CL:233051
Change-Id: I8f9e67157575e5be14952ef4809c3dfafd92596d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233021
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is what other firmware should include. Other firmware must NOT
attempt to include headers from deeper inside the vboot2
implementation; that will likely break as vboot2 is refactored.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I63638b03bb108296fa5069e7cc32ee9e25183846
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233050
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When re-signing a kernel partition and writing the result into a
new file, make sure we only emit the vblock and kernel blob
instead of creating a new file that's the size of the entire
partition.
Also add a test for that.
BUG=chromium:418647
BRANCH=none
TEST=make runtests
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I2c42aec6816e7e7abbeed360089c9b51fdcfe786
Reviewed-on: https://chromium-review.googlesource.com/233039
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When modifying a kernel partition in-place, make sure we only
sign enough bytes to cover the kernel blob, not the entire
partition.
Also added a test for that case.
BUG=chromium:418647
BRANCH=none
TEST=make runtests
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Id89ff3845fe5178ee13f431d99868821fcad3248
Reviewed-on: https://chromium-review.googlesource.com/233038
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Code which compiles against fwlib2 no longer knows or cares about the
new data structures. This should shrink fwlib2 a bit. This is part 3
of 4 changes which split vboot 2.0 struct handling (old vboot1
structs) from vboot 2.1 struct handling (new style structs).
No functional changes; just shuffling around code.
BUG=chromium:423882
BRANCH=none
TEST=make runtests && VBOOT2=1 make runtests (works with/withoug VBOOT2 flag)
And compile firmware for veyron_pinky.
Change-Id: Ibccd7d1974e07f38b90c19c924ef3b1ffcb77d62
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233020
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
At one point I thought I'd be able to support both vboot1 and vboot2.1
data structures and dynamically determine which verification path to
run. But space limitations on current platforms (e.g. pinky) mean
that's not feasible. Remove this vestigal support, so that it's
easier to make a clean break to the new data structures on appropriate
platforms.
BUG=chromium:423882
BRANCH=none
TEST=make runtests && VBOOT2=1 make runtests (works with/withoug VBOOT2 flag)
And build firmware for veyron_pinky.
Change-Id: I9887e0c54114c475df81d5a2b701b9b52e95b017
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232979
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is part 1 of a series of 4 changes which rearrange the vboot2
files and unit tests so that we can more cleanly switch over from
old-style structs to new-style structs.
No functional changes, just shuffling around code.
BUG=chromium:423882
BRANCH=none
TEST=make runtests && VBOOT2=1 make runtests (works with/withoug VBOOT2 flag)
And build firmware for veyron_pinky.
Change-Id: I170d737bf151a6bafe61cde23b3d2f7a3fae43ce
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232978
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Signing is now simple enough (thanks to full utility lib support for
vboot2 data structs) that we don't need the vb2_convert_structs module
anymore. Also, use the utility lib function to create a firmware
preamble, rather than duplicating that code in the fwlib unit tests.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests, and build firmware for veyron_pinky
Change-Id: I1db402a08621f79274d2a69095aebc3e84f4328d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232755
Most importantly, make a vboot 2.0 utility library, rather than just
tossing all the vboot2 files into the main utility library. This will
allow creation of a vboot 2.1 library with overlapping symbol names.
BUG=chromium:423882
BRANCH=none
TEST=make runtests && VBOOT2=1 make runtests (works with/withoug VBOOT2 flag)
And build firmware for veyron_pinky.
Change-Id: I514bda18cb0fa62bbc507251219b02054c447f3c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232753
Also add vb2_common_desc() helper function to return the description
for an object starting with a common struct header.
And use the new host lib function to create the keyblock for verifying
the firmware lib.
Add tests for everything new.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I1fadb3e249e771a692cc69b23620c6ddd46a48ac
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231721
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This removes the hacky conversion from old-style packed keys and
signatures, which existed only because at the time we didn't have the
ability in hostlib to create new-format key and signature structs
directly.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Id7cb3dfce740f2546464a4caae2629af864d7b45
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231543
The cros-compiler doesn't support backtrace(3) when linked
statically. Until that's fixed, just don't use it.
BUG=chromium:437107
BRANCH=ToT, samus
TEST=manual
FEATURES=test emerge-link vboot_reference
/build/link/usr/bin/futility_s gbb_utility -c 100,100,100,100 test.bin
/build/link/usr/bin/futility_s gbb_utility -s --hwid=HEY test.bin
Change-Id: I66b76fc8c0aa92f95976c5d5015f62730bb12064
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232234
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Including signing with bare hashes, and signing an object with more
than one signature. With unit tests, even.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Iad0b9f9f6cca7129071aebf0cbc60c0daa94d382
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231452
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
And unit tests for them.
Move roundup32() into hostlib.
Fix WriteFile() returning success even if it failed to write to the file.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I8a115335c088dc5c66c88423d1ccbda7eaca1996
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/230844
This commit adds a new VbInit() flag which will indicate that it is
being called before option roms are loaded and can therefore respond
to the VbNv flag without needing an immediate reboot.
When the BIOS calls VbInit() in firmware it may not yet know if the
system is in developer mode if there is a virtual developer mode
switch, instead it relies on the VbNv flag that is prepared by VbInit().
So this new flag only affects VbInit() checks itself, the later checks
still do the right thing because OPROM_LOADED can be set based on the
VbNv value that is set by VbInit().
BUG=chrome-os-partner:32379
BRANCH=samus
TEST=pass FAFT tests on samus
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I7a12f3d318a04ff43ac1ddfc0ba8baa112253bad
Reviewed-on: https://chromium-review.googlesource.com/230885
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
