This replaces all calls to vboot1 VerifyFirmwarePreamble() with
equivalent vb2.0 functions. No effect on ToT firmware, which already
uses the vboot2.0 functions.
BUG=chromium:611535
BRANCH=none
TEST=make runtests
Change-Id: I5c84e9ed0e0c75e2ea8dbd9bfcde0597bc457f24
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/349322
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Futility needs to link against both vboot1/vboot2.0 and vboot2.1
functions. This was easy in the past because it did (vboot1 +
vboot2.1) and there's no overlap.
In replacing vboot1 function calls and structs with vboot2.0, now there
are symbol collisions between vboot2.0 and vboot2.1. For example, both
of them use a struct called vb2_signature, but the structs are defined
differently. Functions which operate on those structs also overload.
Rename the vb2.1 structs to start with vb21_ instead of vb2_. Do the
same for vb2.1 functions which operate on vb2.1 data.
BUG=chromium:611535
BRANCH=none
TEST=make runtests
Change-Id: I24defd87cbd9ef64239faf1a8e98ab2372d27539
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347458
Reviewed-by: Daisuke Nojiri <dnojiri@google.com>
Looks like the DISABLE_FW_ROLLBACK_CHECK GBB flag (0x200) was forgotten
in the vboot2 implementation. It's too late for Veyron now, but let's at
least fix it for future devices.
BRANCH=none
BUG=None
TEST=make runtests
Change-Id: I867f7aada28be3897efda73a6bdc3b0848c23dca
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/271419
Reviewed-by: Bill Richardson <wfrichar@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>
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>
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>
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>
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>
