Add a new flag to nvstorage for controlling fastboot capabilities
offered in firmware in dev-mode. By default, value of this flag would
be ignored in normal mode. Thus, when fastboot-based recovery is
entered from normal mode, only limited capability would be available
in firmware.
After switching to dev-mode, this flag can be set automatically by
user script after performing the wipe or it can be set manually using
crossystem. When fastboot-based recovery is entered from dev mode and
this flag is set, it will provide full fastboot capability in the
firmware.
BUG=chrome-os-partner:40196
BRANCH=None
TEST=Compiles successfully for smaug. make runalltests successful.
Change-Id: I761a9ab304dd90f0b73081acc9ce1f8d9052325f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/271369
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
This suppresses following 'maybe-uninitialized' gcc 4.9.2 errors:
CC futility/futility.o
futility/futility.c: In function ‘do_help’:
futility/futility.c:262:2: error: ‘vstr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
printf("The following %scommands are built-in:\n\n", vstr);
^
cc1: all warnings being treated as errors
host/lib21/host_misc.c: In function ‘vb2_str_to_id’:
host/lib21/host_misc.c:154:14: error: ‘val’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
id->raw[i] = val;
^
cc1: all warnings being treated as errors
BUG=none
BRANCH=none
TEST=compile, run unit tests
Change-Id: I6b9d19f2d6e9deb2010dd22602d2a3310f4db335
Signed-off-by: Anatol Pomazau <anatol@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/265370
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Anatol Pomazau <anatol@google.com>
Tested-by: Anatol Pomazau <anatol@google.com>
AFAICT this property is not really used by anything. All factory
scripts that need detailed memory info get it from mosys. Most
platforms display "unknown" which causes confusion whenever
a bug is filed to support crossystem on a new platform.
BUG=chrome-os-partner:36176
BRANCH=none
TEST=no more "unknown" ddr-type shown in crossystem output on speedy
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I97e66c362e9d88c843128a411512d5a76ac5f87d
Reviewed-on: https://chromium-review.googlesource.com/263982
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
vboot currently uses the |SHA256_CTX| name, which is claimed by OpenSSL.
To work around this, it defines OPENSSL_NO_SHA, but that can't be done
at compile time:
The OPENSSL_NO_* defines are set by OpenSSL to reflect the configuration
that it was built with so that users of OpenSSL can disable features as
needed. They can affect the contents of structures any thus the ABI of
the library.
If these defines are set outside of OpenSSL, then the library and the
code that uses it will have incompatible ABIs. At that point it's only
functioning by blind luck.
This change renames the name-collisions so that this hack isn't needed.
This is the same change as was made internally in cl/85758149.
BUG=none
BRANCH=none
TEST=emerge-samus coreboot; make runtests
Change-Id: I709da2507f341896d89d50129ce30ffb111a20d1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/263506
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
A truncated BIOS with an otherwise valid FMAP that now points way
off the end of the file shouldn't cause coredumps.
BUG=none
BRANCH=ToT
TEST=make runtests
Change-Id: Idf96e1e6a381bf0fe0b1cb2d16e3dad39ce7a0dc
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245500
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Adding functionality to allow for rebuilding of vmlinuz after it
has been processed into vblock and header stripped. Basically appends
the 16-bit header of a vmlinuz image onto the end of the vblock.
BUG=chromium:438302
BRANCH=none
TEST=Successfully ran "make runalltests".
Also, ran:
1. Repack kernel block (so that 16-bit header is included):
"vbutil_kernel --pack kern_0 ..."
2. Verify kernel: "vbutil_kernel --verify kern_0 ... ". This should
be done before booting into kernel, but not necessary for it to work.
3. Rebuild vmlinuz image:
"vbutil_kernel --get-vmlinuz kern_0 --vmlinuz-out vm.out"
4. Set up kexec with vmlinuz (this should complete with no errors):
"kexec -l vm.out (other kernel cmd line args)"
5. Boot into kernel:
"kexec -e"
Change-Id: Iaa1582a1aedf70b43cdb3a56cde1fb248f1793d4
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232750
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When working on NAND, we do not actually work with one device name. We
work on a temporary file instead. Moreover, depending on the type of the
partition, we need to show different devices.
BUG=None
BRANCH=None
TEST=All commands must be run on storm_nand
TEST=/usr/bin/cgpt.bin find -t kernel should print out /dev/mtd2
TEST=/usr/bin/cgpt.bin find -t rootfs should print out /dev/ubiblock5_0
TEST=/usr/bin/cgpt.bin find -t data should print out /dev/ubi1_0
Change-Id: Ia36777ffa6a9cfc7c8ec4b128e49ece140428238
Reviewed-on: https://chromium-review.googlesource.com/242291
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@google.com>
This patch changes the FMAP detection mechanism in host utilities to use
the same algorithm as flashrom: try to check the offset with the largest
possible alignment first, then subsequently check other offsets in the
order of larger to smaller alignments. This provides consistency between
the tools and makes the chance of finding the "wrong" FMAP (e.g. a bit
pattern that just looks like an FMAP header, maybe from a piece of
source code that tries to look for the same) less likely, since we
usually try to prefer large alignments for the FMAP offset (for flashrom
efficiency).
BRANCH=None (should be updated on the signers... is that a branch?)
BUG=chromium:447051
TEST='make runtests'. Manually ran the new dump_fmap on all images in
tests/futility/data, and on a "known broken" Veyron_Pinky image that had
a "fake" FMAP header at a 4-byte aligned offset.
Change-Id: I15873573a93f3926c70136679dccd626e5038614
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240750
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
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>
Also add vb2_common_desc() helper function to return the description
for an object starting with a common struct header.
And use the new host lib function to create the keyblock for verifying
the firmware lib.
Add tests for everything new.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I1fadb3e249e771a692cc69b23620c6ddd46a48ac
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231721
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This removes the hacky conversion from old-style packed keys and
signatures, which existed only because at the time we didn't have the
ability in hostlib to create new-format key and signature structs
directly.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Id7cb3dfce740f2546464a4caae2629af864d7b45
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231543
Including signing with bare hashes, and signing an object with more
than one signature. With unit tests, even.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: Iad0b9f9f6cca7129071aebf0cbc60c0daa94d382
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231452
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
And unit tests for them.
Move roundup32() into hostlib.
Fix WriteFile() returning success even if it failed to write to the file.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I8a115335c088dc5c66c88423d1ccbda7eaca1996
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/230844
Previously, "cgpt" called out to "flashrom" directly to read and write
NOR area. This CL removes that dependency and always treats "drive_path"
as the storage of GPT structs. This makes it consistent that whatever
device that cgpt reads from or writes to is always the device that
stores GPT structs. We only need to pass in the size of the drive that
contains the partitions, but we do not need to access to that drive.
More information is in the bug.
BUG=chromium:432611
BRANCH=none
TEST=unittest
CQ-DEPEND=CL:228942
Change-Id: Id0139adf70463cec4f2924de8b9a4725dbec822b
Reviewed-on: https://chromium-review.googlesource.com/229736
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
Storing nvram in SPI Flash becomes more and more popular. Retrieving
it takes quite a while due to various flashrom issues. While flashrom
still needs to be improved to minimize its running time, a good speed
up can be achieved by caching the nvram contents in crossystem.
The cache is invalidated each time nvram is written (this could be
optimized by updating the local copy, but probably is not worth the
extra effort).
BRANCH=storm
BUG=chrome-os-partner:33592
TEST=crossystem runs much faster now:
localhost var # time /var/tmp/crossystem
. . .
real 0m1.669s
user 0m0.790s
sys 0m0.170s
localhost var #
Change-Id: Ie4a483efc189257ff58c92bdc39871b917c89727
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228655
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The current logic for finding a GPIO expects only one gpiochip
entry to exist in /sys/class/gpio. With Samus there is a second
entry because the codec also exports a set of GPIOs.
To solve this we can use the gpiochip#/label file and compare
against the GPIO controller name described in ACPI.
This adds support for that detection method, as well as a new
GPIO controller entry for INT3437:00 which is used in Broadwell
systems.
BUG=chrome-os-partner:33098
BRANCH=samus
TEST=crossytem wpsw_cur works on samus (TOT with enabled codec)
Change-Id: Ib06f25c7c7e1451a3ab3bb00fd063e23b4d75878
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224156
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Currently ReadFileInt assumes that an integer value read from a file
is never going to be "-1" and uses that value to indicate failure.
In particular for GPIO values that may be returned by the kernel it
is possible for them to be not simply 0 or 1 but instead a bit within
the GPIO status register that indicates the value.
The function semantics are changed to have the caller pass in the
variable to store the integer in, and use the return code explicitly
as a pass or fail condition.
This requires all the callers of ReadFileInt to be changed to use the
new scheme, and the x86 ReadGpio function is changed to normalize the
GPIO value that is read from the kernel instead of assuming it is
always 1 for active high values.
BUG=chrome-os-partner:32645
BRANCH=samus,auron
TEST=build for samus, check crossystem output and ensure that all
values are properly reported and that wpsw_cur is correct now.
Also tested to ensure no changes in output on: x86-alex, daisy,
peach_pit, lumpy, stumpy, nyan_big, nyan_blaze, rush_ryu, panther,
wolf, zako, auron, rambi, squawks, parrot_ivb, veyron_pinky
Change-Id: I824152eed5f96cf1faaa18ba31a01f4d346ad172
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223009
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is just a cosmetic tweak to make it a bit clearer that
mosys is the underlying interface for these particular vbnv
read/write functions.
BUG=none
BRANCH=none
TEST=it still compiles
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ide172bfecf608a30489d25026268aedfc421ce4d
Reviewed-on: https://chromium-review.googlesource.com/222062
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This handles VBNV data stored in SPI flash which happens to be
the exact same way we handle VBNV data stored in the EC.
BUG=chrome-os-partner:31529
BRANCH=none
TEST=with CL:221349 applied, crossystem on storm no longer
spews tons of errors
Change-Id: I021d9f430acfac34dff44a927361a5a0e5ae2ff8
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222061
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: 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>
scripts/sign_data.sh is just a wrapper to do this:
./signature_digest_utility $1 $3 \
| openssl rsautl -sign -pkcs -inkey $2
AFAICT, that script is only invoked by the SignatureFile()
function in host/lib/file_keys.c, which is not referenced by
anything. I think I can remove both of those things.
Also remove utility/gbb_utility.cc, which should have been done
long ago in commit 6f39615.
BUG=none
BRANCH=ToT
TEST=make runalltests
Also ran it on daisy_spring-paladin and link-tot-paladin.
Change-Id: I16de5022765806f11bf6144d7ffd8cc849578a68
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/216719
Reviewed-by: Mike Frysinger <vapier@chromium.org>
It doesn't yet handle block devices, but it can display normal files
containing a entire BIOS image, a GBB, a VBLOCK, a .vbpubk, a .vblock,
and a firmware preamble (VbFirmwarePreambleHeader).
The command-line options are not well-documented.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Change-Id: I181f6331ae23599302bbaee3f270e8af9586cf06
Reviewed-on: https://chromium-review.googlesource.com/216032
Commit-Queue: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The functions that look for the FMAP and its entries should return more
useful values.
BUG=none
BRANCH=ToT
TEST=make runtests
No functional changes.
Change-Id: I4b62ea0de972bceb3d58f4ee8eb82ad065ddcbae
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214630
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Provide a PublicKeyLooksOkay() function to sanity-check VbPublicKey structs.
This was just part of PublicKeyRead(), but I want to separate the reading
from the checking.
BUG=chromium:224734
BRANCH=ToT
TEST=make runtests
Change-Id: I1dd808e623e2a7fdc2789e02305619111a7b01e6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214621
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>
Rather than continuing to report different variants of PCH GPIO the same
way use the common name of PCH-LP.
BUG=chrome-os-partner:28234
BRANCH=None
TEST=boot on samus and ensure there are no (error) reported
Change-Id: I9321e7bd85b2b3b3ebadc22ac32be6759e85f822
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210393
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
