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>
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>
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>
The fix for chrome-os-partner:7715 introduced a new bug. This fixes that.
BUG=chrome-os-partner:7775
TEST=manual
Boot into recovery mode.
Insert invalid USB.
You should see the YUCK screen.
Change-Id: I868287eecd34bb0c48127bee04f573b418f5945c
Reviewed-on: https://gerrit.chromium.org/gerrit/14963
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Previously, it was going to recovery only when no disks existed. That didn't
catch the case where disks exist but none of them are usable.
BUG=chrome-os-partner:7715
TEST=manual
I've added a test specifically for this, so just
make
make runtests
should verify it.
To test on actual hardware, find a disk or USB drive that has something
other than 512 bytes per LBA, and try it. It won't be bootable, but using it
shouldn't hang the system or cause weird behavior.
Once in recovery, press TAB, and you should see the reason code
VBNV_RECOVERY_RW_NO_DISK
Change-Id: I475ddd01e13fa806025a2107c260c030d098a17e
Reviewed-on: https://gerrit.chromium.org/gerrit/14816
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@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 the user hits Ctrl+U on the dev screen, we used to change the
screen only after we enumerate the USB devices, load the kernel from USB
mass storage and boot it (about 4 seconds on the current firmware).
Let's blank the screen earlier to show we got the key press.
BUG=chrome-os-partner:7563
TEST=on a Stumpy in developer, hit Ctrl+U on the dev screen with an
invalid key, then a valid key. Check which screen are displayed and how
long it takes to get a new display after the key strokes.
Change-Id: Ifc73b56055bcd50360d71c1cb6dee052d0fdf9aa
Reviewed-on: https://gerrit.chromium.org/gerrit/14395
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:1113
TEST=manual
With the dev-switch OFF, insert a bootable USB drive, reboot while holding
down recovery button. It should boot from the USB without prompting for
removal.
With the dev-switch OFF and the same bootable USB drive inserted, run
crossystem recovery_request=2
reboot
The BIOS screen should prompt you to remove the USB drive, then to insert it
before it will boot from the USB.
Prior to this fix, using recovery_request=2 would NOT require removal, while
other non-zero values would. NO values of recovery_request should be able to
override the removal request. Only physically pressing the button should
allow booting immediately from recovery mode with the dev-switch OFF.
Change-Id: I6d63ecb761c4b26820091cc7a97ca540b362c22e
Reviewed-on: https://gerrit.chromium.org/gerrit/12143
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
BUG=chrome-os-partner:1113
TEST=manual
With the dev-switch OFF, insert a bootable USB drive, reboot while holding
down recovery button. It should boot from the USB without prompting for
removal.
With the dev-switch OFF and the same bootable USB drive inserted, run
crossystem recovery_request=1
reboot
The BIOS screen should prompt you to remove the USB drive, then to insert it
before it will boot from the USB.
Change-Id: Ie2fe4302443e14b1f85f409b54aa43a94d6c5477
Reviewed-on: https://gerrit.chromium.org/gerrit/11788
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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>
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>
BUG=none
TEST=manual
Booted in dev-mode. All noises and delays are unchanged (2 second delay when
gbb.flags is 1, 30-second with beeps at 20 seconds when gbb.flags is 0).
Change-Id: I816e57c4f8f6025299851b3d42b4a350f9925994
Reviewed-on: http://gerrit.chromium.org/gerrit/8240
Reviewed-by: Randall Spangler <rspangler@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>
The vboot library needs to decompress the images so that it can handle those
that are special cases (like rendering the HWID). This means that 1) it
needs access to the BIOS' native decompression routine, and 2) that
VbExDisplayImage() only needs to handle the uncompressed native-format image
and doesn't need to know about how the image is packed in the GBB.
BUG=chromium-os:19134
TEST=manual
This requires a change to vboot_api.h, which requires a (simultaneous)
matching change to the BIOS, at least for U-Boot, which builds separately.
I've made that change and run the "vbexport_test display" command from the
modified U-Boot, but that also requires a change to the way U-Boot is built
so that I can get at the U-Boot commandline.
Change-Id: I449fb467cd3a68e742f27ec41b95d52685459d89
Reviewed-on: http://gerrit.chromium.org/gerrit/6129
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
This is OFF by default, and must be turned on via the gbb_utility.
BUG=chrome-os-partner:2317
TEST=manual
Build a firmware image and flash it. Should have the same 30-sec
delay as it does now. Pressing TAB should show GBB flags = 0x0.
Modify the firmware image using gbb_utility to set GBB flags to 1 and
reboot. Dev delay should be 2 sec. Pressing TAB should show GBB
flags = 0x00000001.
Change-Id: If96ab9e7d0d142a9cd9a2c6af3849421d073de5e
Reviewed-on: http://gerrit.chromium.org/gerrit/4829
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
When we're trying a new firmware B with a new kernel subkey, if it
can't find any kernels there may still be a kernel which the old
firmware A likes. So instead of going to recovery mode, just reboot
so we fall back to firmware A. If firmware A doesn't find any valid
kernels we'll still go to recovery mode.
BUG=chrome-os-partner:1657
TEST=manual:
Do a firmware+OS update which involves kernel subkey rotation. After
installing the new firmware but before rebooting into the new OS,
corrupt the new kernel so that it'll fail validation. Then reboot.
On previous firmware, this would go to recovery mode. Now it should
simply reboot and be back in firmware A / kernel A.
Change-Id: I12796f428fd6969ea5ef36f39c4f58cb0a2bff0d
Reviewed-on: http://gerrit.chromium.org/gerrit/4770
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
This also fixes one place where TPM error codes were getting lost.
BUG=chromium-os:18132
TEST=make && make runtests
Change-Id: I83c74e1103805f166d1dc7448be7d67bd46d15b3
Reviewed-on: http://gerrit.chromium.org/gerrit/4659
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Try #2, now that ARM has the fix from http://gerrit.chromium.org/gerrit/4667
This cleans up the TPM calls inside vboot_reference.
* TPM calls share mode code between boot modes.
* Better handling for TPM_E_MUST_REBOOT, particularly in recovery mode.
* TAB screen shows current TPM versions.
No changes required to the wrapper API; these changes are internal to vboot.
BUG=chromium-os:18084
TEST=make && make runtests; built for both alex and tegra2-seaboard
Original-Change-Id: I2a52066f2889210af83409872b10f9d6380470af
(cherry picked from commit da55560cddcf7a1aa8a881cdf52792a21a01e766)
Change-Id: I120797145772116f09b8125b9e56fdbb11dc16b3
Reviewed-on: http://gerrit.chromium.org/gerrit/4671
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This cleans up the TPM calls inside vboot_reference.
* TPM calls share mode code between boot modes.
* Better handling for TPM_E_MUST_REBOOT, particularly in recovery mode.
* TAB screen shows current TPM versions.
No changes required to the wrapper API; these changes are internal to vboot.
BUG=chromium-os:18084
TEST=make && make runtests; built for both alex and tegra2-seaboard
Change-Id: I2a52066f2889210af83409872b10f9d6380470af
Reviewed-on: http://gerrit.chromium.org/gerrit/4611
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
The problem is that the recovery request was only being cleared when
the firmware found a good image, not after a failed attempt was
ignored.
BUG=chromium-os:17846
TEST=see bug for manual test procedure
Change-Id: I4c6b026bef477839def9bf2b0fed626a9922650f
Reviewed-on: http://gerrit.chromium.org/gerrit/4352
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:5031
TEST=manual
1. crossystem dev_boot_usb=0
2. Boot with dev switch on and bootable USB device inserted
3. Press Tab. Should show dev_boot_usb: 0
4. Press Ctrl+U. Should beep twice
5. crossystem dev_boot_usb=1
6. Boot with dev switch on and nothing in USB/SD
7. Press Tab. Should show dev_boot_usb: 1
8. Press Ctrl+U. Should beep once
Change-Id: Ie9b73f86d68337b48c1b859c7c6d76fcb72d13c2
Reviewed-on: http://gerrit.chromium.org/gerrit/4312
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
BUG=chromium-os:17457
TEST=make && make runtests
When this is merged into an actual firmware build, can test it:
* dev switch off -> no dev screen, won't boot self-signed kernel
* dev switch on --> dev warning screen, will boot self-signed kernel
(e.g., it acts like the Cr-48)
Change-Id: I985428256e48b7e05dd4d8fe582a0c0103bf5fb2
Reviewed-on: http://gerrit.chromium.org/gerrit/3901
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Randall Spangler <rspangler@chromium.org>
BUG=chromium-os:17433
TEST=make && make runtests. Additional manual tests:
0. Insert a valid dev-signed USB key.
1. Boot with dev switch off.
`crossystem dev_boot_usb` should print 0.
2. Flip dev switch on.
`crossystem dev_boot_usb` should print 0.
Ctrl+U at dev screen should beep, but not boot USB.
3. Type `crossystem dev_boot_usb=1`. Should succeed.
`crossystem dev_boot_usb` should print 1.
4. Reboot system.
At the dev mode warning, press Ctrl+U
System should boot from USB key
`crossystem dev_boot_usb` should print 0.
5. Flip dev switch off.
`crossystem dev_boot_usb` should print 0.
6. Flip dev switch on.
`crossystem dev_boot_usb` should print 0.
Note that this does not apply to Cr-48, Alex, or ZGB.
Change-Id: Idf85fdd642f38f531c89e5fa5b1679e84936d4da
Reviewed-on: http://gerrit.chromium.org/gerrit/3875
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Randall Spangler <rspangler@chromium.org>
Pressing Tab at a firmware screen now displays real data, including
the recovery reason, HWID, and contents of VbNvStorage.
Entry point start/end time tracking in VbSharedData now refers to the
new wrapper APIs.
Added capability for calling firmware to request recovery mode (for
example, if it's unable to initialize RAM, can't find the SSD, etc.).
Previously, calling firmware had no (good) way to do this other than
faking the recovery button being pressed.
BUG=chromium-os:17018
TEST=emerge on x86 and tegra2_seaboard
Change-Id: I7d377f279842b30a10d945d13571c41c464633f1
Reviewed-on: http://gerrit.chromium.org/gerrit/3814
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
