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>
When disabling verity with make_dev_ssh.sh, a bug in
vbutil_kernel caused the re-signed kernel size to be the entire
kernel partition instead of just the necessary bits. Until we can
improve the test coverage, I'm rolling back the changes that
introduced this bug.
BUG=chromium:418647
BRANCH=ToT
TEST=manual
Created a new test image with these changes. You can install it
and disable dm-verity and it works (although there seems to be an
unrelated browser startup issue on ToT).
Change-Id: I48e8427b05e191c9894c42056429a79d57bfc78d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220935
Reviewed-by: Randall Spangler <rspangler@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>
This adds a --strict mode to the show command, which requires
that all signatures be valid in order to exit cleanly. It also
creates a "verify" command, which is really just an alias for
"show --strict".
BUG=none
BRANCH=ToT
TEST=make runtests
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I1fed7db7fe7128191bcab0c615706ef4fe2709f5
Reviewed-on: https://chromium-review.googlesource.com/219732
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=none
BRANCH=ToT
TEST=make runtests
This also modifies the tests to compare the futility sign command
results against the vbutil_kernel results.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Ibc659f134cc83982e3f0c0bcc108cc0eddbe228e
Reviewed-on: https://chromium-review.googlesource.com/219730
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds new file types to prepare for signing kernel partitions
and raw firmware blobs (FW_MAIN_A/B).
BUG=none
BRANCH=ToT
TEST=make runtests
No new functionality yet.
Change-Id: Ic6b6b94bb99f00ab54609dfe1b753b53868abaca
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219648
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The original vbutil_kernel command used file read and write to
make changes. Futility prefers to use memory-mapped files. This
rewrites cmd_vbutil_kernel.c to use that scheme.
BUG=none
BRANCH=ToT
TEST=make runtests
The original cmd_vbutil_kernel.c is renamed, and a test written
to ensure that the refactored version produces identical results.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Ic6c3e12429a5dcb271f8136a9edac70807d66120
Reviewed-on: https://chromium-review.googlesource.com/219647
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously, you could extract FMAP areas like so:
futility dump_fmap -x bios.bin FW_MAIN_A VBLOCK_A ...
This lets you decide what to name each area as it's extracted:
futility dump_fmap -x bios.bin FW_MAIN_A:/tmp/rw_a ../vblock
BUG=none
BRANCH=ToT
TEST=make runtests
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: If02b57e03294b0b0b1dbc216ef57afdd3bdf2960
Reviewed-on: https://chromium-review.googlesource.com/219646
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This doesn't have any visible effect. It just brings the meaning
of the where-do-I-put-this variable more in line with common
convention.
BRANCH=ToT
BUG=none
CQ-DEPEND=CL:217940
TEST=lots...
make runtests
make DESTDIR=BAR install
make MINIMAL=1 DESTDIR=FOO install
emerge-$BOARD vboot_reference
sudo emerge vboot_reference
trybots: link-tot-paladin, daisy_spring-paladin
Change-Id: I8d72664da07535f663d8b2f13c872eece37978b9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/217930
Reviewed-by: Mike Frysinger <vapier@chromium.org>
We still create the symlinks (FOO -> futility), but this
change invokes those built-in functions with "futility FOO ..."
instead of using the FOO symlink.
Note that the scripts/ directory is unchanged. That's a
separate CL, since we don't have tests for that.
BUG=chromium:231547
BRANCH=ToT
TEST=make runtests
In addition to running "make runtests", I temporarily
modified the Makefile to avoid creating the symlinks at all.
The tests still passed.
Change-Id: I96863259b9df02a3611f759a7509bf4090ae03e8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/216717
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Since all of the functionality of the resign_firmwarefd.sh script
is built in to futility, let's just make that script invoke
futility to do the work. We'll come back and remove the script
entirely, once all outside references to it have been changed to
do the right thing.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Also tested by editing tests/futility/test_resign_firmware.sh to
invoke the resign_firmwarefd.sh script instead of futility.
Everything passed.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Id068e551067a956cd7ddc3f9b9e23488261d8d94
Reviewed-on: https://chromium-review.googlesource.com/216716
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Just reporting that the parent process is "/bin/bash" doesn't
help much. Let's also report the cmdline args given to the parent
and the cwd. This will help us identify which shell script is
calling futility with the wrong args.
BUG=chromium:231547
BRANCH=ToT
TEST=make runtests
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I800995ff269ab8d8c56cad8827d8de48a53cd150
Reviewed-on: https://chromium-review.googlesource.com/216715
If we're re-signing a valid BIOS image, we want to be sure that
we preserve the original firmware preamble flags (RO_NORMAL and
so forth) if the --flags option does not specifically override
it.
This change adds a test for that case, and makes it happen.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I8cbde66abaf96ec82adf0205bedf57b1fd1b82a1
Reviewed-on: https://chromium-review.googlesource.com/216714
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This allows the sign command to work on BIOS images with
invalid VBLOCK areas. When re-signing an existing image, the
length of the firmware body is part of the firmware preamble
in the VBLOCK areas. If those are invalid, the BIOS can
still be signed, but it will have to sign the entire FW_MAIN
area. That's a little slower to verify, so we'd prefer not
to do that, but it works.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: If58b5c86c5df12f004eabff72c22bfb1e84de7fd
Reviewed-on: https://chromium-review.googlesource.com/216229
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds a "load_fmap" command, which is pretty much the
opposite of the "dump_fmap -x" command. It allows you to
replace the content of any FMAP areas with new stuff, without
mucking around with dd. There's a test for it, too.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I5a9ab249c9e63a9bb1a9b26feeb3ed757cd294f1
Reviewed-on: https://chromium-review.googlesource.com/216228
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The "sign" command can perform the same operation as the old
resign_firmwarefd.sh script, only about 20 times faster. The
test for that will use the new command instead.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Change-Id: Ie7f7a0ab6fc00d7e06cb263733bf6e7246fdb023
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/216227
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This resigns official MP-signed BIOS images, because that's the best way to
ensure we remain compatible forever. The resign_firmwarefd.sh script is
invoked make_dev_firmware.sh, which is used for development and bringup.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
No new functionality, only a new test.
Change-Id: I4bf9cdd8321d126e1c1a45fc198ef46b0eeb5c36
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/216226
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This creates a disk image and verifies a kernel can be loaded from it.
It is roughly analogous to vb2_firmware_tests.sh, but at the kernel
step instead of the firmware step.
This will get more interesting in the near future, with the upcoming
addition of a streaming API to read the kernel.
BUG=chromium:408265
BRANCH=none
TEST=make runtests
Change-Id: Icc9e6d0e318c4bd38fc9ab1ad704da99232822e1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214508
Reviewed-by: Daisuke Nojiri <dnojiri@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>
There are a number of tests that haven't even been compiled in a LOOOONG
time. Let's get them out of the way. We can always put them back later.
I'm adding a comment to this CL in the Makefile.
BUG=none
BRANCH=ToT
TEST=make runalltests
Change-Id: Id2d9f0b71fc40e4a260f54cf919c6af5e0ff85c5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214610
Reviewed-by: Randall Spangler <rspangler@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>
System libraries such as string.h and errno.h should be included with
<> instead of "" to avoid including them from the local directory.
BRANCH=None
BUG=None
TEST=FEATURES="test" emerge-link vboot_reference
Change-Id: I6734e14223fdad9060c6518790f52f1bcfcdf8e0
Reviewed-on: https://chromium-review.googlesource.com/214058
Commit-Queue: Alex Deymo <deymo@chromium.org>
Tested-by: Alex Deymo <deymo@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Update the unit tests which use it to use futility. No functional
changes to it, just relocation.
Remove the futility test which checks the exact list of supported
commands. This doesn't have a good way of handling
conditionally-compiled commands, and will be even harder to maintain
as we add more commands in the future. Presence of sub-commands is
still ensured by the other tests which use them (such as
vb2_firmware_tests.sh)
BUG=chromium:231547
BRANCH=none
TEST=make runtests && VBOOT2=1 make runtests
Change-Id: Idddb639276e4c6449d023d40ac7977123113bd28
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213191
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This change adds these formerly external utilities into the futility binary:
dev_sign_file
dump_kernel_config
gbb_utility
vbutil_firmware
vbutil_kernel
These target binaries will remain independent of futility, since they are
not directly related to verified boot:
cgpt
crossystem
tpm_init_temp_fix
tpmc
Also, dumpRSAPublicKey is removed from the target, since it is only used on
the build host to create new keypairs.
This change also add several additional tests.
BUG=chromium:224734
BRANCH=ToT
CQ-DEPEND=CL:210391,CL:210568,CL:210587
TEST=manual
make runtests
make clean
Also build and test:
- normal image
- test image
- recovery image
- firmware shellball
Note that this CL depends on simultaneous changes to the chromeos-initramfs
ebuild.
Change-Id: If791b5e9b5aac218ceafa9f45fc1785f16b91a64
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210403
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>
As we build features into futility, the standalone executables disappear.
Tests that invoke those executables will need to invoke futility instead.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I75230f6901aab8d978fa5d12505c243e1c90c938
Reviewed-on: https://chromium-review.googlesource.com/207926
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This checks some additional cases where the FMAP is a bit messed up.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Change-Id: Ic2b16bd8afdd1247d1f24c9f976d967764cadb73
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207719
This cleans up the Makfile and test scripts a bit, and adds a new test for
the builtin commands.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Change-Id: Ibf5aa867d4dcabc0e46daac6633036b035c99ac8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207718
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>
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>
This constructs a test firmware using the old vboot signing utilities,
and then verifies it using vboot2 libraries. This ensures vboot2 can
read files signed by the current signing process.
BUG=chromium:370082
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Icc113c982e5ed99382a4592f9ab688784e853c8e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204561
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
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 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>
With an loem keyset in a recovery shellball, we don't want to write the
rootkeys & vblocks to the firmware image directly. Instead, we'll put
them into a keyset subdir that the firmware updater will process later.
bios.bin
keyset/
rootkey.LOEMID
vblock_A.LOEMID
vblock_B.LOEMID
We still write the recovery key to the firmware image though as that is
shared between all the keysets.
BUG=chromium:381862
TEST=Ran against a recovery image with devkeys & loemkeys and checked shellball
TEST=`cbuildbot daisy-release` works
BRANCH=none
Change-Id: I6fc99c71e6c7dee25f7f9a466a97314ff750fda9
Reviewed-on: https://chromium-review.googlesource.com/203682
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@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
It's possible for the AP to get updated and remove the RO-normal flag
without needing to update EC-RW firmware - for example, if it only
needs to update the BIOS. In this case, the EC doesn't need update,
but does need to jump to its RW firmware. But if the EC is already
booted RO-normal with jump disabled, it will refuse that request and
go to recovery mode.
The fix is simply to check if the request to jump to RW requires the
EC to cold-boot first, and pass through that error code to the caller.
BUG=chrome-os-partner:22617
BRANCH=none (affects all platforms, but only in this odd case, and this
is a change to the RW portion of the code)
TEST=pass new unit test which triggers this condition
Change-Id: Ia8d64dff784a9135ef23f6eb26bbca4ad9df57c3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170168
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
