This is immediately needed to debug a Parrot TPM problems, but
we've had similar situation in the past and probably will again
in the future.
BUG=chromium-os:37819
TEST=manually tested with a couple of different packets, and error inputs
BRANCH=none
Change-Id: Id7f66bdbdfe5887fa49cd62af4a9b807fa3d9a89
Reviewed-on: https://gerrit.chromium.org/gerrit/41166
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
This just adds a one-byte field in the nvstorage region for use in debugging
hard-to-catch errors. There's no official meaning or expectation for this
field. It's just a handy place to emit some information.
BUG=chrome-os-partner:11534
BRANCH=parrot
TEST=manual
Just change the value and ensure that it persists across a (working) reboot.
It's only updated at specific points under very exacting error conditions,
so all we really want to test is that it works as a place to store some
extra info.
crossystem recovery_subcode
crossystem recovery_subcode=14
reboot
crossystem recovery_subcode
The recovery_subcode byte is at index [6] of the VbNv.raw bytes that appear
when you press TAB, so you can find it there too:
VbNv.raw: 60 20 00 00 00 00 0e 00 00 00 00 00 00 00 00 65
Decimal 14 == 0x0e
Change-Id: I1930b8f81a03ab838dbee99a8d72c35a444efdfd
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39803
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If there were any errors communicating with the TPM at the OS layer
(open, read, write failures), the library would immediately exit, not
allowing the caller to make any decisions about how to handle it. This
introduces a way to initialize the library so that errors will get passed
back up to the caller instead of unceremoniously exiting.
Setting the environment variable "TPM_NO_EXIT=1" enables the feature. To
avoid needing to implement supporting functions in all backends, the
feature is currently limited to just the Tlcl stub implementation.
In the case of mount-encrypted, it can now survive the kernel returning
read/write failures. In the past it had only worked around having open
fail, but that has now been replaced with more sensible logic instead of
the environment variable trickiness.
BUG=chrome-os-partner:15960
TEST=daisy built with an always-failing kernel driver, u-boot builds too
BRANCH=None
Change-Id: Ic7b217017537980f9c239d678067398613045676
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38791
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
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>
The TPM on snow devices may boot in an unusable state. The workaround
is to detect this early and reboot. The workaround code prevents
an infinite reboot loop by counting the number of reboots and entering
recovery mode with this reason after a small threshold has been reached.
BUG=chromium:156655
TEST=no test! Not even compiled!
BRANCH=none
Change-Id: Ica2f14f8f7df8c46b7cbe5dbd578ba93c8f3a78c
Reviewed-on: https://gerrit.chromium.org/gerrit/36790
Tested-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Luigi Semenzato <semenzato@chromium.org>
While not having a TPM was supported for non-Chrome devices, it was not
expected for Chrome devices. This adds logic to fail the TPM calls
before making them when the TPM is missing. The tpm_lite library doesn't
handle the TPM being missing, so we have to do this ourselves.
BUG=chrome-os-partner:15192
TEST=parrot build, verified operation after "mv /dev/tpm0 /dev/tpm0.bak"
BRANCH=none
Change-Id: I2f625305dce7fa698fcad33e412ee37c60da9bc2
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35440
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
This option is disabled per default and can be enabled with
crossystem dev_boot_legacy=1
or by setting the GBB flag
GBB_FLAG_FORCE_DEV_BOOT_LEGACY 0x00000080
BUG=chrome-os-partner:6108
TEST=crossystem dev_boot_legacy=1
boot to dev mode screen, press CTRL-L, see SeaBIOS start
(other CLs needed)
BRANCH=link
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Change-Id: I593d2be7cff5ca07b8d08012c4514a172bd75a38
Reviewed-on: https://gerrit.chromium.org/gerrit/31265
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
This enum seems partially complete, and not used in vboot_reference.
Complete it and use it.
BUG=chrome-os-partner:13492
BRANCH=snow
TEST=manual
Build and boot through to recovery on snow. Run through the various
screens and check that they still appear correctly.
Change-Id: Ifca54d072457d9a0396a38026f44f8334efb9cf5
Reviewed-on: https://gerrit.chromium.org/gerrit/32628
Reviewed-by: Mike Truty <truty@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Simon Glass <sjg@chromium.org>
We have to define the function we need here, so that we can implement it in
U-Boot, then we can come back here and try to use it. Grr.
BUG=chrome-os-partner:11215
BRANCH=link
TEST=none
This just defines the function prototype. No change to test.
Change-Id: I38a19baa54c59c9744d20f743eb53260f2d19852
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31658
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We need to know not only whether the HW WP pin is asserted, but whether the
flash chip has configured its software protection registers to actually
protect anything. This flag can be used to indicate that.
BUG=chrome-os-partner:13265
BRANCH=link
TEST=none
This just adds the flag. Nothing actually sets the flag yet, so there's
nothing to test.
Change-Id: Icba9945fb56eb3a4681486c630cbbdc9232485ef
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31642
Reviewed-by: Randall Spangler <rspangler@chromium.org>
At DEV screen:
- Space triggers TONORM
- Enter is ignored unless new GBB flag is set
At TONORM screen:
- Enter always means YES
- Space is ignored
So, if you hold the space key at the dev screen, you'll go to tonorm
and stay there until you press Enter or Esc. If you hold the Enter
key at the dev screen, nothing will happen.
Add a GBB flag to allow Enter to trigger the TONORM screen; this will
be used by FAFT testing.
BRANCH=all
BUG=chrome-os-partner:12699
TEST=manual
1. press enter at dev screen. nothing happens.
2. press space at dev screen. tonorm.
3. press space at tonorm. nothing happens.
4. press enter at tonorm. turns off dev mode.
Change-Id: I9f3128d5114e1486911cc4d76d0ccd5649de1680
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30456
Reviewed-by: Tom Wai-Hong Tam <waihong@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
We need to alert user his change has been accepted for 5 seconds.
BUG=chrome-os-partner:11078
TEST=emerge-daisy vboot_reference-firmware vboot_reference chromeos-u-boot chromeos-boogimage
Change-Id: I6a3b13e7543479fbd6543d759093ecf501fb1d04
Reviewed-on: https://gerrit.chromium.org/gerrit/29982
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Some EC's are slow to program their firmware. This could happen at any boot
as part of software sync. This adds the VB_INIT_FLAG_EC_SLOW_UPDATE input
flag to VbInit(), so that vboot knows to display the EC-is-being-programmed
screen when that flag is set.
BUG=chrome-os-partner:12255
TEST=none
This isn't activated yet by anything, so there's nothing to test.
Change-Id: Id4d12e463fcdee017b7c52b53a2facefc33b745f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29370
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is more reliable than reading them through FDT/ACPI, since it reflects
the positions as shown to verified boot code.
Notes:
1. This affects ALL platforms with virtual dev switches (x86 AND arm)
2. The fix should have no effect on older platforms, but I haven't tested those.
BUG=chrome-os-partner:11805
TEST=manual
1. boot in normal mode.
devsw_boot = 0 # Developer switch position at boot
recovery_reason = 0 # Recovery mode reason for current boot
recoverysw_boot = 0 # Recovery switch position at boot
wpsw_boot = 1 # Firmware write protect hardware switch position at boot
2. boot in developer mode.
localhost ~ # crossystem
devsw_boot = 1 # Developer switch position at boot
recovery_reason = 0 # Recovery mode reason for current boot
recoverysw_boot = 0 # Recovery switch position at boot
wpsw_boot = 1 # Firmware write protect hardware switch position at boot
3. boot in developer-recovery mode using keyboard combo.
devsw_boot = 1 # Developer switch position at boot
recovery_reason = 2 # Recovery mode reason for current boot
recoverysw_boot = 1 # Recovery switch position at boot
wpsw_boot = 1 # Firmware write protect hardware switch position at boot
4. disable WP and reboot. wpsw_boot should be 0.
Change-Id: If4156b5e14c6923c5b331c7e5feaabbffe1dad37
Reviewed-on: https://gerrit.chromium.org/gerrit/29199
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Some systems take a long time to program the EC firmware (because it's
behind a really slow I2C bus or something). This could happen at any boot as
part of software sync. If it's necessary to reprogram the EC on a slow
system, we need to display a BIOS screen to the user so he/she doesn't think
it's bricked.
This CL is just to add a new default bitmap so we'll have something to
display when we need it. Nothing actually uses it yet.
BUG=chrome-os-partner:12254
TEST=none
There should be no user-visible changes. We don't invoke this screen yet.
Change-Id: Icb922f933e2e921472dbdff7a26a3ca4d58fbba3
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29241
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
We're still working out the correct behavior for the keyboard-based
dev-mode. Before this, we rebooted into recovery mode before asking if you
wanted to return to normal mode, so if you said "no, stay in dev-mode" you'd
still be at the recovery screen.
But now the confirmation for returning to normal mode happens at the
dev-mode screen, so you never get to the recovery screen (unless normal mode
won't boot, in which case you get there automatically).
BUG=chrome-os-partner:11707
TEST=manual
First, clear the GBB flags so that you can actually test the virtual dev
switch:
/usr/share/vboot/bin/set_gbb_flags.sh 0
reboot
It should come up in normal mode.
Activate keyboard-based dev-mode as before:
- three-finger salute
- Ctrl-D at the recovery screen
- Press ENTER when asked
Now, at the DEV screen, try to leave:
- Press SPACE. It should ask if you want to go to normal mode.
- Press ESC (no). You should be back at the DEV screen again.
- Press ENTER. It should ask if you want to go to normal mode.
- Press ESC (no). You should be back at the DEV screen again.
- Press SPACE. It should ask if you want to go to normal mode.
- Press ENTER (yes). It should reboot into normal mode.
Change-Id: I99af6e7b97fb61f943bd14c8c7166571b5ccf106
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28872
And space at TONORM screen no longer confirms disabling dev mode
Added Ctrl+Refresh as an alias for tonorm screen request. U-boot will
need to be enhanced to support that. Until then, many FAFT tests will
break.
BUG=chrome-os-partner:11887
TEST=manual
1. Boot to DEV screen
2. Press Enter. Nothing happens.
3. Press Space. Goes to TONORM screen.
4. Press Space. Nothing happens.
5. Press Enter. Reboots with dev mode disabled.
Change-Id: I7f61c4001c668ac916f50f931a79a107752c83b5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28851
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Software sync will, of course, work perfectly, so these will never be needed.
BUG=none
TEST=none (hey, it all works perfectly)
Change-Id: I0014dfb99507c5eb00de73b77edb7538b598658f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28495
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This changes the signature of the function above so that it takes an additional
parameter that specifies which EC image vboot wants. This is better than making
U-Boot decide because U-Boot doesn't really keep track of which version it is
(it peeks at internal vboot data) and vboot does.
Also, some consts were removed from the image pointer pointer. The pointer
itself will be changed in the body of the function to tell vboot where the EC
has been loaded, and the contents of the buffer will be changed because U-Boot
will have to actually load the EC there.
BUG=chrome-os-partner:11148
TEST=Built vboot_reference, vboot_reference-firmware, chromeos-u-boot, and
chromeos-bootimage for Daisy and Link and saw them complete successfully with
and without the signature for U-Boot's version of this function being updated.
That works because the function isn't actually being used yet.
Change-Id: I2814c8210eb5b3d965bb8bbf23c0f283f9e44c90
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/27755
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Doesn't check the EC hash, but does jump to the correct image, for now
assuming the hash is good.
BUG=chrome-os-partner:11087
TEST=manual
- Power+refresh. System boots. EC is in RO (verify via 'ectool version')
- Create a BIOS signed *without* RO-normal.
- Power+refresh. System boots. EC ends up in A.
- ectool eventgetb. Event 0x2000 IS present, indicating EC has rebooted
- ectool eventclearb -1
- Power button to shut down, then power button to power back on.
- ectool eventgetb. Event 0x2000 is NOT present.
- crossystem recovery_request=123 && reboot. System reboots to recovery mode
and EC is in read-only (verify via EC console 'sysinfo')
- Power off and on. System boots. EC ends up in A again.
Change-Id: I39682d1bf7215c62a4b20613d029e78194b98826
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27574
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This gives the AP a chance to save NvStorage data first.
BUG=chrome-os-partner:11087
TEST=none yet; API isn't used yet
Change-Id: Iae7a24958fb076039795b92d9edb73d7e6ebfc6f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27525
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
On some systems, we require the VGA option ROM to be loaded before VbInit()
is called so we can display BIOS screens. If that hasn't happened, we
request it and reboot. Alternatively, if we don't need the option ROM
(normal mode) but we've already loaded it, we un-request it and reboot just
in case there are security vulnerabilities that might be exposed.
Not all systems need preloaded option ROMs. There is an additional input
flag that indicates whether this matters or not.
BUG=chrome-os-partner:8789
TEST=manual
Using keyboard-based dev-mode, switch between normal and dev mode and back.
It should work as expected.
Change-Id: Id1d662014d47ab648c73db4b1647520801f3a0b8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27125
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Nothing uses this yet; this is just a placeholder so the u-boot code
which sets the flag based on the FDT can go in.
BUG=chrome-os-partner:11087
TEST=if it builds it works
Change-Id: Ie04e3330bcda5c07d34a49391627316bd6232b5a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26874
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
For fastest boot, we don't want to load the VGA Option ROM every time, but
only when we need it. Coreboot does that loading, but it can't always know
when it's needed (with keyboard-based dev-mode, coreboot can't tell if we're
in dev-mode or not). By the time we get to U-Boot, it's too late, so we need
two extra bits - one for vboot to tell coreboot to load the Option ROM and
another for coreboot to let vboot know it's been done.
BUG=chrome-os-partner:8789
TEST=manual
The only visible change is that crossystem will now have an "oprom_needed"
flag that can be set or cleared. Nothing actually pays attention to it yet,
though.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I521a6afdfb8ea17a8148b32eeb858844c981de9c
Reviewed-on: https://gerrit.chromium.org/gerrit/26272
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The VbExTrustEC function should be implemented in the BIOS, not the vboot
library. Also, weak references don't seem to work with our linker, so we'll
have to just require it always.
BUG=chrome-os-partner:9953
TEST=none
This must go in with a simultaneous change to U-Boot. The only test is
whether or not everything continues to compile.
Change-Id: I8a5ccb167eec3bcacbe892cf0bdcfe550a1f57d6
Reviewed-on: https://gerrit.chromium.org/gerrit/25557
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
And enable dev_boot_usb by default.
And disable rollback checks.
The first flag is necessary for factory to build with keyboard
controlled dev mode. The other flags are really handy for development
on systems where you've defeated firmware WP and are installing custom
firmware.
BUG=chromium-os:31844
TEST=make && make runtests
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I9d837fee676cb0186ea98f13005ad60a9ab86393
Reviewed-on: https://gerrit.chromium.org/gerrit/25265
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Since the "ownership" permament flag does not indicate if the TPM is
currently owned, the state of TPM Ownership must be read via a Capability
read of TPM_CAP_PROP_OWNER. This adds the "getownership" function.
BUG=chromium-os:22172
TEST=x86-alex build & manual test
Change-Id: I2fc9e933e891ba40190d008436b22496dced1c93
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/24784
Reviewed-by: Will Drewry <wad@chromium.org>
Confirmed via codesearch that these fields are not used outside of
vboot_reference itself, and the only use inside vboot_reference is one
test which checked that the test error generation itself worked.
BUG=chromium-os:31668
TEST=make && make runtests
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: Ic393e126ca2853f7aaff19ffd6fcdbdb1c47689f
Reviewed-on: https://gerrit.chromium.org/gerrit/24895
Reviewed-by: Simon Glass <sjg@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>
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>
This just adds the vbutil_ec tool (and a simple test of the library
functions related to it).
BUG=chrome-os-partner:7459, chromium-os:27142
TEST=manual
make
make runtests
Change-Id: I2a2c4e7cfb8ac6ce2229c5de4252a5cc89321fa5
Reviewed-on: https://gerrit.chromium.org/gerrit/21868
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Omit this check because this check is not really necessary and it is
dealing more harms than goods to ARM boards.
While body load address is configurable, it is not quite possible to fix
all the build scripts and runtime scripts to carry this address; so in
reality all scripts use the default body load address.
The problem is, this default address is not friendly to ARM boards, and
it virtually makes this check fails on ARM boards.
BUG=chromium-os:28077
TEST=emerge-{daisy,x86-alex} vboot_reference
TEST=load_kernel_test -b 1 chromiumos_image.bin
TEST=run verified boot on Daisy
Change-Id: I1a1cc0aedf254e2a2b680046812ab7154f26dea7
Reviewed-on: https://gerrit.chromium.org/gerrit/20947
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
When the filesystem resizing process starts, it has the TPM open,
which means it can collide with tcsd after the main process exits.
Additionally, improve the debugging around TPM usage for better timing
analysis.
BUG=None
TEST=lumpy build & manual testing
Change-Id: I7028131015fb972c99e8b3d035f58346f08fbd06
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/19535
Reviewed-by: Elly Jones <ellyjones@chromium.org>
Due to the limitation of servo that is unable to send U keys, dev USB boot
(triggered by Ctrl-U) is unable to be tested on FAFT. To solve it, firmware
should add an addition key combination to workaround it. Ctrl-Enter is the
one we picked.
BUG=chrome-os-partner:6759
TEST=compile the firmware and update it to Lumpy; during the dev screen,
press Ctrl-Enter to trigger USB boot.
Change-Id: I8215a241c3c07dc2f5e194c324459f106d007f47
Reviewed-on: https://gerrit.chromium.org/gerrit/15749
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
Add ability to report a single PCR value via the tpmc utility. Using
/sys/devices/platform/tpm_tis/pcrs is too slow, since it reads all
PCRs before returning. Anything wanting to read PCR0 on a time-critical
path needs maximum speed.
BUG=chromium-os:22172
TEST=install and test x86-alex.
Change-Id: I2d450961d33fa314d54b909135a74aa756279ec6
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/13891
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
When you enter dev-mode,
Pressing Ctrl-U to boot from USB is DISABLED.
Booting any self-signed kernel from the SSD is ENABLED.
This replaces the "crossystem dev_boot_custom" argument with
"crossystem dev_boot_signed_only", which has the opposite polarity.
So if you want to dev-mode to only boot official kernels, you have to
explictly set it that way. If you leave dev-mode and then come back,
it will go back to the conditions shown above.
BUG=chrome-os-partner:5954
TEST=manual
Just run the factory flow. It was broken; this should fix it (except for any
workarounds that were added while it was broken; those may need to be
reverted).
Change-Id: I13e0edbc0e77c5d6ea609dabf771085006cd1805
Reviewed-on: https://gerrit.chromium.org/gerrit/11853
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This adds a flag to the list of values returned by VbInit(). When
this flag is set, the BIOS may be asked to boot something other than
ChromeOS. If this requires some sort of special preparation, the BIOS
should do it.
BUG=chromium-os:22454
TEST=none
There is no test for this. It requires a change to the BIOS in order
to do anything differently, and we haven't yet decided whether the
BIOS should pay attention to it.
Change-Id: I5d89e7cd5b745ee74b8ace7fa613c0db03eebefd
Reviewed-on: https://gerrit.chromium.org/gerrit/11714
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
