For test purposes it should be possible to clear the wipeout request
raised by firmware.
BRANCH=none
BUG=chrome-os-partner:36059
TEST=verified that crossystem wipeout_request=0 changes the bit from 1
to 0, and wipeout_request=1 does not change it from 0 to 1.
Change-Id: Ic45ec03ed3e40e6fee4244804b8c231ee88af95b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262466
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If so desired by the firmware, disable developer mode each time the
recovery mode is entered.
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=with the rest of the patches applied observed desired behavior on
an SP5 (developer mode state wiped out on entering recovery)
Change-Id: If08dc517363bcc36fcc8b0b875a8700bbcefde4c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/261630
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This commands reads/sets a bit in the kernel-reserved area
of the vboot context nvram. The bit can also be set by the
driver during execution of a TPM command, to check if the
command is interrupted by a panic or power loss. Under
some circumstances, this correlates with the TPM assuming
it is under attack.
BUG=chromium:431360
TEST=try "crossystem tpm_attack" and variations
BRANCH=none
Change-Id: I87215d5a0becfb5c01e0b69867a339bfe6fd0b68
Reviewed-on: https://chromium-review.googlesource.com/261339
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
The help message for the sign command is much too long. This
breaks it into several subcategories.
BUG=none
BRANCH=none
TEST=make runtests
futility help sign
futility help sign pubkey
futility help sign fwblob
futility help sign bios
futility help sign vmlinuz
futility help sign kernel
Change-Id: I3e12b2cfdfb17a77c171f925a53748efb1d6c440
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/260496
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Removing rootfs verification or resigning kernels can lead to an
unusable system if the dev_boot_signed_only flag is set. Add a sanity
check to print out an error when this happens.
BRANCH=none
BUG=none
TEST=manual
Run /usr/share/vboot/bin/make_dev_ssd.sh with the dev_boot_signed_only
flag set to 1 and observe that an error message is printed.
Change-Id: If116538152ee3122e3b742918bf1676982754fdd
Reviewed-on: https://chromium-review.googlesource.com/260970
Trybot-Ready: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
We're moving the hardcoded check lists out of the pre-upload script.
BUG=chromium:466264
TEST=uploading a CL w/out a branch line is rejected
BRANCH=None
Change-Id: Ie51600cdc6a635ea925d3e329cdf310e487346ea
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/260711
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Instead of a separate help function for each command, let's just
require each command to handle a --help option. This will make it
easier to layer the commands (for example, "sign" could have
several subcommand variants, each with its own help).
BUG=none
BRANCH=none
TEST=make runtests
I also compared the result of running "futility help CMD" before
and after this change. The help still shows up correctly.
Change-Id: I5c58176f32b41b0a2c2b8f0afb17dddd80fddc70
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/260495
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Some of the help messages are getting pretty long. We should
allow each command to provide additional help details only when
asked.
BUG=none
BRANCH=none
TEST=make runtests
I also compared the help messages for all commands, both before
and after this change to ensure that nothing was different.
Change-Id: Ibe92ec80f99d286886fe020c9d826a5a05556471
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/260494
Reviewed-by: Randall Spangler <rspangler@chromium.org>
It has become necessary to be able to "factory reset" certain devices
on firmware request. The best mechanism for this is NVRAM, as the
request needs to be detected very early in the boot process, before
other means of communications with the upper layers are available.
A previously unused NVRAM bit (bit 0x08 at offset zero) is taken for
this purpose.
A new flag is introduced to allow the firmware to signal the need to
assert this bit.
A new variable name/parameter ('wipeout_request') added to crossystem
to provide user space access to the setting of the dedicated NVRAM
bit.
BRANCH=storm
BUG=chrome-os-partner:37219
TEST=with all the patches applied, on storm, holding the recovery
button at startup for 10 seconds, causes 'crossystem
wipeout_request' to report '1'.
Change-Id: If1f6f061ce5b3f357b92aaa74cb129671dc30446
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/259857
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When trying to build out-of-tree, running `git status` will attempt to
write to the .git/ dir which causes a sandbox violation.
Since this code doesn't seem to actually do anything, drop it.
BUG=chromium:466499
TEST=precq still passes
TEST=build now passes when building out of tree
TEST=`./scripts/getversion.sh` produces good output with clean & dirty trees
BRANCH=None
Change-Id: Ia722fedef692876ffc87109b3a1d2e4a76235532
Reviewed-on: https://chromium-review.googlesource.com/259541
Trybot-Ready: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Rather than write to temp files in the cwd, use the existing build dir
as our scratch space. This lets us build out of tree properly even if
the source repo is read only.
BUG=chromium:466499
TEST=precq still passes
TEST=out-of-tree ebuild passes
BRANCH=None
Change-Id: I5dd69dcb8289cc557143e115e409b9c0924263b3
Reviewed-on: https://chromium-review.googlesource.com/259530
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
This lets us control it explicitly. In CrOS, we won't turn it off, but
most distros will want to as it's too hard to keep a handle on compilers
and various settings users leverage.
BUG=chromium:466499
TEST=precq still passes
BRANCH=None
Change-Id: I11bf03acefa3fd624dd4c5688dd18e3a3c87647d
Reviewed-on: https://chromium-review.googlesource.com/259521
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
This adds a test to be sure we can identify the types of input
files that futility can handle.
This fixes commit d7e1e4f0be, which
was reverted in commit 1ab2c10e8c
because the Makefile dependencies were wrong.
BUG=chromium:466433
BRANCH=none
TEST=make runtests
Also try this:
\rm -rf build
make $(pwd)/build/tests/futility/test_file_types -j16
Before, that failed every time. Now it works.
Change-Id: I7702e1b99f4f593ef0121686a8616a2cb132e64a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/259651
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds a test to be sure we can identify the types of input
files that futility can handle.
BUG=none
BRANCH=none
TEST=make runtests
Change-Id: Iff1dcc05530af2969a82d7c32599850bba59597a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/258501
Some commands look for a --debug option, others don't. The
feature is implemented globally, so let's parse it as a global
option.
BUG=none
BRANCH=none
TEST=make runtests
Change-Id: I3b169e4a1b93443786913276651113d1c915a834
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/258500
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We want a quick and human-friendly way to match keys with
signatures, so we decided to give each key a unique GUID and
carry that ID around when signing things.
But then we realized that we could autogenerate a unique
identifier from the .pem file itself, which is even better
because then we can match our binary keypair structs with the
openssl file used to generate them.
This change replaces the GUID id with a sha1sum calculated from
the public key's "keyb" blob.
BUG=none
BRANCH=none
TEST=make runtests
Also:
futility show tests/testkeys/key_rsa4096.pem
futility create tests/testkeys/key_rsa4096.pem foo
futility show foo.vbp*
Note that the GUID is the same for all files.
Change-Id: Ie44e46c83433718b1ff0163c1e7c51ec331b99f9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256181
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We use the .pem files to generate our public and private key
files. Since we display the sha1sums of those files to help keep
track of them, we might as well also display the same information
about the RSA .pem files, too.
BUG=chromium:231574
BRANCH=none
TEST=make runtests
futility show tests/testkeys/*.pem
Change-Id: Ibfd1e016d65981d477ed7d117d23dedf48b95873
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246769
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Because all of our private key structs carry around the openssl
struct rsa_st data blobs, we can use those blobs to extract the
corresponding public key and generate a digest of it.
This lets us match our public and private keys without having to
rely on the filenames. There's no crypto verification without
actually *using* them, of course, but it's handy for quick reference.
BUG=chromium:231574
BRANCH=none
TEST=make runtests
This also adds a test to ensure that all the public and private
keys generated from the same .pem file have the same sha1sums.
Change-Id: If83492437e3ef37f7c4ebca4675336b75f631901
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246768
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This enhances the futility show command to recognize and identify
our public and private key files, for both the old vboot 1.0
format and the new vboot 2.1 format.
BUG=chromium:231547
BRANCH=ToT
TEST=make runtests
vboot 1.0:
futility show tests/devkeys/*.vbp*
vboot 2.1:
futility create tests/testkeys/key_rsa2048.pem foo
futility show foo.vbp*
Change-Id: I9d7641db03e480b416790a7da6b473215444128a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246767
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This command reads a single .pem file and emits the public and
private keys generated from it. It can produce both the old-style
vboot 1.0 keys (.vbpubk and .vbprivk), or the new vboot 2.1
format keys (.vbpubk2 and .vbprik2). The default is the new
format, but you can give futility the --vb1 arg to force the old
format.
A test is included.
BUG=chromium:231547
BRANCH=ToT
TEST=make runtests
Change-Id: I4713dc5bf34151052870f88ba52ddccf9d4dab50
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246766
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Some Brillo devices may have smaller kernel partition and we need to reduce the
size limit.
BUG=none
BRANCH=none
TEST=make_dev_ssd.sh applied on a Brillo config with 8MB kernel partition.
Change-Id: I9ca37445a6cdb20138f13dbe975c207383a1474c
Reviewed-on: https://chromium-review.googlesource.com/255341
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Mao Huang <littlecvr@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
The host-side futility tool will need to support all extant vboot
implementations. Some legacy futility commands only support the
original vb1 format, but others ("show" or "sign", for example)
may need to be instructed which formats to expect or emit.
This change adds some global args to specify the preferred
formats. It also cleans up a few [unused AFAICT] one-letter args
to avoid conflicts.
BUG=chromium:231574
BRANCH=none
TEST=make runtests
Nothing makes use of this yet, except the "help" command.
Change-Id: Ib79fa12af72b8860b9494e5d9e90b9572c006107
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246765
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Before, building locally left a file named "vboot_host.pc" in the
top directory.
With this change, it's put into the $BUILD directory where it
belongs.
It still gets installed into the same place, of course.
BUG=chromium:459338
BRANCH=none
TEST=make runtests, and
Run:
make test_setup MINIMAL=
make test_setup MINIMAL=1
find . -name vboot_host.pc
Before this CL:
./build/install_for_test/usr/lib/pkgconfig/vboot_host.pc
./build/install_for_test/lib/pkgconfig/vboot_host.pc
./vboot_host.pc
After this CL:
./build/install_for_test/usr/lib/pkgconfig/vboot_host.pc
./build/install_for_test/lib/pkgconfig/vboot_host.pc
./build/vboot_host.pc
Change-Id: I3a888f72a5753228eec5187178d0da22de782171
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/254712
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Nam Nguyen <namnguyen@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
make runtests -j4 occasionally failed due to missing
dependencies. This helps. Of course, there may be others...
BUG=none
BRANCH=ToT
TEST=make runtests -j4
Change-Id: Iff6e96f94b125a16be76d8cf34ce473bf6c65fe5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246764
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This shows an error message when cgpt.bin failed to run, with its
reason. Without this patch, "cgpt" would just fail and return -1 in
that case making it difficult to know the reason of the failure.
BUG=chrome-os-partner:36061
TEST=replaced this binary in storm recovery initramfs 6699.0.0 and it
shows the error message if cgpt.bin is not installed.
BRANCH=None
Change-Id: I3ffaba5a63c491ac7d5b16086d5ae21005f40317
Reviewed-on: https://chromium-review.googlesource.com/251868
Reviewed-by: Alex Deymo <deymo@chromium.org>
Commit-Queue: Alex Deymo <deymo@chromium.org>
Trybot-Ready: Alex Deymo <deymo@chromium.org>
Tested-by: Alex Deymo <deymo@chromium.org>
postinst needs access to a kernel that is bootable from legacy BIOS.
futility provides extraction of a bootable vmlinuz from the kernel
partition via the command line. This patch provides a function which
does the same thing and is suitable for static linking into postinst
with minimal additonal code linked in. This way we can avoid issues with
running dynamic executables during postinst.
BRANCH=none
TEST=None
BUG=chromium:455343
Change-Id: Iaec2f48e4d8f78a4bbfcc1636b6ce478e95e9a8e
Reviewed-on: https://chromium-review.googlesource.com/251760
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Per the pep-0394 recommendation, version specific python scripts should
specify the interpreter version.
TEST=Run tests on a system with python3 default
BUG=None
Change-Id: I83e98f3bb0235230293819104570930085788398
Reviewed-on: https://chromium-review.googlesource.com/251132
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Anatol Pomazau <anatol@google.com>
Commit-Queue: Anatol Pomazau <anatol@google.com>
dump_kernel_config utility used mmap() to map a file or block device to
memory and searched from there. This CL removes mmap(), and reads from
the input sequentially. We need this so that working with MTD devices is
possible. We just need to implement another read function.
BUG=chromium:457862
BRANCH=none
TEST=make runtests
TEST=FEATURES=test emerge vboot_reference
Change-Id: I83e98f3bb079879f411d7f2f584b1792131b9b38
Reviewed-on: https://chromium-review.googlesource.com/249270
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
Trybot-Ready: Nam Nguyen <namnguyen@chromium.org>
Kernel preamble flags are set by the signer for passing hints about
the image. Read these flags from the preamble and pass it back to the
caller in kparams structure.
BUG=chrome-os-partner:35861
BRANCH=None
TEST=Compiles and boots to kernel prompt for both CrOS image and bootimg.
Change-Id: I07a8b974dcf3ab5cd93d26a752c989d268c8da99
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/245951
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
1. Increase kernel preamble revision from 2.1 to 2.2.
2. Add flags field to kernel preamble.
3. Update futility to accept flags parameter for vbutil_kernel and
cmd_sign for kernel.
4. Pass in an extra flags field to SignKernelBlob and
CreateKernelPreamble.
BUG=chrome-os-partner:35861
BRANCH=None
TEST=1) "make runalltests" completes successfully. 2) vboot_reference
compiles successfully for ryu. 3) Verified flags field in header using
futility show.
Change-Id: If9f06f98778a7339194c77090cbef4807d5e34e2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/245950
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Minimal Android.mk sufficient to build host tools to compile
futility vbutil_keyblock and vbutil_kernel to sign kernel images.
BUG=none
TEST='mm' from within Android tree compiles
BRANCH=none
Change-Id: Ie46be27cd14a5ca73a23eb52238eb9fd326ccaf4
Signed-off-by: David Riley <davidriley@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247820
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>
The following works from a Mac with these changes:
make Q= ARCH=arm HAVE_MACOS=1 `pwd`/build/futility/futility
Only vbutil_keyblock and vbutil_kernel have been exercised.
BUG=none
TEST='make Q= ARCH=arm HAVE_MACOS=1 `pwd`/build/futility/futility'
BRANCH=none
Signed-off-by: David Riley <davidriley@chromium.org>
Change-Id: Ie69cfee0c650d4ff96be6322083a2fea1543ee39
Reviewed-on: https://chromium-review.googlesource.com/246773
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Commit-Queue: David Riley <davidriley@chromium.org>
vboot2 added a few new recovery reasons (and abolished many old ones).
In the current vboot2/vboot1 hybrid architecture used on Veyron, the
vboot1 kernel verification part controls the status display when
pressing the TAB key, which may try to show recovery reasons set by the
vboot2 firmware verification part. These currently result in the not
very helpful "We have no idea what this means", so lets hack a few more
strings into vboot1 which will be otherwise harmless. Also add the
recovery_subcode field to the display, which is used much more
extensively by vboot2 and often very useful in firguring out what really
went wrong.
BRANCH=veyron
BUG=None
TEST=Manually set a few recovery reasons and subcodes through crossystem
and made sure they get displayed correctly on my Jerry.
Change-Id: I3f3e6c6ae6e7981337841c0c5e3cd767628472c3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248391
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The kernel chromeos_arm platform device provides the recovery status
with the consideration of active polarity.
Thus make crossystem to read from chromeos_arm device first. If this
is not available, read directly from gpio pin status.
BUG=chrome-os-partner:36425
BRANCH=none
TEST=ran on kitty,
'crossystem recoverysw_cur' return 0 with recovery switch off
'crossystem recoverysw_cur' return 1 with recovery switch on
Change-Id: Ie20630d7d07aeadf24044cd3ffc495df7cdd8a4a
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/246883
Tested-by: Titan Lee <titanlee@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Titan Lee <titanlee@nvidia.com>
The length of the signature is 8 bytes. We've been checking 9
bytes instead, pretty much forever. All the tests have passed
because although the signature we're looking for is an 8-byte
string followed by a '\0', the next field in the header contains
the revision number 0x00010000, so the 9th byte is always zero.
We should follow the spec, though.
BUG=none
BRANCH=none
TEST=make runtests
Change-Id: I7cc6370250fa36a193f4a9fa5bc0099aea465618
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247331
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch adds a check to vboot2 secdata accessor functions that
returns an error if vb2_secdata_init() has not yet been called or
failed for some reason. This avoids a problem where vboot may
misinterpret random garbage (e.g. from transient read failures) as
valid secdata in recovery mode and write it back to the TPM (bricking
the device in a way that requires manual repair).
Also removes VB2_ERROR_SECDATA_VERSION check. This check was not
terribly useful since there should be no way a vboot2 device could ever
have secdata version 1 (and if it did, it should still fail CRC checks).
This error can trigger for cases when secdata contains random garbage
(e.g. all zeroes) and prevent the much more appropriate
VB2_ERROR_SECDATA_CRC error from even being checked for, which just
creates confusion and makes it harder to determine the real problem.
BRANCH=veyron
BUG=chrome-os-partner:34871
TEST=Emulated TPM read errors by just manually memset()ing secdata to 0
in coreboot, verified that vboot does not write back to the TPM and the
device will start working fine again once the disruption is removed.
Change-Id: I76bcbdbcd8106a0d34717cc91a8f2d7cda303c3f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244846
Forgot to update the bitsizes in the variable constants.
BUG=chromium:454651
TEST=`./create_new_keys.sh` still generates 8k keys
TEST=`./create_new_keys.sh --4k` now generates 4k keys
BRANCH=None
Change-Id: Ie285649f4d58ad2e2cba71f4cab737cc2235e3ab
Reviewed-on: https://chromium-review.googlesource.com/245890
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
