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
|