When a TPM goes from the disabled state to the enabled state, it must
reboot after being enabled, before it can be initialized. In vboot1,
TLCL was part of vboot and this was handled internally. In vboot2, the
caller must set a context flag, so that vboot can decide whether to
allow the reboot, or whether to go directly to recovery mode. This
check is necessary to handle the following cases:
1) The device is booting normally, but the TPM needs a reboot. This
should simply reboot, without going to recovery mode.
2) The device is booting in recovery mode, but the TPM needs a reboot.
If this is the first time it asked us, allow the reboot.
3) The TPM asked for a reboot last time, so we did. And it's still
asking. Don't reboot, because that runs the risk that whatever is wrong
won't be fixed next boot either, and we'll get stuck in a reboot loop
that will prevent recovery. Boot into recovery mode.
Add a new NvStorage bit to track whether the TPM requested a reboot on
the previous boot. That's better than what we did in vboot1, where we
used a special recovery request. Vboot1 couldn't track getting stuck in
a reboot loop in normal mode, only in recovery mode. The new code can
catch both.
BUG=chrome-os-partner:45462
BRANCH=ryu
TEST=make runtests
Change-Id: I2ee54af107275ccf64a6cb41132b7a0fc02bb983
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/300572
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This allows the caller to load the kernel partition and then pass it
to vboot for verification, rather than having vboot assume the kernel
partitions are all on a block storage device.
Next up, APIs for the caller to parse partition information from a GPT
(yes, that's cgptlib, but we'll make it more easily callable by
depthcharge).
BUG=chromium:487699
BRANCH=none
TEST=make -j runtests
Change-Id: I388085c7023f4c76d416f37df0607019bea844ac
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/275646
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
When the lid is closed and external power is applied
the system may boot and shut down faster than required
for the OS to determine that things were alright.
In timed charging setups this led to systems ending up
to consider the current version broken because it "failed"
repeatedly.
Remain generic about the reason for not counting boots
since there may be more situations in which we want to
handle the situation optimistically.
BRANCH=none
BUG=chromium:446945
TEST=none
Change-Id: Iea350e3c98d5c00156da682e52c90a882ba017c0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249150
Reviewed-by: Randall Spangler <rspangler@chromium.org>
These are slightly more complex than the firmware versions, because
they need to deal with developer-signed keyblocks and keyblock flags.
BUG=chromium:487699
BRANCH=none
TEST=make -j runtests
Change-Id: I682c14ddfe729984f2629dfbe66750e5cd5ab75e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/272541
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
If so desired by the firmware, disable developer mode each time the
recovery mode is entered.
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=with the rest of the patches applied observed desired behavior on
an SP5 (developer mode state wiped out on entering recovery)
Change-Id: If08dc517363bcc36fcc8b0b875a8700bbcefde4c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/261630
Reviewed-by: Randall Spangler <rspangler@chromium.org>
It has become necessary to be able to "factory reset" certain devices
on firmware request. The best mechanism for this is NVRAM, as the
request needs to be detected very early in the boot process, before
other means of communications with the upper layers are available.
A previously unused NVRAM bit (bit 0x08 at offset zero) is taken for
this purpose.
A new flag is introduced to allow the firmware to signal the need to
assert this bit.
A new variable name/parameter ('wipeout_request') added to crossystem
to provide user space access to the setting of the dedicated NVRAM
bit.
BRANCH=storm
BUG=chrome-os-partner:37219
TEST=with all the patches applied, on storm, holding the recovery
button at startup for 10 seconds, causes 'crossystem
wipeout_request' to report '1'.
Change-Id: If1f6f061ce5b3f357b92aaa74cb129671dc30446
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/259857
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
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
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>
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>
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>
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>
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>
I'm breaking the last chunk of vboot2 into smaller pieces as I add
tests. This has the api-level routines actually called by depthcharge.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: Ic7c082fc5faa0b874b2fa5a15ebda7135dcafe0b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200151
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
I'm breaking the last chunk of vboot2 into smaller pieces as I add
tests. This has a bunch of misc routines like the dev switch logic
and GBB header parsing.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: I0f67400d9b59ec21ed5cc155a9b774fd37eb559b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203374
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is the second of several CLs adding a more memory- and
code-efficient firmware verification library.
BUG=chromium:370082
BRANCH=none
TEST=make clean && COV=1 make
Change-Id: I1dd571e7511bff18469707d5a2e90068e68e0d6f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199841
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
