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>
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
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>
SetupTPM no longer uses recovery_mode parameter for anything other than
a debug print. This change moves the debug print to a caller function,
then removes recovery_mode from SetupTPM and some caller functions that
no longer have a use for it.
BUG=chrome-os-partner:20913.
TEST=Manual. Boot factory install shim in recovery mode and verify TPM
clear operations succeed. Boot in dev mode and verify "Lock physical
presence" print on UART.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I2f671f6680a6e67cf722855e659e99752bc0783c
Reviewed-on: https://gerrit.chromium.org/gerrit/62916
Reviewed-by: Randall Spangler <rspangler@chromium.org>
RollbackKernelLock previously checked a global to determine recovery
mode state. Since we have two copies of vboot_reference in firmware
(in coreboot and depthcharge), this creates a problem with
synchronization. Remove the global entirely and instead pass the
recovery state to RollbackKernelLock.
BUG=chrome-os-partner:20913.
TEST=Manual. Boot factory install shim in recovery mode and verify TPM
clear operations succeed. Boot in dev mode and verify "Lock physical
presence" print on UART.
BRANCH=FalcoPeppy.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I4e751d4a9ca60cd57c5c662ce86eba595fb22ba2
Reviewed-on: https://gerrit.chromium.org/gerrit/62874
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds two new flags to crossystem:
clear_tpm_owner_request
clear_tpm_owner_done
The first one requests that the firmware clear the TPM owner on the
next boot. When the firmware does this, it will set
clear_tpm_owner_request=0, and set clear_tpm_owner_done=1. The OS can
use the done-flag as a hint that trusted things guarded by the TPM are
no longer trustable.
BUG=chromium-os:31974
TEST=manual
crossystem
// both flags initially 0
crossystem clear_tpm_owner_request=1
crossystem clear_tpm_owner_done=1
// request=1, done=0; done can be cleared but not set by crossystem
reboot
tpmc getownership
// owned=no
crossystem
// request=0, done=1
crossystem clear_tpm_owner_done=0
crossystem
// both flags 0 again
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I49f83f3c39c3efc3945116c51a241d255c2e42cd
Reviewed-on: https://gerrit.chromium.org/gerrit/25646
BUG=chrome-os-partner:9706
TEST=manual
Currently, Link is the only platform that enables this feature.
To enter dev-mode:
Boot into recovery mode using the magic key chord. At the Insert screen,
press Ctrl-D. You'll be asked if you want to enter developer mode. If you
then press ENTER, it will reboot with dev-mode enabled. If you press SPACE
or ESC, it will return to the Insert screen.
If you enter recovery mode through any other means, or if dev-mode is
already enabled, pressing Ctrl-D at the Insert screen will have no effect.
To return to normal mode:
Reboot. At the Dev screen, press ENTER or SPACE. It will reboot to
recovery mode and ask you if you want to return to normal mode. If you
press ESC or power off, you'll still be in dev-mode. Press ENTER or SPACE,
and it will reboot into normal mode (of course, if you've messed up your
images while in dev-mode, you'll just come right back to recovery mode
again).
You can also request a direct return to normal mode by running
crossystem disable_dev_request=1
and rebooting.
Change-Id: I435905855a6c39932ee466cc046bdc4c4c860f98
Reviewed-on: https://gerrit.chromium.org/gerrit/24160
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
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>
Try #2, now that ARM has the fix from http://gerrit.chromium.org/gerrit/4667
This cleans up the TPM calls inside vboot_reference.
* TPM calls share mode code between boot modes.
* Better handling for TPM_E_MUST_REBOOT, particularly in recovery mode.
* TAB screen shows current TPM versions.
No changes required to the wrapper API; these changes are internal to vboot.
BUG=chromium-os:18084
TEST=make && make runtests; built for both alex and tegra2-seaboard
Original-Change-Id: I2a52066f2889210af83409872b10f9d6380470af
(cherry picked from commit da55560cddcf7a1aa8a881cdf52792a21a01e766)
Change-Id: I120797145772116f09b8125b9e56fdbb11dc16b3
Reviewed-on: http://gerrit.chromium.org/gerrit/4671
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This cleans up the TPM calls inside vboot_reference.
* TPM calls share mode code between boot modes.
* Better handling for TPM_E_MUST_REBOOT, particularly in recovery mode.
* TAB screen shows current TPM versions.
No changes required to the wrapper API; these changes are internal to vboot.
BUG=chromium-os:18084
TEST=make && make runtests; built for both alex and tegra2-seaboard
Change-Id: I2a52066f2889210af83409872b10f9d6380470af
Reviewed-on: http://gerrit.chromium.org/gerrit/4611
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
The old (v2.0) parser is compatible with new (v2.1) structs. That is,
this won't break existing firmware or vbutil_firmware.
A new (v2.1) parser parsing an old (v2.0) struct will return 0 for the
flags.
This will be used to support the RO-normal code path in a subsequent CL.
BUG=chromium-os:17304
TEST=added unit tests; make && make runtests
Change-Id: I73bcd8acd3330b0d7d143061b5ef838e6d79cf1a
Reviewed-on: http://gerrit.chromium.org/gerrit/4030
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Pressing Tab at a firmware screen now displays real data, including
the recovery reason, HWID, and contents of VbNvStorage.
Entry point start/end time tracking in VbSharedData now refers to the
new wrapper APIs.
Added capability for calling firmware to request recovery mode (for
example, if it's unable to initialize RAM, can't find the SSD, etc.).
Previously, calling firmware had no (good) way to do this other than
faking the recovery button being pressed.
BUG=chromium-os:17018
TEST=emerge on x86 and tegra2_seaboard
Change-Id: I7d377f279842b30a10d945d13571c41c464633f1
Reviewed-on: http://gerrit.chromium.org/gerrit/3814
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
I re-factored the extend call into its own module, since it doesn't necessarily
need to be couple with rollbackfirmwaresetup.
BUG=chrome-os-partner:2372
TEST=Tried emerge-x86-generic and emerge-arm-generic vboot_reference.
Change-Id: I0d3115b10b686133e63e304570325ebdbd50ae3a
Review URL: http://codereview.chromium.org/6696006
Change-Id: I976c11c82c3d665a4feb88226e919f16c2440f60
BUG=chrome-os-partner:1657
TEST=manual - see below
make && make runtests
Then test verifying a test image in both dev mode (-b1, no key specified) and recovery mode (key specified)
build/utility/load_kernel_test -b1 ~/b/USB_images/0.11.224.0-alex/chromiumos_test_image.bin
build/utility/load_kernel_test ~/b/USB_images/0.11.224.0-alex/chromiumos_test_image.bin tests/devkeys/recovery_key.vbpubk
And make sure the firmware with this change actually boots to USB and SSD.
NOTE: u-boot-next needs to change to work with this change. will attempt a follow-up CL with that change
Review URL: http://codereview.chromium.org/6626045
BUG=2083
TEST=manual
Compiled with DISABLE_ROLLBACK unset. I need help testing this change - in particular, if the PCR 0 value is actually different in dev mode off vs. dev mode on. This can be done by invoking 'tpm_pcrread -p 0' at the shell. tpm_pcrread is part of the tpm_tools package.
Change-Id: I0728fb776a0c9cb90d885e7a1c76ff6a1a41a17b
Review URL: http://codereview.chromium.org/3195018
Changed TlclRead / TlclWrite to take void* / const void* to reduce typecasts.
Much restructuring of rollback_index.c.
Fixed a version-packing bug in rollback_index.c (& --> |)
BUG:chrome-os-partner:304
TEST:manual testing of all code flows on CRB
Review URL: http://codereview.chromium.org/3084030
Also renamed verify preamble functions, now that they do not need the
'2' at the end to differentiate them from the now-deleted original
implementation.
BUG=4501
TEST=Ran make runtests; all pass.
Review URL: http://codereview.chromium.org/3027009
This code compiles and installs using a modified ebuild (which needs to be committed after this change).
Review URL: http://codereview.chromium.org/2857030
