This gives recovery mode information on two boots back instead of one,
which may be handy for debugging.
It also allows determining whether a failure of the current boot
should try the other slot or go to recovery, using only information
stored in NV storage.
Added crossystem support for printing the fields, and unit tests.
BUG=chrome-os-partner:32585
BRANCH=none
TEST=make runtests; VBOOT2=1 make runtests
Change-Id: Ia9f4186210d30217b902db7c513ae4ab8851f8f4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221230
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
In order to disable PD software sync but still do EC software sync
it is useful to have a separate GBB flag for it.
This will allow me to release a Samus P2B firmware image that will
update the EC but not the PD, since the PD FW that comes on P2B
devices cannot be updated with software sync.
BUG=chrome-os-partner:30079
BRANCH=None
TEST=flash BIOS with updated EC+PD:
1) no GBB flags to override behavior updates both EC and PD
2) GBB flag to disable EC software sync disables both EC and PD update
3) GBB flag to disable PD software sync disables only PD update
Change-Id: I49ffb59238bee4a2dd66b24f2516e3ce46ea06cd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211910
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This will be used in subsequent CLs to support PD software sync. For
now, only devidx=0 is used.
This changes the external vboot API, so must be checked in at the same
time as changes to the u-boot and depthcharge implementations. For
now, those implementations should simply check if devidx=0 and fail if
it's not.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=make runtests
CQ-DEPEND=CL:208195,CL:208196
Change-Id: Iad3be9d676ac224c4582669bcd67176b39f75c73
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208210
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The functions TlclLog() and TlclSetLogLevel() are declared in tlcl.h, but do
not appear anywhere else in the source. Let's not declare nonexistant
functions.
BUG=chromium:231567
BRANCH=ToT
TEST=make runtests
These never existed or did anything. They still don't.
Change-Id: Id6f0216d70b7b62d91486aba7d6cd996dc5f7d8d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205708
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We use a few bytes of battery-backed nvram to save some flags across
reboots. However if the battery discharges completely, these flags are lost.
There aren't any security issues with that since they reset to safe values,
but some of the flags are used to configure how the system boots in
dev-mode.
If a dev-mode user has completely replaced ChromeOS with some other OS, then
she often needs to set the dev_boot_usb and/or dev_boot_legacy flags as well
in order to boot it using Ctrl-U or Ctrl-L. If the battery dies, then those
flags are cleared, and the only way to make the Chromebook boot again is by
going through recovery, which wipes the disk.
This change uses a new NV space in the TPM to back up some of the nvram
flags. These nvram fields will be backed up:
block_devmode
dev_boot_legacy
dev_boot_signed_only
dev_boot_usb
fwupdate_tries
loc_idx
Because writing to the TPM space is slow and limited to an unspecified but
finite number of cycles, we only back up the fields when specifically
requested by the new backup_nvram_request flag. This flag will be set by
crossystem whenever it is used to change any of the fields listed above. The
backup will be attempted at the NEXT boot (because the TPM is locked after
booting), and the backup_nvram_request flag will be cleared if the backup
was successfull.
Note that this CL is for Top of Trunk only. The firmware will create the
required TPM spaces on systems that have never been booted, but we don't yet
have a secure or reliable method to update existing systems.
FYI, on Link, determining that the TPM's backup NV space doesn't exist adds
about 6ms to the boot time. If it does exist, the backup_nvram_request flag
is cleared automatically so it won't check until it's set again.
BUG=chromium:362105
BRANCH=ToT (only!)
TEST=manual
Testing this is a long and involved process. Read on...
First, there are host-side tests for it. In the chroot:
cd src/platform/ec
make runtests
Second, to test on a completely NEW system that was first booted with a BIOS
that contains this CL, do this:
Enter dev-mode
Use crossystem to set values for the fields listed above
Confirm that "backup_nvram_request" is set to 1
Reboot
Use crossystem to confirm that "backup_nvram_request" is now 0
Remove the battery and the AC
Reattach either battery or AC so it will boot again
Use crossystem to confirm that the backed up fields are still good, while
the others have been reset to default values
Switch to normal mode
Remove the battery and the AC
Reattach either battery or AC so it will boot again
Look at the bios info in chrome://system to see what crossystem says
Confirm that the dev_boot_* flags are all 0, while the others are restored
Third, to set things up to test this on an existing system (I used Link),
you have update the BIOS, delete both the Kernel and Firmware NV spaces in
the TPM, then reboot so that the BIOS will create the Backup, Kernel, and
Firmware spaces. It will only do that if they're all missing.
Open it up, disable write-protect, attach a servo, etc.
Switch to dev-mode, log in.
Run make_dev_firmware.sh
Reboot in recovery mode, and insert a USB stick with a test image on it.
NOTE: In order to fiddle with the TPM, we'll *always* have to boot in
recovery mode, since that's the only time the TPM is left unlocked. That's
NOT the same as pressing Ctrl-U at the scary boot screen. The rest of
these steps assume you've booted in recovery mode and are running from the
test image on the USB stick.
Run
make_dev_ssd.sh --remove_rootfs_verification --recovery_key
Reboot (recovery mode)
Run
mv /etc/init/tcsd.conf /etc/init/tcsd.conf.disabled
Reboot (recovery mode).
Run "tpmc getvf". It should say
deactivated 0
disableForceClear 0
physicalPresence 1
physicalPresenceLock 0
bGlobalLock 0
Run "tpmc geto". It should say
Owned: no
Now you'll need to build the "tpm-nvtool" utility. In the chroot:
cd src/third_party/tpm/nvtool
make
Copy that to the DUT, in /usr/local/bin.
Now run
tcsd
tpm-nvtool --list | grep Index
You may see a number of spaces, but you should at least see these:
# NV Index 0x00001007
# NV Index 0x00001008
Run
tpm_takeownership
It will prompt you for two passwords (and confirm each one). Respond with
something you can remember like "google".
Run
tpm-nvtool --release --index 0x1007 --owner_password "google"
tpm-nvtool --release --index 0x1008 --owner_password "google"
Verify that it worked with
tpm-nvtool --list | grep Index
Power off.
Using servo, flash the new BIOS that has this CL in it.
Power on, normally this time (not recovery mode). If all goes well, it
should create the correct NV spaces and boot into the SSD. Copy tpm-nvtool
into this image too, and run
tpm-nvtool --list | grep Index
You should now see at least these spaces:
# NV Index 0x00001007
# NV Index 0x00001008
# NV Index 0x00001009
Now you're ready to test the backup/recover feature.
Change-Id: I00031fa0774720147327e2ae0f37e26b34b86341
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202138
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
For displaying GBB images on panels with different dimension, X86 has VESA mode
and VBIOS to scale automatically but ARM does not have such mode settings. If we
install a larger panel on ARM platforms, current firmware will render the
screens in left-top corner and leave black borders in right-bottom corner.
To render images correctly, vboot library has to send out the expected dimension
(similar to the VESA mode) so display provider can scale or shift images.
BUG=chrome-os-partner:28494
TEST=emerge-nyan vboot_reference
CQ-DEPEND=CL:199051,CL:199045
BRANCH=none
Change-Id: I6d60f755ca2bcbd3135631d7624a8a4a4cff68b1
Reviewed-on: https://chromium-review.googlesource.com/199043
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
We don't allow ENTER from a USB keyboard as the confirmation
in the switch from normal to developer mode.
For devices that have a physical recovery button, we require
a recovery button press instead. For other devices, we
require that ENTER be pressed on the internal keyboard.
This prevents an "evil keyboard" attack in which a USB keyboard
(or other USB device pretending to be a keyboard) sends a
control-D/ENTER sequence shortly after every boot (followed
by more evil keys). In that situation, when users power-on in
recovery mode, they will be forced to dev mode even if it
was not their intention. Further attacks are easy at
that point.
TESTING. On a panther device:
1. powered on with recovery button pressed -> booted in recovery mode
2. pressed control-D on external USB keyboard -> got to ToDev? screen
3. pressed ENTER -> system beeped
4. pressed recovery button -> system rebooted in DEV mode
... all as expected
Also:
1. powered on with recovery button pressed and HELD recovery button
2. pressed control-D -> system beeped
BUG=chrome-os-partner:21729
TEST=manual (see commit message)
BRANCH=none
CQ-DEPEND=CL:182420,CL:182946,CL:182357
Change-Id: Ib986d00d4567c2d447f8bbff0e5ccfec94596aa7
Reviewed-on: https://chromium-review.googlesource.com/182241
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
TEST=Built and booted Peppy. Ran flashrom from user space and
verified the EC firmware was updated after reboot.
CQ-DEPEND=CL:172651, CL:172652, CL:178324
BRANCH=none
BUG=chromium:325286
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Ia73da70dbf3abb5ced48666e86715c8d24a431a0
Reviewed-on: https://chromium-review.googlesource.com/172635
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@google.com>
Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
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>
This tells the boot loader the number of firmware types that are supported,
so that it can declare arrays of that size.
BUG=chrome-os-partner:21115
BRANCH=pit
TEST=manual
Build for pit, link, daisy
Change-Id: Ib10e559af29b8dfe78268eb6e0465a245427313e
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66095
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
In many cases format strings in vboot_reference do not match their
parameters, which causes all kind of ugly results when examining debug
output.
Enforce proper format verification.
CQ-DEPEND=CL:65396
BRANCH=pit
BUG=none
TEST=manual
. compiled cleanly in vboot_reference, observed debug printouts
making sense.
Change-Id: I58d5ba1f9097ef9922fbaeb7a9946aadf5eb8617
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65394
1) GBB flag to skip EC software sync, so EC will be untouched. Needed
for EC development.
2) GBB flag to default to booting legacy at end of dev screen timeout.
Very handy for booting Ubuntu (or other OS).
Also added unit tests for the new flags.
BUG=chrome-os-partner:20111
BRANCH=none
TEST=make runtests
Change-Id: I9da87d87014881a1b1393b0b4a5acb921d080066
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58270
Reviewed-by: Bill Richardson <wfrichar@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>
It's no longer necessary and adds complexity.
BUG=None
TEST=Built vboot_reference (with FEATURES=test), chromeos-u-boot, depthcharge,
chromeos-factory, chromeos-factoryinstall, chromeos-initramfs, and
chromeos-cryptohome for daisy, lumpy, link, alex, and fox_wtm2 where
applicable. Built vboot_reference for the host.
BRANCH=None
Change-Id: Ic2d70b92b25d57fd9ca1d9ad47d9889f6adc85e7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/45685
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Strncat() looks almost like strncat(), but it's completely different. Change
the name to reduce confusion.
Also fix a place where strncat() was misused anyway.
BUG=none
BRANCH=all
TEST=manual
sudo FEATURES=test emerge vboot_reference
FEATURES=test emerge-$BOARD vboot_reference
Change-Id: I39c30d391aa6566ec67461462e800720ade66a91
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44572
This removes the need to load the EC code at all when the precomputed
hash matches.
BUG=chrome-os-partner:17606
BRANCH=spring
TEST=wouldn't that be nice
Change-Id: If4438b9db8b1449b8fd4d90ef3acb3bbec5e09a0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42567
This is used by vboot to retrieve the precomputed hash of the expected
EC image, which requires reading less data from EEPROM than getting
the entire EC image.
BUG=chrome-os-partner:17606
BRANCH=spring
TEST=none; just a new API not used yet
Change-Id: I226643144280acabba147d345ef1f83a77a91fbc
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42566
Verifies the right TPM commands are called, but doesn't check at a
detailed level that they're packed properly.
BUG=chromium-os:38139
BRANCH=none
TEST=make runtests
Change-Id: I6c14db083ac0a40d4738582d200d9687cddb99de
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42261
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
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>
