We want a quick and human-friendly way to match keys with
signatures, so we decided to give each key a unique GUID and
carry that ID around when signing things.
But then we realized that we could autogenerate a unique
identifier from the .pem file itself, which is even better
because then we can match our binary keypair structs with the
openssl file used to generate them.
This change replaces the GUID id with a sha1sum calculated from
the public key's "keyb" blob.
BUG=none
BRANCH=none
TEST=make runtests
Also:
futility show tests/testkeys/key_rsa4096.pem
futility create tests/testkeys/key_rsa4096.pem foo
futility show foo.vbp*
Note that the GUID is the same for all files.
Change-Id: Ie44e46c83433718b1ff0163c1e7c51ec331b99f9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256181
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This command reads a single .pem file and emits the public and
private keys generated from it. It can produce both the old-style
vboot 1.0 keys (.vbpubk and .vbprivk), or the new vboot 2.1
format keys (.vbpubk2 and .vbprik2). The default is the new
format, but you can give futility the --vb1 arg to force the old
format.
A test is included.
BUG=chromium:231547
BRANCH=ToT
TEST=make runtests
Change-Id: I4713dc5bf34151052870f88ba52ddccf9d4dab50
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246766
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Kernel preamble flags are set by the signer for passing hints about
the image. Read these flags from the preamble and pass it back to the
caller in kparams structure.
BUG=chrome-os-partner:35861
BRANCH=None
TEST=Compiles and boots to kernel prompt for both CrOS image and bootimg.
Change-Id: I07a8b974dcf3ab5cd93d26a752c989d268c8da99
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/245951
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
1. Increase kernel preamble revision from 2.1 to 2.2.
2. Add flags field to kernel preamble.
3. Update futility to accept flags parameter for vbutil_kernel and
cmd_sign for kernel.
4. Pass in an extra flags field to SignKernelBlob and
CreateKernelPreamble.
BUG=chrome-os-partner:35861
BRANCH=None
TEST=1) "make runalltests" completes successfully. 2) vboot_reference
compiles successfully for ryu. 3) Verified flags field in header using
futility show.
Change-Id: If9f06f98778a7339194c77090cbef4807d5e34e2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/245950
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
vboot1 kept track of an internal "LoadFirmware() check" value for both
firmware slots and encoded the value for the slot that managed to go
further in the verification flow into a special range of recovery
reasons. vboot2 instead uses the generic "invalid RW" reason for all
firmware verification failures and communicates further information
through the subcode.
While the subcode may be good enough for developers, it's difficult to
communicate failure reasons to "normal" users (like non-firmware
developers) on the TAB screen. Currently we just display a couple of
numbers that people won't know how to interpret and "RW firmware failed
signature check" for any verification error (including rollback, which
might be the most commonly encountered in practice).
Since our recovery reason space is big enough (and we don't reuse old
numbers anyway), we might as well reuse the more precise numbers (and
strings) from vboot1 to communicate the failure reason, even if we don't
implement its "which slot came further" algorithm. This patch translates
the most common/useful VBSD_LF_CHECK numbers into plain VB2_RECOVERY
reasons and uses them where appropriate.
CQ-DEPEND=CL:248400
BRANCH=veyron
BUG=None
TEST=make runtests VBOOT2=1
test_that my_jerry firmware_CorruptBothFwSigAB
firmware_CorruptBothFwBodyAB firmware_RollbackFirmware
(Confirmed that matched recovery reasons are the more precise ones in
the 0x10-0x1F range.)
Change-Id: I51ecf1b820d1faa40405cb84377380d6f3f6ca1d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248392
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
vboot2 added a few new recovery reasons (and abolished many old ones).
In the current vboot2/vboot1 hybrid architecture used on Veyron, the
vboot1 kernel verification part controls the status display when
pressing the TAB key, which may try to show recovery reasons set by the
vboot2 firmware verification part. These currently result in the not
very helpful "We have no idea what this means", so lets hack a few more
strings into vboot1 which will be otherwise harmless. Also add the
recovery_subcode field to the display, which is used much more
extensively by vboot2 and often very useful in firguring out what really
went wrong.
BRANCH=veyron
BUG=None
TEST=Manually set a few recovery reasons and subcodes through crossystem
and made sure they get displayed correctly on my Jerry.
Change-Id: I3f3e6c6ae6e7981337841c0c5e3cd767628472c3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248391
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The length of the signature is 8 bytes. We've been checking 9
bytes instead, pretty much forever. All the tests have passed
because although the signature we're looking for is an 8-byte
string followed by a '\0', the next field in the header contains
the revision number 0x00010000, so the 9th byte is always zero.
We should follow the spec, though.
BUG=none
BRANCH=none
TEST=make runtests
Change-Id: I7cc6370250fa36a193f4a9fa5bc0099aea465618
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247331
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch adds a check to vboot2 secdata accessor functions that
returns an error if vb2_secdata_init() has not yet been called or
failed for some reason. This avoids a problem where vboot may
misinterpret random garbage (e.g. from transient read failures) as
valid secdata in recovery mode and write it back to the TPM (bricking
the device in a way that requires manual repair).
Also removes VB2_ERROR_SECDATA_VERSION check. This check was not
terribly useful since there should be no way a vboot2 device could ever
have secdata version 1 (and if it did, it should still fail CRC checks).
This error can trigger for cases when secdata contains random garbage
(e.g. all zeroes) and prevent the much more appropriate
VB2_ERROR_SECDATA_CRC error from even being checked for, which just
creates confusion and makes it harder to determine the real problem.
BRANCH=veyron
BUG=chrome-os-partner:34871
TEST=Emulated TPM read errors by just manually memset()ing secdata to 0
in coreboot, verified that vboot does not write back to the TPM and the
device will start working fine again once the disruption is removed.
Change-Id: I76bcbdbcd8106a0d34717cc91a8f2d7cda303c3f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244846
This patchs adds a new vb2_shared_data field to store the current
rollback prevention version number stored in secdata (TPM). This
information needs to be retrieved from there by coreboot (current
hack) or vboot2 kernel verification (bright shiny future) so it can be
passed along to the operating system and user space.
BRANCH=veyron
BUG=chrome-os-partner:35941
TEST=make runtests. Booted Jerry in recovery mode (with corresponding
coreboot patch), ensured that crossystem tpm_fwver still shows the
correct value.
Change-Id: I2a0c3e51b158a35ac129d2abce19b40c6c6381a6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244601
Reviewed-by: Randall Spangler <rspangler@chromium.org>
this api allows firmware to get the digest indicating boot mode status.
BUG=chromium:451609
TEST=VBOOT2=1 make run2tests
BRANCH=tot
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Idca7bc5f6aed947689ad7cf219805aad35047c7d
Reviewed-on: https://chromium-review.googlesource.com/244542
This accurately reflects what's really happening. Vboot 2.0 is
backwards-compatible with the binary structs used in vboot 1.0,
while vboot 2.1 will not be.
When building firmware, vboot_reference should be invoked in one
of three ways:
TARGET OUTPUT VERSION
fwlib vboot_fw.a 1.0
fwlib20 vboot_fw20.a 2.0
fwlib21 vboot_fw21.a 2.1
BUG=chromium:228932
BRANCH=ToT
CQ-DEPEND=CL:243981
TEST=manual
emerge-veyron_pinky coreboot
emerge-samus coreboot
emerge-daisy_spring chromeos-u-boot
make runtests
Change-Id: I98d8ea6b48e5922a470e744d56699cad43eabb3d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243980
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We were assuming 8-byte alignment for buffers. That's not true on
32-bit architectures. We should make the alignment requirements
explicit (and correct) for all architectures.
BUG=chromium:452179
BRANCH=ToT
CQ-DEPEND=CL:243380
TEST=manual
USE=vboot2 FEATURES=test emerge-x86-alex vboot_reference
Change-Id: I120f23e9c5312d7c21ff9ebb6eea2bac1e430e37
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243362
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
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>
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>
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>
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>
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>
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>
This adds a GBB flag which can be used in VbExShutdownRequested
to ignore the state of the lid switch and enable factory to run
with the lid closed.
BUG=chromium:434462
BRANCH=samus
TEST=none in this commit, just adding a new unused flag
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ife93adcc90b2c48e79d4e0c8164d2e64e6326ca7
Reviewed-on: https://chromium-review.googlesource.com/230884
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This reverts commit 5040a945df.
This patch breaks booting any image (both fixed and
removable) on Veyron_Pinky (and presumably every other
non-NAND board?). By the power vested in me through the
office of ChromeOS tree sheriff (well, five hours early
but whatever) it is hereby reverted!
BUG=chromium:425677
BRANCH=none
TEST=Can successfully boot on Veyron_Pinky again.
Change-Id: I9323a3d5e34491337fc7eb09dd00d845ac42997d
Reviewed-on: https://chromium-review.googlesource.com/229963
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
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.
make runalltests passes.
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Change-Id: I5a77e417aea8ee9442d18c200d1b073aa5375ecf
Reviewed-on: https://chromium-review.googlesource.com/228943
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
And associated unit tests.
And fix a memory overwrite in the old vb_api_tests.c, which apparently
didn't touch a critical piece of the shared work buffer, but was still
wrong. (This was a problem in the test, not in the code being
tested.)
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I322fb7e6bb5214b0adcf5d6d48a0cd238abba88e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229738
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This allows the api header to include it without pulling in the rest
of the vboot2 internal structs.
No functional changes; just moving a struct definition.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Ife9408f9b597939a3cc85a10d534108e12f2d739
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229793
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Previously, "cgpt" called out to "flashrom" directly to read and write
NOR area. This CL removes that dependency and always treats "drive_path"
as the storage of GPT structs. This makes it consistent that whatever
device that cgpt reads from or writes to is always the device that
stores GPT structs. We only need to pass in the size of the drive that
contains the partitions, but we do not need to access to that drive.
More information is in the bug.
BUG=chromium:432611
BRANCH=none
TEST=unittest
CQ-DEPEND=CL:228942
Change-Id: Id0139adf70463cec4f2924de8b9a4725dbec822b
Reviewed-on: https://chromium-review.googlesource.com/229736
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Previously, my_lba of the secondary GPT was recorded as if that
GPT was written at the end of the device. This patch tweaks
my_lba to report where it is in the random-access GPT address space,
namely at the end of that space.
TEST=Compiled it into the firmware and observed the firmware to update
the my_lba field of the secondary GPT.
BRANCH=none
BUG=chromium:425677
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Change-Id: I88791fb2cff1086351ca8a3adeef675c4a88cc9a
Reviewed-on: https://chromium-review.googlesource.com/228942
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Daniel Ehrenberg <dehrenberg@chromium.org>
Tested-by: Daniel Ehrenberg <dehrenberg@chromium.org>
