This patch shuffles around most of the detachable UI code to try to make
it more readable and maintainable. The goal is to get the business logic
out of the main UI loop functions as much as possible, and concentrate
the code handling each individual menu option in a single location.
This is a pure refactor and should not change behavior in any
(important) way. The adjustments to unit tests are only needed since the
old code displayed the same screen twice in certain circumstances, and
returning from the LANGUAGE menu to DEVELOPER selected the default
option Power Off, although other transitions to that screen select the
current default boot target.
BRANCH=None
BUG=None
TEST=make runtests, boot Scarlet and play with all screens.
Change-Id: Ibe05cbcb23c964d81f80de741bbd6f2231a2522d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/888082
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Shelley Chen <shchen@chromium.org>
This patch implements the new OPTIONS menu which will function in stead
of the old basic RECOVERY menu. The TO_DEV menu is now directly
reachable through the VolUp+VolDown key combo. Cancelling any menu or
changing USB state will immediately drop back to the menuless base
screens (INSERT or NOGOOD).
Also contains some minor clean-up here and there, like decoupling code
from tests a bit more by reducing reliance on global initializers. Code
for the now obsolete RECOVERY menu will be removed in a follow-up patch.
BUG=b:67371896, b:64400036
BRANCH=None
TEST=Go through all recovery screens, trry various back-and-forth
transitions between OPTIONS, LANGUAGE and TO_DEV, in addition to
inserting/removing USB at various times.
CQ-DEPEND=CL:884840
Change-Id: I95319778e14ce07fe2ada3edf95990560ac7081a
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/770258
Commit-Ready: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Now that vb2_shared_data / vb2_context provides all the same data to
lower-level kernel verification code that cparams did, stop passing
cparams down to those functions.
No change in functionality.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: I86eb1801ee96d8b56404b74843a8d09e3122567f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/852814
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The region API was a way for firmware and kernel verification to get
at various blocks of caller-provided data. In practice, we only used
it internally as a way to get at parts of the GBB. Prune it down to
access only the bits of GBB we still need, from the buffer we already
know we have.
In the long run we should use the same vb2ex_read_resource() API that
vb2 firmware verification does, but that should be done in a follow-up
CL since it'll need to be coordinated with support in depthcharge.
No change in functionality.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: I5715cb8d88274164a1a73ed4a56bbd93af46f9bf
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/852798
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Currently, firmware verification uses entirely vb2 structs, including
vb2_shared_data. This goes through an ugly translation to the old vb1
VbSharedData to pass it to depthcharge. The vboot kernel verification
maintains an equally ugly translation back to the vb2 struct
internally.
Eventually, we want to get rid of all that and use vb2 all the way
down to what crossystem picks up from the OS.
But before we can do that, we need to finish translating kernel
verification code to use the new vb2 structs. This is a step on that
path, using vb2_shared_data equivalents where present and hiding the
old vb1 shared data struct as a member of vb2_shared_data so at least
the vboot functions don't need to pass around cparams to get at it.
This will be followed by more CLs which convert more vboot internals
to use vb2 structs directly, and eventually coreboot/depthcharge CLs
which pass the vb2 structs from firmware verification directly to
kernel verification.
No change in functionality.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: I5df8ce81ba3c3ac3f2cb4229db5461757cd89d8d
Reviewed-on: https://chromium-review.googlesource.com/852856
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
All screens are now drawn by depthcharge. ToT firmware does not
include a bmpblk / bmpfv section in the GBB. Remove the code paths
which are no longer used.
Also drop a few cparams parameters from functions that no longer use
it, now that those functions don't need to access the GBB.
BUG=chromium:502066
BRANCH=none
TEST=make -j runtests; build bob firmware and check recovery screens
Change-Id: I4d2d0a3ba57c34151e65c6f42581df823192a4ae
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/852371
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Copy sync-related flags from cparams / vboot1 shared data to the
equivalent vboot2 structs. This removes the need for ec_sync to
access the old structs, which are on their way out.
No change in functionality.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: I50ee76cf275a7fba894c2ec2c3dd83b9a8d91b53
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/852489
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Previously, workbuf used was not rounded up to a multiple of
VB2_WORKBUF_ALIGN. The next allocation would be aligned, but not
until it was made.
Change this to round up used size when more workbuf is used. This
provides better predictability of where the next allocation will be
placed.
Uncovered this problem when I added a new member to vb2_shared_data
which changed its size so it wasn't a multiple of VB2_WORKBUF_ALIGN,
and the vb20 and vb21 unit tests which tried to simulate not enough
buffer broke in strange ways.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: I0157a1c96326f7fce6be6efbd74d90c3d2942268
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/852488
Reviewed-by: Shelley Chen <shchen@chromium.org>
Vboot firmware previously supported a rather complex audio looping
library. Our original intent was to allow developers to flash a
custom beep sequence / tune as an easter egg. We never fully
supported that, but the code to allow it lived on. Get rid of that.
Vboot also previously made no assumptions about the frequency of
VbExGetTimer(), which was only used by the vboot_audio library. So it
spent 10ms every boot measuring the frequency. Which is silly now,
because depthcharge implements that as a microsecond timer. Get rid
of that measurement and define the timer as a microsecond timer.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: I350246874fb36b00149423696285cfcaca0fc526
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/847311
Reviewed-by: Shelley Chen <shchen@chromium.org>
Vboot1 code directly referenced the GBB from cparams even though now
it has access to the GBB flags via the vb2 context. Refactor all
existing code to use the vb2 context, since that takes us one step
closer to getting rid of the old vboot1 cparams.
No change in functionality.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: Ic4a5bf215b723a2eacbf0a4cf0eba8b1338155a2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/847310
Reviewed-by: Shelley Chen <shchen@chromium.org>
Initial unit tests for detachable menu UI. With these tests, the
coverage is at 81.2% for lines for code and 87.5% for function
coverage. I will improve this to closer to 100%, but wanted to get
this in as it's still significantly better than before, which was 0%.
There are still a lot of tests in the code that are #if 0'd out
currently. I still need to go through an enabled/delete those.
BUG=b:65025540
BRANCH=None
TEST=run COV=1 make and make sure passes without errors
Change-Id: If17bfc24fb7f65deb3d2286cc39cdc311d8a6d93
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/830680
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Remove the old vboot1 vboot_nvstorage library (VbNv*() functions) and
use the vboot2 library (vb2_nv_*()) instead. This is needed in
preparation for moving to 64-byte records; no sense in implementing
that change twice...
Should be (better be) no change in system behavior.
BUG=chromium:789276
BRANCH=none
TEST=make runtests
compare output of crossystem before/after change (should be identical)
Change-Id: I10f9975b0824263064b9a74a3c6daadcecc085d3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/794732
This patch allows a power button on a keyboard to shut down the system
when waiting for a user interaction at a firmware screen. The firmware
menu, which is implemented by vboot_ui_menu, shouldn't be affected.
BUG=b:70244028
BRANCH=none
TEST=Verify power button on Fizz can shut down the system at recovery
screen, broken screen, todev scree, and user confirmation screen using
a USB keyboard and a servo. Verify recovery button can confirm dev mode
transition. Run 'make runmisctests' successfully.
Change-Id: Icc7d7a774da19acac3d2938d5748ad2323ba4856
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/811444
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Kernel verification will now roll forward the minimum allowable
version in the TPM no farther than the kernel_max_rollforward setting.
Note that CL:765573 changes chromeos-setgoodkernel so it always sets
kernel_max_rollforward to 0xfffffffe when marking a kernel as good.
That ensures that firmware with this setting will behave the same for
now as existing firmware.
BUG=chromium:783997
BRANCH=none
CQ-DEPEND=CL:765573
TEST=make runtests
Manual testing:
crossystem tpm_kernvel --> print current kernel version in TPM
- Resign the kernel with a higher version
- Reboot
- Wait a minute for chromeos-setgoodkernel to run
crossystem kernel_max_rollforward=0
- Reboot
crossystem tpm_kernvel --> has not changed
- Wait a minute for chromeos-setgoodkernel to run
crossystem kernel_max_rollforward -> 0xfffffffe
- Reboot
crossystem tpm_kernvel --> has changed to the higher version
Change-Id: Ia32ecb7fa4078548cd311541ccbe120570cf1bc5
Reviewed-on: https://chromium-review.googlesource.com/765574
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
This just adds the kernel_max_rollforward field to the nvstorage
libraries and crossystem. The firmware does not use it yet; that's
coming in a subsequent CL.
16 of the fields's 32 bits are taken from unused bytes of the kernel
field. This has no effect on existing usage.
BUG=chromium:783997
BRANCH=none
TEST=make runtests
Also manual testing. In a root shell:
crossystem kernel_max_rollforward --> Should default to 0
crossystem kernel_max_rollforward=0xfffffffe
crossystem kernel_max_rollforward --> Should be 0xfffffffe
(Note that setting it to 0xffffffff is indistinguishable from the
-1 value that the crossystem library uses to indicate error, so
0xffffffff isn't actually usable as a max rollforward limit. But
0xfffffffe is, and if we ever get so close to the limit that we
need to use 0xffffffff, something has already gone horribly wrong
with our versioning strategy...)
Change-Id: I008f412e6ed3c0b59beb9881268585af69d1ff2e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/765572
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch makes sign_official_build.sh resign ec.bin and store
signed RW copies in bios.bin if the original ec.bin contains
signed RW copies.
BUG=b:66956286
BRANCH=none
CQ-DEPEND=CL:738794,CL:*490792
TEST=sign_official_build.sh recovery recovery_image.bin \
~/trunk/src/platform/vboot_reference/tests/devkeys /tmp/out.bin
Change-Id: I73c7d8da7d8e2f770e5952d0124f8d43bb13e592
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/734295
CL:693008 changed check_ac_active so that we ask CR50 to verify EC
is in RO. While this is the right decision, on some platforms ECs
can't reset EC_IN_RW. This causes check_ec_active to set IN_RW
wrongly when EC is in RO after reboot.
This patch replaces VbExTrustEC with VbExEcRunningRW. If RW is
owned it may say it's in RO. Then, the software sync will proceed
and flash RW while the EC is running RW copy.
It also removes redundant checks for VbExTrustEC() when deciding
whether to allow developer mode to be enabled from the INSERT
screen. The INSERT screen can only be reached by manual recovery,
which resets the EC, we don't need to check again before going to
TODEV.
BUG=b:67976359
BRANCH=none
TEST=make runtests
Change-Id: Ide722146ca8683411dd9072a39387aa9531f6cfc
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/740878
Depthcharge currently asks EC whether recovery was requested manually
or not without verifying EC is in RO or not. If EC-RW is compromised,
recovery switch state can be spoofed.
This patch makes Depthcharge check EC_IN_RW to determine whether EC
is in RO or not. Only if it's in RO and it says recovery button was
pressed at boot, we proceed to the recovery process.
All other recovery requests including manual recovery requested by a
(compromised) host will end up with 'broken' screen.
BUG=b:66516882
BRANCH=none
TEST=Boot Fizz. make runtests.
Change-Id: I01d2df05fe22e79bbc949f5cb83db605147667b3
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/693008
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This change makes futility write out a EC_RW image to the filesystem.
It also allows the command to run without '--prikey' option. When a
private key isn't provided, the command copies the previous signature.
This can be used to extract EC_RW without changing the key or the
signature. Since data only mode doesn't have a previous signature,
the command returns error if '--prikey' isn't specified (as done
before).
BUG=b:65027647
BRANCH=none
TEST=Run futility as follows
futility sign --type rwsig ec.RW.flat ec.RW.sig (Missing key error, expected)
futility sign --type rwsig ec.bin (EC_RW.bin is produced)
futility sign --type rwsig EC_RW.bin
futility sign --type rwsig --prikey key.vbprik2 ec.RW.flat ec.RW.sig
futility sign --type rwsig --prikey key.vbprik2 ec.bin (EC_RW.bin is produced)
futility sign --type rwsig --prikey key.vbprik2 EC_RW.bin
make runfutiltests
Change-Id: I8c1e0cef147967cfd6d28aa7272b88c03e109e0d
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/647804
Reviewed-by: Randall Spangler <rspangler@chromium.org>
vb2_public_key_read_keyb cannot be used for VB2.1 public keys
(especially not for 2048 exponent 3 or F4, as their size is the
same so the algorithm cannot be guess).
Instead, do what futility/rwsig does and derive the public key from
the private RSA key.
BRANCH=none
BUG=b:64854892
TEST=make runlongtests
Change-Id: Ie81f40e6076cd0c234012b9af58e39425f8b717c
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/628177
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Caveh Jalali <caveh@google.com>
Add tpm_lite library support for the IFX specific TPM_FieldUpgrade
subcommand "FieldUpgradeInfoRequest2". Expose this via tpmc so it can
be used from shell scripts.
BRANCH=none
BUG=chromium:728130
TEST=Builds and tpmc ifxfieldupgradeinfo prints plausible results.
Change-Id: Ie58ebccef7fe90f7fca65d7cd9c78e1f16f9f29a
Reviewed-on: https://chromium-review.googlesource.com/562772
Commit-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
call VbExUpdateAuxFw() uncontidionally, instead of when we know we
need to do an update. Vb*AuxFw() already maintains state, so this
doesn't change when we (attempt) to update firmware.
however, this does allow us to iterate over all firmware drivers to
call their .protect() method. previously, we would only call
.protect() after an actual firmware update.
updated unit tests to match the new logic.
BRANCH=none
BUG=b:35585700
TEST=verified i2c tunnels are protected on reef using
ectool i2cprotect N status.
Change-Id: I9244db28ed181f568d117092307293202257735b
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/620281
Reviewed-by: Julius Werner <jwerner@chromium.org>
For detachables, the short delay is to fast to them to read/choose
options. Setting timeout to 30 seconds once user starts scrolling
through the menu. If no action is taken by the user, will retain
the short delay timeout.
BUG=b:63056097, b:35585623
BRANCH=None
TEST=reboot with gbb flag bit 1 enabled and ensure using short delay.
reboot and press volume button and make sure using long delay.
reboot and make sure short delay performed again upon reboot.
reboot and make sure gbb flag bit 1 = 0 and make sure long delay
still working as expected.
Change-Id: I31e3ca8aff6b29abca70ca9587deae7f6443d837
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/563817
Reviewed-by: Randall Spangler <rspangler@chromium.org>
this adds calls to depthcharge (using callbacks) to do auxiliary
firmware updates. in particular, this is intended to trigger TCPC
updates, but other programmables could also be updated.
no firmware updates take place until a board file has actually
registered a firmware update "driver". board file updates to follow.
TEST="COV=1 make" passes.
depthcharge boots on snappy.
with additional follow-on CLs, we can update the ps8751.
the companion depthcharge changes are here:
https://chromium-review.googlesource.com/c/498150/
the working design doc is here:
https://docs.google.com/a/google.com/document/d/1uzS0b3O3Us1QI2Sx7LDkjEfHmuhYB2BolrAoNwCVoc0/edit?usp=sharing
these features depend on vboot API updates:
CQ-DEPEND=CL:498150
BUG=b:35586896
BRANCH=none
Change-Id: If0d634eab08b429a8e7e80f5fe11eab3705bba0f
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/505260
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Replace commands using gbb_utility by the new 'gbb' futility command.
BRANCH=none
BUG=None
TEST=USE=test emerge-$BOARD vboot_reference
Change-Id: I8c1547d295a955373413482509a33964b0e0c06f
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/538442
Reviewed-by: Stefan Reinauer <reinauer@google.com>
This also adds the required tests (keys, testcases), and some
additional tests in vb2_rsa_utility_tests.c that were not
added when 2048-bit exponent 3 support was added.
BRANCH=none
BUG=chromium:684354
TEST=make runtests
Change-Id: I56d22302c2254ef500b9d2d290a79d8c8bc39942
Reviewed-on: https://chromium-review.googlesource.com/449060
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If an FMAP is detected in the rwsig image file, use it
to determine the location of:
- RW region
- RW signature
- public key in RO region
futility show uses that information to verify the signature,
and futility sign uses it is correctly resign the image,
and replace the public key a well.
This also adds tests for this use case. hammer_dev.bin sample
image uses huge RO public key and RW signature regions to make
sure all keys up to RSA-8192 can be used.
BRANCH=none
BUG=chrome-os-partner:62321
TEST=make -j
TEST=./build/futility/futility --debug show \
--pubkey hammer.vbpubk2 hammer.bin
TEST=./build/futility/futility --debug show hammer.bin
TEST=cp hammer.bin hammer.bin.orig
./build/futility/futility --debug sign \
--prikey hammer.vbprik2 hammer.bin
diff hammer.bin hammer.bin.orig => identical
TEST=openssl genrsa -3 -out hammer2.pem 2048
futility create --desc="Hammer 2nd key" hammer2.pem \
hammer2
./build/futility/futility --debug sign \
--version 2 --prikey hammer2.vbprik2 hammer.bin
These 2 commands succeed, but show different keys:
./build/futility/futility --debug show hammer.bin
./build/futility/futility --debug show hammer.bin.orig
TEST=make runtests
Change-Id: I2cebc421eaf97d1b92c9a58afc238d41487d0f6d
Reviewed-on: https://chromium-review.googlesource.com/445536
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This tests that futility can correctly create and verify rwsig images.
Note that we do not test RSA 8192, as the signature is longer than
1024 bytes, and the test logic would need to be changed.
BRANCH=none
BUG=chromium:684354
TEST=make runfutiltests
Change-Id: I690e59fe8fa3e273dd81176211c58e1677fa720f
Reviewed-on: https://chromium-review.googlesource.com/438950
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This calls gen_test_cases.sh in the proper environment.
Also, prevent gen_test_cases.sh from overriding test_file, to
provide stable signature (and avoid large git diff for no reason).
BRANCH=none
BUG=chromium:684354
TEST=make gentestcases -j8; git diff => no changes
Change-Id: I556285fd1a07a4d84f4ebd3fd7881ae06743716e
Reviewed-on: https://chromium-review.googlesource.com/439064
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The original VBDEBUG macro used doubly-nested parens to work with
MSVC, which didn't support varargs in macros. We now only use more
modern compilers, so replace it with the VB2_DEBUG macro and get rid
of the ugly and fragile double parens.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; build_packages --board=reef chromeos-firmware
Change-Id: Ifc0cb0733b14daaa1fde095fab7da4215a538c77
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/425133
Reviewed-by: Shelley Chen <shchen@chromium.org>
This cleans up the vboot functions which handle display so they don't
need to pass it around. Eventually, it'll be absorbed by vb2_context.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; build_packages --board=reef chromeos-firmware; boot reef
Change-Id: I58169dfd37abe657f9b9aa339cc72ffa398329e0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414288
Reviewed-by: Shelley Chen <shchen@chromium.org>
Previously, the EC software sync process called VbDisplayScreen() from
several function calls deep. Refactor software sync so that the UI
decisions are at a higher level (in ec_sync_all.c) and isolated from
the low-level EC software sync functionality (in ec_sync.c).
This is one in a series of changes which are more clearly separating
out the UI, to make it easier to support multiple UI across a range of
devices.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; build_packages --board=reef chromeos-firmware; boot reef
Change-Id: I40597abeb5b0cc8f5d8fc2098e4acbed4bf59bf6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/411921
Reviewed-by: Shelley Chen <shchen@chromium.org>
Passing the vb2 context around allows using more of the vb2 functions in
future changes, and prepares for a future where we directly use the
context as it was set up in firmware verification.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I8efa606dbdec5d195b66eb899e76fdc84337ad36
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404997
Reviewed-by: Shelley Chen <shchen@chromium.org>
This was previously done inside vboot_api_kernel. But it has nothing to
do with kernel verification; that's just the only place where we could
easily put it given that vboot (currently) owns the firmware UI.
No outwardly-visible functionality changes.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I8a434eb4449a5a86b129ecac61ad81d0ad55549c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404920
Now that LoadKernel() uses a stream API for its partition data, it
doesn't care about those fields. They're blindly passed to
cgptlib_internal, which does similar checks in CheckParameters() and
CheckHeader(). So, don't duplicate the checks.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I72375496e5df7b7c17df25d358f2555fe41fe520
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/407053
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
LoadKernel() was a big function which did everything from looping over
partitions on a drive to loading the data within them to calling the
low-level verification functions on that data. Split it apart into more
manageable chunks. This also reduces indentation of the inner parts of
the code, whic increases readability.
No outwardly-visible functionality changes.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: Iea79e70163f5d9f1a9d0d897e4a9bacc925a742d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404919
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This new recovery reason will instruct the calling firmware in
vboot_select_and_load_kernel to reboot the device (under the assumption
that training of memory has already been performed by the firmware). On
seeing the return code VBERROR_REBOOT_REQUESTED, calling firmware should
perform a reboot.
BUG=chrome-os-partner:59352
BRANCH=None
TEST=make -j runtests successful
Change-Id: I110a735e612665cb2378bd71ca01a111edaf58e3
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/407656
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously, vb2_unpack_key() actually unpacked a key buffer. Callers
that had a vb2_packed_key had to typecast it back to a uint8_t buffer to
unpack it. Rename vb2_unpack_key() to vb2_unpack_key_buffer(), and make
vb2_unpack_key() unpack a vb2_packed_key.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge;
emerge-samus and boot it
Change-Id: I9ee38a819c59cc58a72ead78cf5ddf3d0f301ae7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400906
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Originally, vboot1 code used VbExMalloc() and VbExFree() since it needed
to talk to EFI firmware that didn't have standard malloc() and free().
Now, coreboot and depthcharge implement them as wrappers around those
standard calls. vboot2 code already calls them directly, so let vboot1
code do that too.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I49ad0e32e38d278dc3589bfaf494bcf0e4b0a4bd
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400905
Now that the vboot1 cryptolib code is gone, nothing uses stateful_util.
Remove it and its unit tests.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I75b6014be00c5266545db10e87c1d9485fd1444b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400904
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
At this point, all that's left are a few constants in the cryptolib
header files, and they're only used by host-side code. So move them to
a host-side header file and get rid of cryptolib.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I2235f0e84e13fef313afe54e749b73744b157884
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400903
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
The old vboot1 cryptolib hard-coded many of its padding arrays in a
padding.c file. Use the equivalent vboot2 apis instead.
This change is almost exclusively on the host and test side; the only
firmware impact is on a single line of debug output.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: If689ffd92f0255847bea2424950da4547b2c0df3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400902
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
