This can be used by implementations that want to request vboot to
favor a particular kernel entry for booting without affecting the
checks for rollback protection and image verification.
CQ-DEPEND=CL:274716, CL:274932, CL:275171
BUG=None
BRANCH=None
TEST=Compiles successfully. make -j runtests successful.
Change-Id: I6a4600020354f5d4118c17f083c353c2585c4181
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/274558
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Commit-Queue: Nicolas Boichat <drinkcat@chromium.org>
Trybot-Ready: Nicolas Boichat <drinkcat@chromium.org>
This patch reintroduces a vb2_secdata->struct_version check similar to
the one that was removed in CL:244846. The CRC is not a reliable way to
detect zeroed buffers, so this check helps vboot fail earlier and more
clearly in certain situations.
BRANCH=kitty,smaug,storm,veyron
BUG=chrome-os-partner:40778
TEST=make runtests. Rebooted Jerry with 'mem w 0xff7601b0 0xfdb9', saw
that recovery reason was now 0x2b (VBNV_RECOVERY_VB2_SECDATA_INIT).
Change-Id: Ic4376d127e6d14d4ef9c2f53c83090040ca4cb68
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/274138
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add support for functions to request unlock and lock of devices in
response to fastboot oem unlock/lock commands. Unlock operation is
equivalent to enabling dev mode and lock operation is equivalent to
leaving dev mode. It is the responsibility of the caller to ensure
that user confirmation is obtained before unlock/lock operations.
BUG=chrome-os-partner:40196
BRANCH=None
TEST=Compiles successfully and fastboot lock/unlock operations work as
expected on smaug. Added tests to ensure lock/unlock operations are
covered. Verified using make -j runtests.
Change-Id: Ibafe75abdd1202473009208a414f3996d537db4f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/273182
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
When the lid is closed and external power is applied
the system may boot and shut down faster than required
for the OS to determine that things were alright.
In timed charging setups this led to systems ending up
to consider the current version broken because it "failed"
repeatedly.
Remain generic about the reason for not counting boots
since there may be more situations in which we want to
handle the situation optimistically.
BRANCH=none
BUG=chromium:446945
TEST=none
Change-Id: Iea350e3c98d5c00156da682e52c90a882ba017c0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249150
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This API allows fastboot boot from memory command to verify that the
image loaded in memory is signed properly using recovery keys. Thus,
only officially signed recovery images can be booted using fastboot
boot command in recovery mode.
However, if GBB_FLAG_FORCE_DEV_BOOT_FASTBOOT_FULL_CAP is set, then
this routine will not perform any check and return okay for any image
sent by fastboot boot.
BUG=chrome-os-partner:40196
BRANCH=None
TEST=Compiles successfully. With GBB override for FASTBOOT_FULL_CAP
set any signed image is allowed to boot. With FASTBOOT_FULL_CAP not
set, then only officially signed image is allowed to boot. (make -j
runtests successful)
Change-Id: I78028853bd1ad09d3c610a687f327560557d5681
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/272696
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>
These are slightly more complex than the firmware versions, because
they need to deal with developer-signed keyblocks and keyblock flags.
BUG=chromium:487699
BRANCH=none
TEST=make -j runtests
Change-Id: I682c14ddfe729984f2629dfbe66750e5cd5ab75e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/272541
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This is necessary for the next change, which adds keyblock hash checking.
Also clean up some other assorted comments, and move the diagnostic
check of root key to see if it's the checked-in one earlier in
firmware preamble validation so it's closer to where the root key is
loaded.
No functional or higher-level API changes; just shuffling around code
under the covers.
BUG=chromium:487699
BRANCH=none
TEST=make -j runtests
Change-Id: Ibc3960a4d882dc2ad8684e235db4b9d066eac080
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/272223
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This also checks that the bootloader and vmlinuz headers, if present,
are within the signed part of the kernel blob; the vboot1 routines
didn't do that. That wasn't harmful at firmware boot time because the
vboot1 routines would only load as much data as was signed, but in
vboot2 loading the kernel data is the responsibility of the caller so
we need to check.
BUG=chromium:487699
BRANCH=none
TEST=make -j runtests
Change-Id: I73eb4831e5d3d7a642b6cb85cb55857d87fcc0af
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270797
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>
Looks like the DISABLE_FW_ROLLBACK_CHECK GBB flag (0x200) was forgotten
in the vboot2 implementation. It's too late for Veyron now, but let's at
least fix it for future devices.
BRANCH=none
BUG=None
TEST=make runtests
Change-Id: I867f7aada28be3897efda73a6bdc3b0848c23dca
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/271419
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Older GBB headers (e.g. 1.0 and 1.1) do not have hwid_digest. In such cases,
PCR1 is currently extended from 0, causing a remote attestation failure.
This change makes all GBB headers older than 1.2 incompatible.
BUG=none
BRANCH=tot
TEST=make -j runtests
Change-Id: I7a3b19c2da325a3fa4b9c1fe06ed6f43cb51fb9e
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270796
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This patch fixes what I think is an inconsistency in the existing legacy
boot behavior: when the GBB flag that defaults to legacy boot is set,
running out the 30 second timer would still boot legacy mode even if
dev_boot_legacy is not actually set (whereas pressing CTRL+L in the
same configuration would beep and refuse).
This patch makes both legacy boot trgiggers check the same condition
before boot. This does not restrict functionality since anyone who sets
the DEFAULT_DEV_BOOT_LEGACY GBB flag could simply set
FORCE_DEV_BOOT_LEGACY at the same time. It does however open up an
interesting new use case of using NVRAM to change back-and-forth between
legacy and normal developer mode (after GBB flags are changed once and
write-protection is enabled again).
If this is updated in the field it might lock existing devices out of
legacy mode... however, since by far the most common GBB flag
combination recommended on the internet seems to be 0x489 (including
FORCE_DEV_BOOT_LEGACY), I doubt this would be a problem in practice.
BRANCH=tbd
BUG=chrome-os-partner:39999
TEST=Booted with GBB flags 0x4b9 and 0x439, observed difference.
Change-Id: If6a6d99ab2cf116db2237fdc3df97fc22a68251c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270182
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Even though legacy boot is an unsafe mode that has to be manually
initiated by the user, we should still lock the kernel TPM space to be
consistent with existing developer mode practice.
BRANCH=tbd
BUG=chrome-os-partner:39999
TEST=Spent over an hour unsuccessfully trying to get SeaBIOS to boot a
Chromium test image on my Falco. Decided that's not worth it an just
tested the firmware side of this (pressing CTRL+L when legacy mode is
enabled and disabled, multiple times, with and without GBB flag
DEFAULT_DEV_BOOT_LEGACY).
Change-Id: I3b02b59a9055431d222c0c7446de2cd7d2e0bb82
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270181
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
And add a vb2_digest_buffer() call which produces the hash of a buffer
all in a single function call. That function actually already
existed, but was in a unit test file rather than in the library
itself. It's a small function, so adding it won't increase the size
of the library significantly - or at all, on platforms which compile
with -ffunction-sections.
This allows coreboot to reuse this SHA library for hashing CBFS
entries and file data. All it has to do is #define
NEED_VB2_SHA_LIBRARY and then #include "vb2_api.h".
BUG=chromium:482652
BRANCH=none
TEST=make -j runtests
Change-Id: Ice2d0929324b58b2665f3989b5b887225f6ef61e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/269523
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is done to break a circular DEPENDency as we want to
send UMA stats from tcsd. Without this, metrics depends on
vboot_reference which depends on trousers which depends on
metrics. Technically the vboot_reference dependency on trousers
is header-file only, but we can't cope with that.
BUG=chromium:481552
TEST=compiled with emerge-<something> vboot_reference
BRANCH=none
Change-Id: Iea5c0c39bb70977c9d375e63ea607687debe9f9f
Reviewed-on: https://chromium-review.googlesource.com/267744
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
When a read fails in getting the GPT, just zero the contents of the
buffer and carry on.
Some testing changes are required for this. When a read of the GPT
fails, it is no longer fatal, so tests of that have been adjusted.
Tests have been improved to show that the GPT is automatically
repaired when a read error occurs.
There was one test which checked that a zero-sized disk would fail
to load a kernel, but it was surrounded by a number of mocked
functions which normally do that error checking, and it amounted
to the same test as read failure; that test was deleted.
BUG=chrome-os-partner:35440
TEST=vboot tests pass
BRANCH=none
Change-Id: I0c05813e7492920433733947d3fb74a7e4aa66f2
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266882
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Recent experience shows that users often get confused and try running
pre-mp signed images under dev firmware control and vice versa. The
matters are further aggravated by the fact that the signage mismatch
is allowed when the device is in dev mode and not in normal mode.
While the users usually can tell what class of keys the Chrome OS
image is signed with, it is much mode difficult to tell what keys the
firmware was signed with.
This patch, reports in the log if the firmware was signed with dev
keys, by comparing the hash calculated over the packed root public key
body with a precompiled value.
A test tweak was required to avoid using uninitialized data.
BRANCH=none
BUG=none
TEST=booted the new code on storm, observed the following message
included in the log:
VB2:vb2_report_key_class() This is developer signed firmware
- verified that 'make run2tests' succeeds in chroot
Change-Id: I97ed6ba384cee59ff3f42943630e92ebae10dd03
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264469
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The USB Type-C chargers released with Samus ("Pixel (2015)") have
upgradable firmware. Those firmware images are currently signed
by some custom scripts. This adds support for those images to
futility, so that those custom scripts can be replaced.
Note that due to space considerations, the usbpd firmware images
don't have room for handy things like an FMAP or headers for the
signatures. Accordingly, all the normally variable factors (image
size, signature algorithms, etc.) are hard coded and the image
itself just looks like a bunch of random numbers. Because of
this:
1. There's no way to recognize this type of file, and nothing to
display about it.
2. You have to give the "--type usbpd1" arg to the sign command.
3. I'm designating this file type "v1" because I hope that the
firmware for any future adapters will be more readily
identifiable.
BUG=chromium:231574
BRANCH=none
TEST=make runtests
This adds a new test that signs usbpd1 firmware images using
futility, and compares the result to the same files signed by the
custom scripts, ensuring that they are bitwise identical.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Idbe061db5b3c8e474ada47b40bcbe04bbecdba3a
Reviewed-on: https://chromium-review.googlesource.com/262899
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This allows the user to manually specify the type of an input
file, since not all file types can be reliably identified.
This also adds a test to ensure that futility doesn't coredump if
you give it the wrong type (although I'm sure it's not exhaustive).
BUG=chromium:231574
BRANCH=none
TEST=make runtests
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I9d909305d9989fe7299e744c585de380109cf8cd
Reviewed-on: https://chromium-review.googlesource.com/262895
Reviewed-by: Randall Spangler <rspangler@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>
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 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 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 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>
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>
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>
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>
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
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>
This patchs adds a new vb2_shared_data field to store the current
rollback prevention version number stored in secdata (TPM). This
information needs to be retrieved from there by coreboot (current
hack) or vboot2 kernel verification (bright shiny future) so it can be
passed along to the operating system and user space.
BRANCH=veyron
BUG=chrome-os-partner:35941
TEST=make runtests. Booted Jerry in recovery mode (with corresponding
coreboot patch), ensured that crossystem tpm_fwver still shows the
correct value.
Change-Id: I2a0c3e51b158a35ac129d2abce19b40c6c6381a6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244601
Reviewed-by: Randall Spangler <rspangler@chromium.org>
this api allows firmware to get the digest indicating boot mode status.
BUG=chromium:451609
TEST=VBOOT2=1 make run2tests
BRANCH=tot
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Idca7bc5f6aed947689ad7cf219805aad35047c7d
Reviewed-on: https://chromium-review.googlesource.com/244542
The vb2_verify_fw command is used only in a host-side test. It
doesn't need to be built into futility. This makes it a separate
executable used just for that test.
BUG=chromium:231547
BRANCH=none
TEST=make VBOOT2=1 runtests
Note that tests/vb2_firmware_tests.sh still passes, now using an
external vb2_verify_fw executable instead of a futility command.
Change-Id: Iee58df065e7a762369c5e691f6c2093de9122ed2
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243630
We were assuming 8-byte alignment for buffers. That's not true on
32-bit architectures. We should make the alignment requirements
explicit (and correct) for all architectures.
BUG=chromium:452179
BRANCH=ToT
CQ-DEPEND=CL:243380
TEST=manual
USE=vboot2 FEATURES=test emerge-x86-alex vboot_reference
Change-Id: I120f23e9c5312d7c21ff9ebb6eea2bac1e430e37
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243362
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>
The verify_kernel command is used only in a host-side test. It
doesn't need to be built into futility. This makes it a separate
executable used just for that test.
BUG=chromium:231547
BRANCH=none
TEST=make runtests
Note that the load_kernel_tests.sh still passes, using the
external verify_kernel executable.
Change-Id: I309d2561d65af7eb4f3708e9bc024852238deeec
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235480
Reviewed-by: Randall Spangler <rspangler@chromium.org>
