Generated with the following commands.
$ mkdir tests/devkeys/uefi
$ ./scripts/keygeneration/uefi/create_new_uefi_keys.sh tests/devkeys/uefi lakitu
$ rm -f tests/devkeys/uefi/{pk,kek,db,dbx}/*.rsa
BUG=b:62189155
TEST=See the following commit.
BRANCH=none
Change-Id: I996081c30fbfa89d07dba9252128dc214530e71f
Reviewed-on: https://chromium-review.googlesource.com/994179
Commit-Ready: Edward Jee <edjee@google.com>
Tested-by: Edward Jee <edjee@google.com>
Reviewed-by: Jason Clinton <jclinton@chromium.org>
The new TlclGetSpaceInfo function returns more detailed information
about a defined NVRAM space. The existing TlclGetPermissions function
is now using TlclGetSpaceInfo behind the scenes.
BRANCH=None
BUG=chromium:788719
TEST=New unit tests.
Change-Id: I6c4f490d575788b696fd742a69e81e2767ec50f1
Reviewed-on: https://chromium-review.googlesource.com/937705
Trybot-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Adds two new functions and their corresponding TPM commands to create
delegation families and list the delegation family table, respectively.
This isn't sufficient to meaningfully manage delegation families, but good
enough for the (ab)use case of storing flags in delegation family labels, which
we are going to do in order to strengthen encrypted stateful to guarantee
recreation of the encrypted file system after TPM clear..
BRANCH=None
BUG=chromium:788719
TEST=new unit tests
Change-Id: I31beb662784a8fff450b485c7cabc553944d7772
Reviewed-on: https://chromium-review.googlesource.com/817199
Trybot-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Add the ability to take TPM ownership. This requires two new commands:
TPM_OIAP to start an auth session and TPM_TakeOwnership to establish
ownership. TPM_TakeOwnership requires an auth session and proper
command authentication to work, which is also added.
BRANCH=None
BUG=chromium:788719
TEST=new unit tests
Change-Id: Ib70144eedb0b1c7c43b26c06529d33ccbaa51a0e
Reviewed-on: https://chromium-review.googlesource.com/790414
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Trybot-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Trybot-Ready: Mattias Nissler <mnissler@chromium.org>
Remove 512 sector block size restriction so that UFS, with sector block size 4096
or greater, can be used. The sector block size is queried from the kernel with
ioctl(BLKSSZGET) or queried from depthcharge with VbExDiskGetInfo().
BUG=b:77540192
BRANCH=none
TEST=manual
make runtests passed.
Tested firmware on Kevin and boot to kernel from disk.
Executed cgpt show /dev/mmcblk0 on eve device and verified output was correct.
Should be tested on device with sector block size greater than 512.
Change-Id: I8165c8ee4da68180eecc8d12b3fb501cc5c60a5d
Reviewed-on: https://chromium-review.googlesource.com/1007498
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
If an aux firmware update fails enter recovery with a specific
reason code so we can identify systems that fail.
Also handle the case where the update succeeds and requests a
cold reset of the EC, first clearing the oprom flag if
necessary in order to prevent a second reset.
Unit test was added to check recovery reason for aux firmware
update failure.
BUG=b:74336712
BRANCH=eve
TEST=manual: force update to fail and ensure it goes to recovery
mode, and after successful update check that the option rom flag
is cleared before the EC reset happens.
Unit tests udpated and 'make runtests' passes.
Change-Id: I35a93892a0f8bb16eac0925ada5dfbc5c3144f8d
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/959671
Reviewed-by: Caveh Jalali <caveh@google.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
It seems like there are some testing use cases where we want the device
to boot into the recovery installer but it is impractical to fully
simulate a user-triggered recovery. This has become impossible with the
recent change to always require manual recovery to boot an image, even
when the developer mode switch is enabled (CL:924458).
This patch adds a new GBB flag to support this use case. When the flag
is set, all recovery mode is manual recovery mode, regardless of wheter
the developer mode switch is on or not.
Since the GBB_FLAG_ENABLE_SERIAL was killed off before it ever really
worked anyway, we can safely reuse the bit reserved for it.
BRANCH=None
BUG=None
TEST=make runtests, manually confirmed on Kevin
Change-Id: I4f51dfd20b4ff04c522f53596896dccbceee52dc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/976660
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The calling firmware can set ctx->flags VB2_CONTEXT_NVDATA_V2 to tell
vboot that nvdata is a 64-byte record instead of a 16-byte record, or
equivalently, set the VBSD_NVDATA_V2 flag if calling the old vboot1
API.
If calling firmware does not (which is the current coreboot and
depthcharge default), then the 16-byte record is used, and V2 fields
return explicit default values.
Added the fw_max_rollforward V2 field, which defaults to 0xfffffffe on
V1. This will be used by a subsequent CL.
Added unit tests to verify all that.
Added crossystem support, though it will only work with the current
16-byte records until firmware sets the VBSD flag and mosys supports
larger records.
(Note that because coreboot/depthcharge do not yet set the new context
flag, this CL should not change ToT firmware behavior.)
See go/vboot-nvstorage for design doc.
BUG=chromium:789276
BRANCH=none
TEST=make runtests
Change-Id: I43072ef153dfa016c051f560892af1fbb3508e3a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/942031
This was deprecated months ago in crossystem, and isn't set by
depthcharge or coreboot. Remove the flag from vboot as well, keeping
only a reminder in vboot_struct.h so we don't reuse the VbSharedData
bit.
BUG=chromium:742685
BRANCH=none
TEST=make runtests
Change-Id: Ifa928e8ec4d999c524c6f4168695859261f384c9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/947256
Reviewed-by: Julius Werner <jwerner@chromium.org>
VbLockDevice() would be inconvenient to port to 64-byte NV storage
records because it doesn't take VbSharedData flags or a vb2_context.
So, just have depthcharge call vbnv_write() directly (as it does in
other places in fastboot.c) and get rid of this API.
BUG=chromium:789276
BRANCH=none
TEST=make runtests
CQ-DEPEND=CL:944183
Change-Id: I2aeaecf7f929cd1a1ebd1f6850d0dd96c6fabb49
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/944243
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Currently, ec.bin generated by cros_sdk contains and is signed by the
dev keys in the platform/ec/<board> directory. This patch copies these
dev keys to vboot_reference.
BUG=b:73249665
BRANCH=none
TEST=make runtests
Change-Id: Id2a0b16dc6d404a6bea902fd5a401d6fc7caa2bf
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/940665
Reviewed-by: Wai-Hong Tam <waihong@google.com>
Previously, non-manual recovery behavior would depend on the developer
mode switch: in normal mode it would get stuck at the BROKEN screen, but
in developer mode it would proceed exactly like manual recovery. This
behavior was mostly just confusing to people and it seems that we have
no real use case for it anymore. Remove the developer mode special case
so that non-manual recovery will always go to the BROKEN screen from now
on.
BRANCH=scarlet?
BUG=None
TEST=make runtests, verified manually on Scarlet and Kevin
Change-Id: Iaf33f82d7cb709a5ee309c08d1ad3015859738b3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/924458
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Since we're continuing to support the boot shortcuts Ctrl+D, Ctrl+U and
Ctrl+L, it makes sense to also continue to support the debug info
shortcut Tab, just in case somebody may want to use it from an external
keyboard. This does not affect the existing method to display debug info
through the appropriate menu option in any way.
BRANCH=None
BUG=b:73080278
TEST=make runtests, booted Scarlet and pressed Tab on UART.
Change-Id: Ia08404e0ffd1f8cac3d85f3b2fc4ce17a21d743d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/907759
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
When switching from normal to dev mode, the EC is in RO. AP requests
warm reboot, whic causes EC to jump to RW. After sysjump, RW tries to
renegotiate PD but it's too late for type-c monitor to function
because VBIOS has already run.
This patch makes AP request EC reboot when switching to dev mode.
BUG=b:73083750
BRANCH=none
TEST=Dingdong connected to Teemo. Verify norm-to-dev screen is
displayed. make -j runtests.
Change-Id: I763cd6968406f7b904604b2588a9db6d567cbd4e
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/907734
Some of the defined screens have never been used or we've stopped using
them a while ago. Remove the respective constants to make it clearer
that callers of the library are not expected to handle them.
CQ-DEPEND=CL:903362
BRANCH=None
BUG=None
TEST=make runtests
Change-Id: I82308fc76dc10b2c8b408af7a15a819120043632
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/902899
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Bit 0 in the GPT partition attributes is defined to indicate whether a
partition is required by the platform. This CL adds the support for
managing this bit to cgpt.
BUG=b:70807006
BRANCH=None
TEST=Run unit tests.
Change-Id: Iaf87c828438b3df6730de502ae420fcf4c61277b
Reviewed-on: https://chromium-review.googlesource.com/902196
Commit-Ready: Ben Chan <benchan@chromium.org>
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
This patch adds a bunch of new unit tests for the detachable UI and
enhances some of the existing ones to more explicitly check more things.
BRANCH=None
BUG=b:65025540
TEST=make runtests. I actually found a real bug in my previous patch, so
that's nice... and COV=1 make gives me 96.9% of lines covered in
vboot_ui_menu.c, with 28 out of 28 functions touched.
Change-Id: I7737a7e62d4b7e01ea98e6a0f1dd098716582794
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/894292
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>
