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>
The return value of VbExDisplaySetDimension should be handled as VbError_t,
which means we should print error message when it's not zero.
Also add the return code to debug message.
BRANCH=none
BUG=none
TEST=emerge-nyan coreboot chromeos-bootimage, enter recovery screen.
Not seeing error messages anymore.
Change-Id: Icafdfd933d799e8496fedcf1633339065c6962a3
Reviewed-on: https://chromium-review.googlesource.com/200679
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@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>
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>
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
VbHWID() returns a fixed string which can also be a returning a
string that lives in the read only text segment or read only flash.
Because of this the compiler will rightfully error when built with
-Werror and -Wwrite-strings because the const qualifier is being
ignored. Correct this and the ripple effect in VbRenderTextAtPos().
VbRenderTextAtPos() should be using constant strings anyhow.
BUG=chrome-os-partner:17695
BRANCH=None
TEST=built fwlib with -Werror -Wwrite-strings. Compiles correctly. make
runtests still passes as well.
Change-Id: Id03a783d2d9b5de4cc3b3ce0fa6d74934751cca4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44043
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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
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>
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 just chews up memory and wastes time on ARM, since the data is already
in memory.
BUG=chrome-os-partner:13492
BRANCH=snow
TEST=manual
Build and boot on snow with manually modified code, to see that the bmpfv
pointer is in the same region as the bmp region.
Build and boot on link and see that displaying screens is still fast.
Change-Id: I98349b73671e38fa6cace966b6953a2abf129fab
Reviewed-on: https://gerrit.chromium.org/gerrit/32629
Reviewed-by: Mike Truty <truty@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Commit-Ready: Simon Glass <sjg@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>
On x86 U-Boot cannot see the power button, which means that the EC must
deal with it, and may power off the unit at any time. To get around this,
we write the vbcontext every time we change it.
Since this isn't a problem on ARM, and we want to avoid spurious writes
(due to delay and disk wear), make this code execute only on x86 machines.
BUG=chrome-os-partner:13717
BUG=chrome-os-partner:7689
BRANCH=snow,link
TEST=manual
On snow, see that the EC no longer gets MKBP messages to write the nv
context.
On link, manually add a print to U-Boot's nvstorage_write_disk() function
and see that changing language in recovery still causes a write.
Change-Id: I62508739c9fc3aca46fba58b196a8af45269af2a
Reviewed-on: https://gerrit.chromium.org/gerrit/32464
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
Rather than read the images from slow flash every time we need them, cache
them the first time and use that cache thereafter.
BUG=none
BRANCH=snow,link
TEST=manual
Go into recovery mode on link
See that we can display a new screen in roughly 20ms instead of the 250ms
it previously took on link.
Also tested on snow and shown to have no ill effects.
Change-Id: Ieb39c44bddeb6315da8983669f19f550888659bd
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32462
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
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 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
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>
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>
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>
Callers of vboot might print some additional information in
VbExDisplayDebugInfo(). Add a new line to the end of the buffer
so that output is aligned with the normal <tab> information.
BUG=none
TEST=set gbb flags to 1, see cursor go to next line at dev screen.
Change-Id: I8dd77404338a05bddc5f3ec54d7b65c890a60c50
Reviewed-on: https://gerrit.chromium.org/gerrit/17001
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
On x86 platforms, the power button and lid switch events have to be handled
by coreboot SMM code, because it needs to interact with the southbridge
and/or EC, and U-Boot doesn't have a way to do that. Once the kernel takes
over, it sends an SMI to that code which tells it to start delivering ACPI
events instead of whatever pre-ACPI handling it has been doing.
U-Boot doesn't have any code to handle either case, and adding it would
either be a major undertaking (adding ACPI support to U-Boot!), or would
require creating yet another special-purpose interface just for our U-Boot
(yuck).
It's much simpler to just make vboot_reference be more aggressive about
writing to the nvram for this one case where it matters.
OTOH, ARM will need U-Boot to handle the lid switch and power button via
GPIOs since it uses only U-Boot and has no SMI handler. This change isn't
necessary for ARM, but shouldn't hurt either.
BUG=chrome-os-partner:7689
TEST=manual
1. Boot to dev-mode screen or recovery screen.
2. Press arrow keys to change locale.
3. Power off (press power button or yank A/C & battery)
4. Power on again.
The BIOS screen locale should still be set to your last choice before
powering off.
Change-Id: I9008811c3be71de47ff1c6899e81955cf0560a52
Reviewed-on: https://gerrit.chromium.org/gerrit/14721
Tested-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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>
Although we're now using a single unified BIOS, it is pretty nice to be able
to get a shell in developer mode while still using verified boot for the
kernel and filesystem. Alex & ZGB implemented this by requiring the dev-mode
user to install a special dev-mode BIOS. We don't do that, but we DO require
setting a special flag with "crossystem" to accomplish the same thing.
In order to allow booting a self-signed kernel, you must boot in developer
mode, open a shell, and run this:
crossystem dev_boot_custom=1
Special note to internal developers: If you're in the habit (as I am) of
booting directly from a USB stick in dev-mode, you'll have to run this:
crossystem dev_boot_custom=1 dev_boot_usb=1
Just using dev_boot_usb=1 is no longer enough, because the USB kernel is
signed using the recovery key and by pressing Ctrl-U, we validate it with
the kernel data key. That worked before this change because any self-signed
kernel was fine, and that's how the USB key was treated. Now it actually
requires a verified signature until you enable dev_boot_custom=1 also.
BUG=chrome-os-partner:5954
TEST=manual
Boot once in normal mode, which clears the special flags. Then switch to
developer mode. You should be able to boot and get a root shell.
Run
crossystem dev_boot_usb=1
Obtain a USB recovery image that's keyed differently. For example, if you're
testing with dev-keys, use a PVT-signed image or vice-versa.
Reboot into dev-mode with the USB recovery stick inserted. At the dev-mode
screen, press Ctrl-U. You should hear a single beep, but it should not boot.
Press Ctrl-D to boot from the hard drive, log in to a shell and run
crossystem dev_boot_custom=1
Repeat the previous test. This time when you press Ctrl-U, it should boot
the recovery image. Turn the system off before it does anything.
That's it.
Change-Id: I1811ee9a188974b3f94c83c52b00b60028b86c69
Reviewed-on: https://gerrit.chromium.org/gerrit/11442
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This displays the gbb.flags value when being warned about it being nonzero.
It also decodes the recovery_reason value into English.
BUG=chromium-os:20972
TEST=manual
1. Use gbb_utility to create a BIOS with valid bitmaps, but with gbb.flags
set to a non-zero value. Boot into recovery mode. You should see the
warning that gbb.flags is non-zero, and the value itself.
2. Press TAB. The recovery_reason field should display not only a value, but
also an English string explaining the value.
Change-Id: I99b7aa35bc67453bdf3385b9573491090c3dec1d
Reviewed-on: http://gerrit.chromium.org/gerrit/8459
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
This enables us to support playing sounds in the background if the BIOS
allows it, so we don't have to block while beeping is happening. The new
declaration is:
VbError_t VbExBeep(uint32_t msec, uint32_t frequency);
If the audio codec can run in the background, then:
zero frequency means OFF, non-zero frequency means ON
zero msec means return immediately, non-zero msec means delay (and
then OFF if needed)
else:
non-zero msec and non-zero frequency means ON, delay, OFF, return
zero msec or zero frequency means do nothing and return immediately
The return value is used by the caller to determine the capabilities. The
implementation should always do the best it can if it cannot fully support
all features - for example, beeping at a fixed frequency if frequency
support is not available. At a minimum, it must delay for the specified
non-zero duration.
Currently, VbExBeep() is called only when displaying the dev-mode screen.
BUG=none
TEST=manual
I've tested on x86 and ARM, all timeouts and noises work as before.
Note that ARM and coreboot will require a corresponding change to their
VbExBeep() implementations, which will have to be handled with separate,
simultaneous CLs.
Change-Id: I3417ae4b99d9d0aee63f2ccaeed39b61d4333e5d
Reviewed-on: http://gerrit.chromium.org/gerrit/8234
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:5919
TEST=manual
Until the factory flow has completed, BIOS screens should display a warning
message about GBB.flags. This message should disappear once the flags field
is zero.
You can see the state of the GBB flags in a particular BIOS image using
gbb_utility -g --flags BIOS.bin
And set it with
gbb_utility -s --flags=VALUE BIOS.bin NEWBIOS.bin
Change-Id: I15d336bda571978ece0a9744f19d80f0ae385fb1
Reviewed-on: http://gerrit.chromium.org/gerrit/7719
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The vboot_api.h doesn't require the BIOS display the ASCII HWID in
a graphical form (ARM U-Boot doesn't know how), so we have to do it
ourselves. This change makes that possible.
Summary of changes:
* bmpblk_font.h defines a structure to map ASCII chars to BMPs
* bmpblk_font utility generates that font structure
* bmpblock format is bumped to version 1.2
- YAML file specifies font to use for $HWID
- make_default_yaml updated to emit the new format
- README updated to describe the difference
BUG=chromium-os:18631
TEST=manual
I've tested this on ARM, like so:
Inside the chroot, build a U-Boot that uses it:
emerge-tegra2_kaen vboot_reference vboot_reference-firmware
emerge-tegra2_kaen tegra-bct tegra2-public-firmware-fdts \
chromeos-u-boot chromeos-bootimage
Outside chroot, but in src/platform/vboot_reference:
make
<copy ./build/utility/bmpblk_font and ./build/utility/bmpblk_utility to
somewhere in your $PATH>
make clean
cd scripts/newbitmaps/fonts
bmpblk_font --outfile ../images/hwid_fonts.bin outdir/*
cd scripts/newbitmaps/images
make arm
cd out_arm
<edit DEFAULT.yaml>
bmpblk_utility -z 2 -c DEFAULT.yaml arm_bmpblock.bin
<use gbb_utility to replace the bitmaps in the U-Boot image, boot it>
The HWID string is displayed.
Change-Id: I782004a0f30c57fa1f3bb246e8c59a02c5e9f561
Reviewed-on: http://gerrit.chromium.org/gerrit/6544
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
This refactoring will enable us to test and mock them separately from the
rest of the vboot_api functions.
BUG=chromium-os:17564
TEST=manual
Built for ARM, ran "vbexport_test display" at U-Boot prompt. Still works.
Change-Id: I2ddb01d3e981603f371aaa7317184457bdff48ac
Reviewed-on: http://gerrit.chromium.org/gerrit/6422
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
