All new-style structs have a common header. This adds a verification
function for that common header, and tests for it.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I668486e77f7200c10b43aa2d17b4dd6639e5538e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225459
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
For kernel NAND support, some vboot/cgptlib functionality is
needed from depthcharge. This patch moves certain function
declarations to a new header in firmware/include and puts
their definitions in a common place.
TEST=make runalltests passes and packages build
BRANCH=none
BUG=chromium:403432
Change-Id: Idd42b1f9f531651d78bb4afb80ca90c24aae93d9
Reviewed-on: https://chromium-review.googlesource.com/224996
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Daniel Ehrenberg <dehrenberg@chromium.org>
Tested-by: Daniel Ehrenberg <dehrenberg@chromium.org>
Move packed key functions to their own file, in preparation for
introducing support for vb2_packed_key2.
Rename the awfully-named vb2_verify_fw_preamble2() function to
vb2_load_fw_premable(), since the new structs actually have a
vb2_fw_preamble2 struct and that would be very confusing.
Rename vb2_verify_fw_keyblock() to vb2_load_fw_keyblock(), so it
matches.
No functional changes, just renaming.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Ia914e48e6c5814ab3205b999ceda1aa2452206ff
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225458
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This changes the internals of vboot2 to use the enumerated type for
signature algorithm. The conversion from crypto algorithm is done
only when unpacking the key. This is preparation for the vboot2 data
types, which separate signature and hash algorithms into their own
fields.
There is no external change in the calling API to vboot, and no change
to the external data structures.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I2e176d186d88cc7541644e001e720b4aee456be0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225209
This changes the internals of vboot2 to use the enumerated type for
hash algorithm. The conversion from crypto algorithm is done only
when unpacking the key (and ok, in checking the rsa padding, but that
goes away in the next change). This is preparation for the vboot2
data types, which separate signature and hash algorithms into their
own fields.
There is no external change in the calling API to vboot, and no change
to the external data structures.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I9c6de08d742dab941beb806fbd2bfc1e11c01e2c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225208
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Looks like vboot2 currently never outputs the current recovery reason
anywhere, which is annoying for debugging devices without working
display (where you could press TAB). This patch adds log messages both
when deciding to go into recovery mode and when picking up an existing
recovery request from NVRAM, for maximum visibility.
Also removes the "Both slots are bad." part of the vb2_fail() message,
since this is not necessarily true and can be confusing (there are many
other possible reasons why it might want to go into recovery).
BRANCH=ToT
BUG=None
TEST=Manual
Change-Id: Ic98c61223dce00e830ea0f199878d47b214bb224
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225160
Reviewed-by: Randall Spangler <rspangler@chromium.org>
These structures allow for simplication and feature expansion in
vboot. They are NOT backwards-compatible with old vboot1 structs.
This CL simply adds the new structs and unit tests for struct packing;
future CLs will add support for them in the firmware library and
futility.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I22532acf985dd74316bd30f17e750f993b6c53d7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224820
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
vboot2 supports only GBB header versions 1.1+. When the GBB header
was rev'd to 1.2, this broke the compatibility check for 1.1.
However, the test was written in such a way that wasn't detected. Fix
the check and the test.
BUG=chromium:415227
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Ifeb1f21bf5cf3cc05d31ac7912693e090eb8fd5e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225110
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This removes code duplicated between 2common.c and 2rsa.c. This is in
preparation for adding new unsigned hash algorithms.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make -j runtests
Change-Id: Ic9c542ae14d3b7f786129c1d52f8963847a94fb8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224780
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This adds a field in the GBB header to store the sha256 digest of
the HWID string, and updates gbb_utility so that it stores the
digest when it modifies the HWID. Because this is a new field,
the GBB_MINOR_VER is incremented.
BUG=chromium:415227
BRANCH=ToT
TEST=make runtests, VBOOT2=1 make runtests
Since the GBB is in the RO firmware, there should be no side
effects for existing devices (but even without that, they should
handle a minor version change without complaint).
Change-Id: Icdb2a0b564677b0b65e58df897d2ec5af3964998
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221360
This will be needed by other algorithms, so should not live inside the
rsa module. Also added explicit unit tests for it.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I92c8c6484964a93d755ac2ee93b57511794540e9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224111
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
In order to display the slow EC update screen on x86 devices
in normal mode it is necessary to request a reboot where the
VGA Option ROM is loaded.
This needs a bit of plumbing to pass the OPROM_MATTERS and
OPROM_LOADED flags into shared data so they can be consumed
in the VbEcSoftwareSync() function. It also needs the VbInit()
function to not immediately request a reboot if the VGA Option
ROM was loaded in normal mode and the SLOW_EC flag is set as it
will still need to be used during software sync.
A FIXME in VbEcSoftwareSync() is implemented and the comment is
removed, and two extra checks are done. First, if rebooting to
RO then also check if the VGA Option ROM is needed to save an
extra reboot, and second when exiting the software sync function
request a reboot without the VGA Option ROM if it was done in
normal mode and the option rom was needed+loaded.
The request for a reboot from VbEcSoftwareSync() is saved when
doing EC update in case there is an (optional) PD software sync
that may also need to display the screen.
BUG=chrome-os-partner:12257,chrome-os-partner:32379
BRANCH=samus
TEST=all tests pass, manual testing:
1) in normal mode, with EC/PD in RW, ensure that they are rebooted
to RO and the VGA Option ROM is loaded and the wait screen is
displayed, and then the system is rebooted at the end and the
VGA Option ROM is not loaded.
2) same as #1 with EC/PD in RO already, same result
3) same as #1 with system in developer mode, same result except
there is no reboot at the end of software sync
4) same as #1 with system in developer mode and EC/PD in RO,
ensure that there is no extra reboot at the beginning or end of
software sync.
Change-Id: Id592181efd640f4cd37a986cd1dcc29f3ca45104
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223718
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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>
This allows the algorithm list to be shared by code which simply needs
to look at the vboot structures.
No functional changes; just moving enums around and adding comments.
BUG=chromium:423882
BRANCH=none
TEST=make runtests; VBOOT2=1 make runtests
Change-Id: Ia8cefeffb28d5eceb290540195193ea13e68e2c1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223541
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is necessary to support reading the kernel from raw NAND flash,
where the driver may need to skip over bad sectors, and absolute
sector addressing is thus not practical.
The impact is relatively minor. Vboot only did two reads per kernel
anyway, one for the first 64KB of the partition and a second for the
rest of the kernel data.
Firmware which uses vboot will need to implement the streaming APIs.
Or, as a really easy workaround, just copy the implementation from
firmware/stub/vboot_api_stub_stream.c, which translates from the new
streaming API to the old sector-based disk API.
BUG=chromium:403432
BRANCH=none
TEST=make runtests; passes.
CQ-DEPEND=CL:221992, CL:222885, CL:222945
Change-Id: I7437b489650c95c09ac68b67d4d86f9e15c2fa73
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222410
Reviewed-by: Daniel Ehrenberg <dehrenberg@chromium.org>
This patch adds three functions called from vboot into depthcharge to
support NAND. NAND needs to stream rather than be accessed randomly
in order to skip bad blocks. The intended flow from vboot1 is:
- Read the GPT from a NAND disk handle, and depthcharge will silently
fill it in with reads from from SPI
- When a partition is selected, open a stream on the volume to access
NAND
- Sequentially read the NAND partition
- Close the NAND stream
This can be done multiple times when trying different partitions. The
stream is associated with the GPT by reading/opening a stream from the
same disk handle.
This patch includes stub implementations by rspangler to translate the
stream calls to block device calls.
To reduce vboot code duplication, this flow will be done for all media
types eventually, but a STREAMING flag is included to ease the transition.
The draft depthcharge code can be found at
https://chromium-review.googlesource.com/#/c/222312/
BUG=chromium:403432
TEST=stub implementations pass unit tests; together with upcoming depthcharge
and vboot code, actually boots a kernel. This compiles by itself.
BRANCH=none
Change-Id: I660a89594390c72c2ef6ea2564367ce62bd90cf2
Reviewed-on: https://chromium-review.googlesource.com/221992
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Daniel Ehrenberg <dehrenberg@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Randall Spangler <rspangler@chromium.org>
This gives recovery mode information on two boots back instead of one,
which may be handy for debugging.
It also allows determining whether a failure of the current boot
should try the other slot or go to recovery, using only information
stored in NV storage.
Added crossystem support for printing the fields, and unit tests.
BUG=chrome-os-partner:32585
BRANCH=none
TEST=make runtests; VBOOT2=1 make runtests
Change-Id: Ia9f4186210d30217b902db7c513ae4ab8851f8f4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221230
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Previously, we only kept that slot info in RAM. We read it from NV
storage, but never wrote it back.
Added a test to confirm proper behavior (and made sure it failed
before patching 2misc.c with the fix).
BUG=chrome-os-partner:32583
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Ie12124d9cbe417914fbde14ea5086380d637240f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221214
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
In AllocAndReadGptData() the code was changed to use the GPT header
to determine the LBA of the GPT entries. This change did not account
for devices that have an invalid header and it can attempt to read
from invalid block addresses on a device.
This commit happened here:
a2d72f7 vboot: cgpt: Refer to partition entries by entries_lba.
https://chromium-review.googlesource.com/213861
The subsequent steps in vboot, LoadKernel->GptInit->GptRepair will
fix a missing header and entries, so it is only necessary for one of
the headers to be valid.
This is commonly the case with a new USB stick that has an image
written to it as only the primary header will be valid in this case.
However it is also true if the primary header has been corrupted and
the secondary header is still valid.
The code has been changed to call CheckHeader() on the primary and
secondary headers before attempting to use the 'entries_lba' field
to read the entries from the device. AllocAndReadGptData() now only
fails if both headers are invalid.
A number of new unit tests are created to check for these failure
conditions. In order to support this I had to extend the vboot_kernel
test infrastructure to have a buffer for the mocked disk data instead
of just ignoring reads and writes. This is because many of the existing
tests assumed they could have an invalid GPT header and still pass.
Now that the header is checked it is necessary for a valid header to
be created before the tests can pass.
BUG=chrome-os-partner:32386
BRANCH=samus,auron
TEST=All unit tests pass when running 'make runtests'
In addition real-world testing was done by corrupting the primary
and/or secondary headers of USB stick to ensure that it will
successfully boot if one of the headers is valid.
Change-Id: I7f840a44742fa3ba9a124df29ab5749e4c5a40c1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220757
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Nam Nguyen <namnguyen@chromium.org>
If key is null in vb2_verify_digest(), we could attempt to dereference
it. In practice it never is, but for safety's sake we should avoid
the reference.
BUG=chrome-os-partner:32235
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I5a817e432922ea4c3b439b696cd2f8d988d0fecc
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219574
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This CL renames GPT_PMBR_SECTOR to GPT_PMBR_SECTORS and GPT_HEADER_SECTOR to
GPT_HEADER_SECTORS to better indicate that these are constants for sizes, not
location.
BRANCH=None
BUG=None
TEST=unittest
Change-Id: I26ed6d45d77dcb1eb714135edbb9e4124b54e953
Reviewed-on: https://chromium-review.googlesource.com/214830
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
This CL accesses the partition entry array through its header's
entries_lba value.
Previously, we assume the primary entry array lies on third sector, and
the secondary array lies (1 + 32) sectors from disk end. This assumption
was fine, even Wikipedia assumed the same.
But in order for us to support writing boot code to the third sector (as
required by some Freescale board), the primary entry array must be moved
to another location. Therefore, we must use "entries_lba" to locate the
arrays from now on.
BRANCH=none
BUG=chromium:406432
TEST=unittest
TEST=`cgpt create -p` and then `cgpt show`. Make sure the table
header and entries are properly moved.
Change-Id: Ia9008b0bb204f290b1f6240df562ce7d3a9bbff2
Reviewed-on: https://chromium-review.googlesource.com/213861
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
In order to disable PD software sync but still do EC software sync
it is useful to have a separate GBB flag for it.
This will allow me to release a Samus P2B firmware image that will
update the EC but not the PD, since the PD FW that comes on P2B
devices cannot be updated with software sync.
BUG=chrome-os-partner:30079
BRANCH=None
TEST=flash BIOS with updated EC+PD:
1) no GBB flags to override behavior updates both EC and PD
2) GBB flag to disable EC software sync disables both EC and PD update
3) GBB flag to disable PD software sync disables only PD update
Change-Id: I49ffb59238bee4a2dd66b24f2516e3ce46ea06cd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211910
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If a device has both an EC and a separate PD chip, call software sync
for each chip.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=Flash image.bin with new AP+EC+PD firmware, reboot.
See EC and PD both update and jump to RW.
On next cold boot, they jump to RW without again updating.
CQ-DEPEND=CL:210520
Change-Id: Ie445336ade46f0009c040afc14b3f40452caf27b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210536
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This will be used in subsequent CLs to support PD software sync. For
now, only devidx=0 is used.
This changes the external vboot API, so must be checked in at the same
time as changes to the u-boot and depthcharge implementations. For
now, those implementations should simply check if devidx=0 and fail if
it's not.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=make runtests
CQ-DEPEND=CL:208195,CL:208196
Change-Id: Iad3be9d676ac224c4582669bcd67176b39f75c73
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208210
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
I don't think these utilities are needed any longer, so mark them as
deprecated. They will still be built and can be run via futility, but
invoking them directly will fail with a warning message.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Change-Id: Ie704f2cecc3c37c91e4a0ffbcbcf94e2bf3ba05b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208775
Reviewed-by: Randall Spangler <rspangler@chromium.org>
A lot of functions were added some time ago, nominally to support keeping
the firmware in an MTD device that wasn't formatted with the GPT headers.
That work was never completed, so these functions aren't used anywhere.
We may want to resurrect this work at some future point. Until then, this CL
just moves some of the functions into an "unused" file.
BUG=chromium:231567
BRANCH=ToT
TEST=manual
All tests pass, all firmware and external repos build.
Change-Id: I420dd52d1cea0418cedf2f8e834c61145915f20c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207037
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We've been creating and linking against a library called "libvboot_host.a"
for two different reasons. The main purpose is to build the vboot_reference
tools found in the utility/ directory. But there are some external userspace
programs that would also like to use some functions in this library.
This change establishes libvboot_host.a as the library for use by external
userspace programs only, and creates a new libvboot_util.a library that's
only used inside this source tree to build the vboot utilities.
BUG=chromium:231567
BRANCH=ToT
TEST=manual
Build and run the local tests:
make runalltests
make clean
Build Link firmware and all the utilities:
emerge-link chromeos-base/vboot_reference \
sys-boot/depthcharge \
sys-boot/coreboot \
chromeos-base/chromeos-ec \
chromeos-base/chromeos-firmware-link \
chromeos-base/chromeos-cryptohome \
chromeos-base/update_engine \
chromeos-base/chromeos-installer \
chromeos-base/chromeos-login \
chromeos-base/verity
Build Lumpy utilities, which include the 32-bit cros_installer:
emerge-lumpy chromeos-base/vboot_reference \
chromeos-base/chromeos-login \
chromeos-base/verity \
chromeos-base/update_engine \
chromeos-base/chromeos-installer \
chromeos-base/chromeos-cryptohome
Change-Id: Ie81ff1f74a6356cb8fab7d98471139d7758c4f19
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207016
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The functions TlclLog() and TlclSetLogLevel() are declared in tlcl.h, but do
not appear anywhere else in the source. Let's not declare nonexistant
functions.
BUG=chromium:231567
BRANCH=ToT
TEST=make runtests
These never existed or did anything. They still don't.
Change-Id: Id6f0216d70b7b62d91486aba7d6cd996dc5f7d8d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205708
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Bill and I both added meanings for byte 1 bit 0x10. His changed
(NV_BOOT_BACKUP_NVRAM) landed first, so move the vboot2 bit to byte 2.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 make runtests
Change-Id: Ib7ff8da47d03f91cbeb729ca517c6315dfb4e6ac
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205408
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Compiling in the GBB magic number as is causes any tools that search for the
number to fail. This patch allows firmware to embed XOR'ed signature.
TEST=Booted Nyan in normal mode. FAFT:firmware_DevMode passes.
BUG=none
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Id18905a9969af3db24151e7c51332d0e94405108
Reviewed-on: https://chromium-review.googlesource.com/205416
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
When porting vboot2 to a platform, it's common to copy 2stub.c and
then start implementing APIs. Adding explicit errors makes it clearer
when an unimplemented API is called.
BUG=chromium:370082
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I1f412b7ed4b431dbdbdee5e33b27bf7206186918
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204960
Reviewed-by: Daisuke Nojiri <dnojiri@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 the higher-level routines for verifying keyblock and
preamble.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: I82da9542c8857a3f89a85f206c9f5aecadf94a79
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203501
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>
Error codes reported by 2common.c are now very specific, and tests
verify the proper errors are reported.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: I9480bd22b60ae339196c92918a8a984a9f05ac1a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202938
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Error codes reported by the aligment checks in common.c are now very
specific, and tests verify the proper errors are reported.
Changed args to vb2_member_inside() so I can force wraparounds.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: Ib135674e82005b76bce7a83a1f4a65a9c5296cf4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202937
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Error codes reported by the crypto and storage APIs are now very
specific, and tests verify the proper errors are reported.
More specific error codes coming to other files next, but I don't want
this CL to get too long.
This also changes test_common.c so TEST_EQ() reports mismatched values
in both decimal and hex, and adds TEST_SUCC() to test for a successful
return value.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: I255c8e5769284fbc286b9d94631b19677a71cdd0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202778
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
We use a few bytes of battery-backed nvram to save some flags across
reboots. However if the battery discharges completely, these flags are lost.
There aren't any security issues with that since they reset to safe values,
but some of the flags are used to configure how the system boots in
dev-mode.
If a dev-mode user has completely replaced ChromeOS with some other OS, then
she often needs to set the dev_boot_usb and/or dev_boot_legacy flags as well
in order to boot it using Ctrl-U or Ctrl-L. If the battery dies, then those
flags are cleared, and the only way to make the Chromebook boot again is by
going through recovery, which wipes the disk.
This change uses a new NV space in the TPM to back up some of the nvram
flags. These nvram fields will be backed up:
block_devmode
dev_boot_legacy
dev_boot_signed_only
dev_boot_usb
fwupdate_tries
loc_idx
Because writing to the TPM space is slow and limited to an unspecified but
finite number of cycles, we only back up the fields when specifically
requested by the new backup_nvram_request flag. This flag will be set by
crossystem whenever it is used to change any of the fields listed above. The
backup will be attempted at the NEXT boot (because the TPM is locked after
booting), and the backup_nvram_request flag will be cleared if the backup
was successfull.
Note that this CL is for Top of Trunk only. The firmware will create the
required TPM spaces on systems that have never been booted, but we don't yet
have a secure or reliable method to update existing systems.
FYI, on Link, determining that the TPM's backup NV space doesn't exist adds
about 6ms to the boot time. If it does exist, the backup_nvram_request flag
is cleared automatically so it won't check until it's set again.
BUG=chromium:362105
BRANCH=ToT (only!)
TEST=manual
Testing this is a long and involved process. Read on...
First, there are host-side tests for it. In the chroot:
cd src/platform/ec
make runtests
Second, to test on a completely NEW system that was first booted with a BIOS
that contains this CL, do this:
Enter dev-mode
Use crossystem to set values for the fields listed above
Confirm that "backup_nvram_request" is set to 1
Reboot
Use crossystem to confirm that "backup_nvram_request" is now 0
Remove the battery and the AC
Reattach either battery or AC so it will boot again
Use crossystem to confirm that the backed up fields are still good, while
the others have been reset to default values
Switch to normal mode
Remove the battery and the AC
Reattach either battery or AC so it will boot again
Look at the bios info in chrome://system to see what crossystem says
Confirm that the dev_boot_* flags are all 0, while the others are restored
Third, to set things up to test this on an existing system (I used Link),
you have update the BIOS, delete both the Kernel and Firmware NV spaces in
the TPM, then reboot so that the BIOS will create the Backup, Kernel, and
Firmware spaces. It will only do that if they're all missing.
Open it up, disable write-protect, attach a servo, etc.
Switch to dev-mode, log in.
Run make_dev_firmware.sh
Reboot in recovery mode, and insert a USB stick with a test image on it.
NOTE: In order to fiddle with the TPM, we'll *always* have to boot in
recovery mode, since that's the only time the TPM is left unlocked. That's
NOT the same as pressing Ctrl-U at the scary boot screen. The rest of
these steps assume you've booted in recovery mode and are running from the
test image on the USB stick.
Run
make_dev_ssd.sh --remove_rootfs_verification --recovery_key
Reboot (recovery mode)
Run
mv /etc/init/tcsd.conf /etc/init/tcsd.conf.disabled
Reboot (recovery mode).
Run "tpmc getvf". It should say
deactivated 0
disableForceClear 0
physicalPresence 1
physicalPresenceLock 0
bGlobalLock 0
Run "tpmc geto". It should say
Owned: no
Now you'll need to build the "tpm-nvtool" utility. In the chroot:
cd src/third_party/tpm/nvtool
make
Copy that to the DUT, in /usr/local/bin.
Now run
tcsd
tpm-nvtool --list | grep Index
You may see a number of spaces, but you should at least see these:
# NV Index 0x00001007
# NV Index 0x00001008
Run
tpm_takeownership
It will prompt you for two passwords (and confirm each one). Respond with
something you can remember like "google".
Run
tpm-nvtool --release --index 0x1007 --owner_password "google"
tpm-nvtool --release --index 0x1008 --owner_password "google"
Verify that it worked with
tpm-nvtool --list | grep Index
Power off.
Using servo, flash the new BIOS that has this CL in it.
Power on, normally this time (not recovery mode). If all goes well, it
should create the correct NV spaces and boot into the SSD. Copy tpm-nvtool
into this image too, and run
tpm-nvtool --list | grep Index
You should now see at least these spaces:
# NV Index 0x00001007
# NV Index 0x00001008
# NV Index 0x00001009
Now you're ready to test the backup/recover feature.
Change-Id: I00031fa0774720147327e2ae0f37e26b34b86341
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202138
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
This is the third 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: I3a5daa5438afc5598d3dfcf5a597ffb16eda8749
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200140
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>
This is the first of several CLs adding a more memory- and
code-efficient firmware verification library. This CL adds the crypto
library (modified from firmware/lib/cryptolib) and unit tests for it.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: I4240eab227bb197cacc6c8e7a6397127d74414a2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199578
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
We'll try breaking this up into smaller pieces. This one's pretty
small - just the work buffer utility functions.
BUG=chromium:370082
BRANCH=none
TEST=make clean && VBOOT2=1 COV=1 make
Change-Id: I4c417438053c155d6f7f9725552066e9b059951c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201141
Two changes here.
First are some failing assertions in tlcl.c. These have always failed, but
only when DEBUG=1, so no one noticed. I've opened a bug to find out why, but
it's blocking something else. We're refactoring anyway, so for now we'll
just comment around it.
Second is a null-pointer dereference in VbSharedDataSetKernelKey(). Again,
only when DEBUG=1.
BUG=chromium:379255
BRANCH=ToT
TEST=manual
cd src/platform/ec
\rm -rf build
DEBUG=1 make runtests
Change-Id: Ia5e0a742f75057b449f3c19b778c5d2f0408d7cd
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202303
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
The return value of VbExDisplaySetDimension should be handled as VbError_t,
which means we should print error message when it's not zero.
Also add the return code to debug message.
BRANCH=none
BUG=none
TEST=emerge-nyan coreboot chromeos-bootimage, enter recovery screen.
Not seeing error messages anymore.
Change-Id: Icafdfd933d799e8496fedcf1633339065c6962a3
Reviewed-on: https://chromium-review.googlesource.com/200679
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
