History log of /external/vboot_reference/tests/vboot_api_firmware_tests.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
f4f395e1ca724ef8795cfe86a9edbf15f14eacd1 23-Oct-2014 Bill Richardson <wfrichar@chromium.org> Extend HWID digest into PCR1 (GBB v1.2 only)

GBB header v1.2 adds a digest of the HWID string to the blob (and
maintains it when updated with the current futility/gbb_utility).

This CL causes VbSelectFirmware() to extend PCR1 with that HWID
digest (only for GBB header v1.2 and later, of course).

Tests are updated.

This also adds a "pcr" command to futility to help determine that
the change is working on the hardware (adds 4K bytes or fewer to
the size of the executable).

BUG=chromium:415714
BRANCH=ToT (and maybe others?)
TEST=make runtests, manual install on HW

To test on hardware, build and update a system with this change
(both the disk image and the RO firmware).

NOTE: The BIOS image must be built in a chroot that is using the
current version of futility. You may need to update your chroot
if your BIOS image still produces v1.1 GBB headers. Check with:

futility show <firmware_image.bin> | grep -B1 'digest:'

Boot the new system with a new test image, then follow these steps:

Read the BIOS:

# flashrom -r /tmp/bios.bin

Make sure the GBB has a valid digest for the HWID.

# futility show /tmp/bios.bin | grep -B1 'digest:'
HWID: SAMUS TEST 8028
digest: 4172d24f40bf72cc0ab8... <valid>
#

Extract only the sha1sum-sized part of the HWID digest:

# futility show /tmp/bios.bin | awk '/digest:/ {print $2}' | colrm 41
4172d24f40bf72cc0ab878b4c589b8fe9cf4405e
#

Simulate extending that value in a PCR using the futility "pcr"
command:

# futility pcr 4172d24f40bf72cc0ab878b4c589b8fe9cf4405e
PCR: 0000000000000000000000000000000000000000
+ 4172d24f40bf72cc0ab878b4c589b8fe9cf4405e
PCR: b6e5ffd2d898a7b15236ad22ca25f53ac1f40776
#

Finally, look at the value of PCR1. It should match the last line
of the futility pcr output:

# head /sys/class/misc/tpm0/device/pcrs | grep PCR-01
PCR-01: B6 E5 FF D2 D8 98 A7 B1 52 36 AD 22 CA 25 F5 3A C1 F4 07 76
#

Change-Id: I09cf855f1a24616cc1a9ddb676670edbc76827d2
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226408
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/tests/vboot_api_firmware_tests.c
2500185a83b453580f187087fffc6376f19f8ff0 16-Aug-2013 Simon Glass <sjg@chromium.org> Add memory leak checking

Add checks that the vboot library does not leak memory. This works by
tracking VbExMalloc() calls and making sure that they have an associated
VbExFree().

Adjust host_signature to use VbExFree() instead of free(), so that this
scheme works correctly for existing code.

BUG=chrome-os-partner:21115
BRANCH=pit
TEST=FEATURES=test emerge-peach_pit vboot_reference

Change-Id: I6ccccfbcc162fc43fb75862cd0eddad78ce8b18a
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/66175
/external/vboot_reference/tests/vboot_api_firmware_tests.c
527ba810eff4006cf69579f6b96cb4350cb1e189 25-Jul-2013 Simon Glass <sjg@chromium.org> Implementation of Region API

At present reading data from storage in Vboot is a little fragmented. For
the firmware image, we expect the boot loader to handle this. For the disk
we have a block-level API. For the GBB (which also sits in the firmware
image) we expect the entire thing to be read before Vboot is called.

Add the concept of a region, and an API to read from a region. At present,
and most pressing, is reading from a GBB region. In the future this could
be extended to other parts of the firmware or even the disk.

Move all access to the GBB into this API so that the boot loader can provide
either a GBB region in one large contiguous chunk, or a function to deal with
read requests from vboot.

The call to VbExRegionRead() is behind a flag since not all boot loaders
support it yet.

The main change for boot loaders which don't support this new API is that
vboot will do more behind the scenes. For example, it will allocate memory
for chunks of data that it reads from the GBB, rather than just accessing it
directly. This approach is considerably simpler than trying to pass char **
everywhere and have vboot decide whether something needs to be allocated or
not.

The tests are updated, mainly to include setting up a GBB structure
accessible from VbCommonParams, which is now required by the firmware and
kernel functions. In normal operation this is set up at the start of
VbLoadFIrmware() and VbSelectAndLoadKernel() but for tests which call
children of these functions directly, the GBB structure must be set up
manually by the test.

BUG=chrome-os-partner:21115
BRANCH=none
TEST=manual
FEATURES=test sudo -E emerge vboot_reference

Change-Id: If2b8bbe467fdbd643239d8d9b5d7aa98df4d286f
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/63336
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167361
/external/vboot_reference/tests/vboot_api_firmware_tests.c
8fa13ad6f727d44fdc0ae1d2bde5f54b32dab9b9 29-Aug-2013 Yoshiki Iguchi <yoshiki@chromium.org> Revert "Implementation of Region API"

This reverts commit 1d3c804b6b9d2ffb6953a7ee98fabfd548915ad7.

This patch breaks cbuildbot on internal paladins bots.

Change-Id: Icf7f9d9bbb56b092035888eaa3e249ffd23fac16
(cherry picked from commit 3a60335ebb1530e5fd9d5da3bc6214949bc59caf)
Reviewed-on: https://chromium-review.googlesource.com/167451
Reviewed-by: Yoshiki Iguchi <yoshiki@chromium.org>
Commit-Queue: Yoshiki Iguchi <yoshiki@chromium.org>
Tested-by: Yoshiki Iguchi <yoshiki@chromium.org>
/external/vboot_reference/tests/vboot_api_firmware_tests.c
1d3c804b6b9d2ffb6953a7ee98fabfd548915ad7 25-Jul-2013 Simon Glass <sjg@chromium.org> Implementation of Region API

At present reading data from storage in Vboot is a little fragmented. For
the firmware image, we expect the boot loader to handle this. For the disk
we have a block-level API. For the GBB (which also sits in the firmware
image) we expect the entire thing to be read before Vboot is called.

Add the concept of a region, and an API to read from a region. At present,
and most pressing, is reading from a GBB region. In the future this could
be extended to other parts of the firmware or even the disk.

Move all access to the GBB into this API so that the boot loader can provide
either a GBB region in one large contiguous chunk, or a function to deal with
read requests from vboot.

The call to VbExRegionRead() is behind a flag since not all boot loaders
support it yet.

The main change for boot loaders which don't support this new API is that
vboot will do more behind the scenes. For example, it will allocate memory
for chunks of data that it reads from the GBB, rather than just accessing it
directly. This approach is considerably simpler than trying to pass char **
everywhere and have vboot decide whether something needs to be allocated or
not.

The tests are updated, mainly to include setting up a GBB structure
accessible from VbCommonParams, which is now required by the firmware and
kernel functions. In normal operation this is set up at the start of
VbLoadFIrmware() and VbSelectAndLoadKernel() but for tests which call
children of these functions directly, the GBB structure must be set up
manually by the test.

BUG=chrome-os-partner:21115
BRANCH=none
TEST=manual
FEATURES=test sudo -E emerge vboot_reference

Change-Id: I2c19e9dc2ed602d0642bbf4f7d27f79fe9fad873
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/63336
Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/tests/vboot_api_firmware_tests.c
0c3ba249abb1dc60f5ebabccf84ff13206440b83 29-Mar-2013 Bill Richardson <wfrichar@chromium.org> Massive refactoring of external header files.

This reduces the number of exported header files to the minimum needed by
the existing userspace utilities and firmware implementations.

BUG=chromium:221544
BRANCH=none
TEST=manual, trybots
CQ-DEPEND=CL:47019,CL:47022,CL:47023

sudo FEATURES=test emerge vboot_reference
FEATURES=test emerge-$BOARD \
vboot_reference \
chromeos-cryptohome \
chromeos-installer \
chromeos-u-boot \
peach-u-boot \
depthcharge

Change-Id: I2946cc2dbaf5459a6c5eca92ca57d546498e6d85
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47021
Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/tests/vboot_api_firmware_tests.c
ac8805e7e9bd40c03baf44e37b26f28d9b763ab5 16-Mar-2013 Gabe Black <gabeblack@chromium.org> Get rid of some crufty macros.

These were macros that were never used, or that were only set to one thing and
could be substituted up front.

I left in code guarded by the HAVE_ENDIAN_H and HAVE_LITTLE_ENDIAN macros even
though those are never defined because they guard a reportedly significantly
faster implementation of some functionality, at least according to a comment
in the source. It would be a good idea to enable that code path and see if it
really does make a big difference before removing it entirely.

BUG=None
TEST=Built for Link, Daisy, and the host with FEATURES=test. Built depthcharge
for Link and booted in normal mode.
BRANCH=None

Change-Id: I934a4dd0da169ac018ba07350d56924ab88b1acc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/45687
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
/external/vboot_reference/tests/vboot_api_firmware_tests.c
640b1c420748049c796b3f9d59406e38ff8f4774 22-Nov-2012 Bill Richardson <wfrichar@chromium.org> Add more recovery_reason codes

There are several places where the same recovery_reason was used to report
slightly different points of failure. Let's create some new codes instead.

Remember that recovery mode is handled by RO firmware, so if an updated RW
firmware uses one of the new error codes, pressing TAB at the recovery
screen will say "We have no idea what this means". That's not a bug. This CL
deprecates the original codes, so the fact that the RO firmware doesn't
recognize it just means it's a new code reported by a new RW BIOS.

BUG=chromium-os:36562
TEST=manual
BRANCH=parrot

Run

make && make runtests

It should pass. You can test some of the error cases on actual hardware by
using

crossystem recovery_reason=86
reboot

and pressing TAB at the recovery screen. For that example you should see the
message

recovery_reason: 0x56 TPM lock error in rewritable firmare

Change-Id: I123c781e6c6f6fe0284c4fd49f5f5a855eece7df
Reviewed-on: https://gerrit.chromium.org/gerrit/38652
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/tests/vboot_api_firmware_tests.c
b75d8adcc01f08cf5a6d87b78aeb1d7cdfcd22af 17-May-2012 Bill Richardson <wfrichar@chromium.org> Use virtual dev-mode switch when told to.

If VbInit() is instructed to look at a virtual dev-mode switch, then it will
use value contained in the TPM's firmware space instead of a hardware GPIO
to determine if developer mode is enabled.

This change just makes it look. It doesn't provide a way to actually set
the value in the TPM. VbInit() isn't being told to look yet, either. Those
changes are coming.

BUG=chrome-os-partner:9706
TEST=none

The usual sanity-check applies:

make
make runtests

But to actually test that this stuff is working IRL requires special tweaks
to other components and monitoring the serial debug output from both EC and
CPU. We'll save the hands-on tests for when it's all done.

Change-Id: Ie485ad2180224e192238bf2a5dbf95bbcb9130f9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/23067
Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/tests/vboot_api_firmware_tests.c
e339cbacef5cab487e2a2c4718376579d99c9b55 09-Sep-2011 Randall Spangler <rspangler@chromium.org> Add unit tests for vboot_api_firmware.c

BUG=chromium-os:17564
TEST=make && make runtests

Change-Id: I030c204527e1c17b8d6523beec3b7604a638fc98
Reviewed-on: http://gerrit.chromium.org/gerrit/7444
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/tests/vboot_api_firmware_tests.c