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>
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>
This structure, like RollbackSpaceFirmware in my previous CL, contains members
that are inherently unaligned. This breaks when the machine running vboot
cares about alignment. Like before, I'm using Memcpy to avoid the direct
unaligned accesses.
BUG=chrome-os-partner:17340
TEST=Built and booted into depthcharge on Snow. Without this change, there's
an unaligned access in RollbackKernelRead. After this change, the unaligned
access goes away and vboot gets at the kernel version successfully.
BRANCH=None
Change-Id: Ifcdcee1ab4bbce74d05e563cb82bef73a1aa9a84
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/44503
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This structure has two uint8_t members and then fw_versions which is a
uint32_t. That means that fw_versions is 32 bits wide but only has 16 bit
alignment, and architectures that care about that sort of thing won't be able
to access it. ARM generally cares about alignment, but there's a bit which
lets you select whether 32 bit accesses can be unaligned. In the past this bit
was ignored, and because this is a 32 bit data type the right load happened to
be used.
To avoid the unaligned access all together, this change makes vboot use Memcpy
to access fw_versions. The number of accesses should be very small so the
overhead should be minimal.
BUG=chrome-os-partner:17340
TEST=Built and booted depthcharge on Snow. Without this change, there was an
unaligned exception during SetupTPM when the fw_versions member was accessed
as part of a VBDEBUG call. With this change, the exception went away and the
TPM was initialized successfully.
BRANCH=None
Change-Id: I1ed705f2de450c65f986c1c7ba30da15c0150f74
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/44499
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The rollback_index.c file uses a macro RETURN_ON_FAILURE which creates
a locally block-scoped variable named 'result'. However, when built with
-Wshadow -Werror the compile will break because the 'result' variable
will shadow the one function scoped variable. Fix this warning by
changing the variable name from 'result' to 'result_' in
the RETURN_ON_FAILURE macro.
BUG=chrome-os-partner:17695
BRANCH=None
TEST=built fwlib with -Werror -Wshadow. Compiles correctly.
runtests still passes as well.
Change-Id: I9fedef5567411beacdc1c0b8ed182573601f24aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44044
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When the fwlib is built with -Wmissing-prototypes and -Werror
there build breakages that occur. Fix these errors by either
including the header file with the correct declaration or provide
the declaration at the top of the c files for global symbols that
are used by tests.
BUG=chrome-os-partner:17695
BRANCH=None
TEST=built fwlib library with -Wmissing-prototypes and -Werror. Also
'make runtests' still passes.
Change-Id: I992516ee2545509054887173bc65234905381e06
Signed-off-by: Aaron Durbin
Reviewed-on: https://gerrit.chromium.org/gerrit/44042
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-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
This reverts commit 552ae43be0.
vboot should set up dev switch value in output flag of VbInit, instead
of exposing TPM getter to U-Boot.
BUG=chrome-os-partner:10947
TEST=build okay for Snow and Alex
Change-Id: Iee884dbf758fef0cacfed6bcbab373ab5ec5aa25
Reviewed-on: https://gerrit.chromium.org/gerrit/26556
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Firmware needs to be able to read virtual dev switch to set up device
tree blob which is passed to kernel and eventually read by crossystem.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BUG=chrome-os-partner:10947
TEST=With this change, U-Boot can read virtual dev switch.
Change-Id: Ifac2ec3d39b8e9c1100031fdef085c28bb8b37c7
Reviewed-on: https://gerrit.chromium.org/gerrit/26394
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
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>
BUG=chrome-os-partner:9706
TEST=none
No test yet. The entire boot/dev-mode/recovery flow depends on this working.
This is only part of the process, which will eventually be tested through
FAFT.
Change-Id: Iea6eaf59d4f349590cf9b920e4effb6a2641b2dc
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/23657
Reviewed-by: Randall Spangler <rspangler@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>
BUG=chrome-os-partner:9707
TEST=manual
make
make runtests
You can also test it by clearing the TPM, then manually looking at the TPM
regions. In dev-mode, clear the regions and you'll see something like this:
localhost ~ # tpmc read 1007 a
1 0 0 0 0 0 0 0 0 0
localhost ~ # tpmc read 1008 d
1 4c 57 52 47 0 0 0 0 0 0 0 0
localhost ~ #
Go back to normal mode and reboot, and you'll see something like this:
localhost ~ # tpmc read 1007 a
2 0 1 0 1 0 0 0 0 4f
localhost ~ # tpmc read 1008 d
2 4c 57 52 47 1 0 1 0 0 0 0 55
localhost ~ #
The important things are that the first number is now 2, instead of 1, and
the last number is not zero (it's a checksum, so it'll vary depending on the
other numbers, which will themselves vary according to the firmware and
kernel versions).
Change-Id: Ia4040311c2a4b2819792549b883377c8b6b89d48
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/22856
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>
Third time's the charm. Now that we've moved to u-boot-next, this
won't break the ARM build.
BUG=chromium-os:17006
TEST=make && make runtests; emerge vboot_reference; emerge-tegra2_seaboard chromeos-bootimage
Change-Id: Ib4fa26c7a23868dd2ffd2b321ee8dc08c66ea322
Original-Change-Id: I771085dcdf79d9592de64f35e3b758111a80dd9f
Original-Reviewed-on: http://gerrit.chromium.org/gerrit/3263
Original-Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/3803
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
With this change, the firmware creates and initializes the kernel space first,
then the firmware space. Thus, if the initialization is interrupted (by
cutting power) in between the two spaces, at the next boot the initialization
path will be taken again, since it is triggered by a missing firmware space.
A space creation succeeds when the space already exists (the space is
removed and recreated), so this eliminates two races. There is still
the possibility that the power is cut between creating the firmware
space and initializing it, but let's assume it's not a problem until
proven otherwise. (It won't be a security problem anyhow.)
BUG=chromium-os:17049
TEST=none (too hard to reproduce the race)
Change-Id: Iae4c1cc2b9a5056cb5d858e71b680e27a442357e
Reviewed-on: http://gerrit.chromium.org/gerrit/3520
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
This reverts commit 0184886c8cb35e8e01d610622df448a7cb063e06
(This works with uboot-next, but not uboot, which doesn't implement its half of the new wrapper API. So rolling back to leave uboot working.
Change-Id: I1f9e3c63e5bbdb20b9195cd68787bef89f24afee
Reviewed-on: http://gerrit.chromium.org/gerrit/3588
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
This is part 3 of the vboot wrapper API refactoring. It replaces the
function calls to utility.c functions with new API calls. (It also
fixes up some integer type mismatches in cryptolib that were causing
warnings on the H2C build; those had been fixed a while ago in H2C but
hadn't been propagated across.)
This is a re-commit of the original; I've verified it compiles on both
x86-alex and tegra2, for both vboot_reference and
vboot_reference-firmware, now that the patch from
1c1a883bc7 is checked in.
BUG=chromium-os:17006
TEST=make && make runtests, and emerged on both x86-alex and tegra2
Original-Change-Id: I771085dcdf79d9592de64f35e3b758111a80dd9f
Original-Reviewed-on: http://gerrit.chromium.org/gerrit/3263
Original-Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit bd81b3a7d3)
Change-Id: Iefdbfb3d10eb9aa385fb6dfc3bf0896f637cb64b
Reviewed-on: http://gerrit.chromium.org/gerrit/3582
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
This is part 3 of the vboot wrapper API refactoring. It replaces the
function calls to utility.c functions with new API calls. (It also
fixes up some integer type mismatches in cryptolib that were causing
warnings on the H2C build; those had been fixed a while ago in H2C but
hadn't been propagated across.)
BUG=chromium-os:17006
TEST=make && make runtests
Change-Id: I771085dcdf79d9592de64f35e3b758111a80dd9f
Reviewed-on: http://gerrit.chromium.org/gerrit/3263
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
This is a temporary workaround for Tegra boards that don't reset the TPM
when the CPU is reset. It makes the firmware more lenient when execution
starts with an already locked TPM.
BUG=chromeos-partner:3574
TEST=none (yet)
Change-Id: If6a060595c1eb41e95e0935f8467de8bb6256b12
Reviewed-on: http://gerrit.chromium.org/gerrit/1429
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Nick Sanders <nsanders@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
TlclStubInit, TlclCloseDevice, and TlclOpenDevice were void functions but
should return error codes.
BUG=chromium-os:6695
TEST=RUNTESTS=1 make && emerge successfully
Review URL: http://codereview.chromium.org/5796005
Change-Id: I8ddbf8b1f080d98ff6ed42c4a675fbda5b17eef1
Change-Id: Ib12405f968af11ad75a6429ae9ebe502dde5bf92
BUG=chrome-os-partner:1591
TEST=make && make runtests
(This is already in the firmware; I'm just copying it back into vboot reference)
Review URL: http://codereview.chromium.org/5312003
Change-Id: I3f18081bda888a0fa6f56a67d0cef17268014706
BUG=chromium-os:6714
TEST=manual by enabling ROLLBACK_TPM in firmware/Makefile (did not test by compiling under MSVC)
Review URL: http://codereview.chromium.org/3973001
Change-Id: I4785a6326017c63d83a8eb153d6b90ee82e5f839
BUG=chromeos-partner:222
TEST=manual (build FW, make sure system boots and tpmc prints good values)
Review URL: http://codereview.chromium.org/3367020
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
