dc8ec103c0d0d2a4e930153a4b19c43b51d74b5d |
|
10-Feb-2015 |
Julius Werner <jwerner@chromium.org> |
vboot1: Add vboot2 recovery reason strings and subcode to TAB display vboot2 added a few new recovery reasons (and abolished many old ones). In the current vboot2/vboot1 hybrid architecture used on Veyron, the vboot1 kernel verification part controls the status display when pressing the TAB key, which may try to show recovery reasons set by the vboot2 firmware verification part. These currently result in the not very helpful "We have no idea what this means", so lets hack a few more strings into vboot1 which will be otherwise harmless. Also add the recovery_subcode field to the display, which is used much more extensively by vboot2 and often very useful in firguring out what really went wrong. BRANCH=veyron BUG=None TEST=Manually set a few recovery reasons and subcodes through crossystem and made sure they get displayed correctly on my Jerry. Change-Id: I3f3e6c6ae6e7981337841c0c5e3cd767628472c3 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/248391 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
782300d093a2fbf2ca24e446fb6d65f9f28e56a6 |
|
23-Sep-2014 |
Randall Spangler <rspangler@chromium.org> |
vboot2: Add previously tried slot and result to NV storage 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>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
9e1da784487fb8cfbe4e76693e07205b66675bda |
|
25-Jun-2014 |
Randall Spangler <rspangler@chromium.org> |
Add nvstorage / crossystem support for new vboot2 fields This allows testing vboot2. These fields are ignored by original vboot firmware. BUG=chromium:370082 BRANCH=none TEST=manual crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A crossystem fw_tried=B echo $? -> 1 crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A crossystem fw_try_next=B crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=B crossystem fw_try_next=beats_me echo $? -> 1 crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=B crossystem fw_try_next=A crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A crossystem fw_result=trying crossystem -> fw_tried=A, fw_result=trying, fw_try_next=A crossystem fw_result=bupkis echo $? -> 1 crossystem -> fw_tried=A, fw_result=trying, fw_try_next=A crossystem fw_result=success crossystem -> fw_tried=A, fw_result=success, fw_try_next=A crossystem fw_result=failure crossystem -> fw_tried=A, fw_result=failure, fw_try_next=A crossystem fw_result=unknown crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A crossystem -> fw_try_count = 0, fwb_tries = 0 crossystem fw_try_count=6 crossystem -> fw_try_count = 6, fwb_tries = 6 crossystem fwb_tries=0 crossystem -> fw_try_count = 0, fwb_tries = 0 Change-Id: I1532f3384f8c05de2a7ff3f35abcc35d18049491 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/205475
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
b64f097891e697eaf3b2794baae934f8b4d82d14 |
|
29-May-2014 |
Bill Richardson <wfrichar@chromium.org> |
Use the TPM to back up some of the nvram fields 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>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
0c3ba249abb1dc60f5ebabccf84ff13206440b83 |
|
29-Mar-2013 |
Bill Richardson <wfrichar@chromium.org> |
Massive refactoring of external header files. This reduces the number of exported header files to the minimum needed by the existing userspace utilities and firmware implementations. BUG=chromium:221544 BRANCH=none TEST=manual, trybots CQ-DEPEND=CL:47019,CL:47022,CL:47023 sudo FEATURES=test emerge vboot_reference FEATURES=test emerge-$BOARD \ vboot_reference \ chromeos-cryptohome \ chromeos-installer \ chromeos-u-boot \ peach-u-boot \ depthcharge Change-Id: I2946cc2dbaf5459a6c5eca92ca57d546498e6d85 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/47021 Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
5ca4ea087a3d67c2a639e8b9254f51f076bf85fa |
|
05-Feb-2013 |
Randall Spangler <rspangler@chromium.org> |
EC software sync uses precomputed hash if available 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
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
a2db67d204c0dd3d152ff54958bf42c5dbe394ff |
|
25-Jan-2013 |
Randall Spangler <rspangler@chromium.org> |
Reformat header files to kernel style No code changes, just reformatting. BUG=none BRANCH=none TEST=make runtests Change-Id: Id5bac79545e9803d19b45da160c535f7e06465c6 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/42016 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
699ebf398f84bb0a6138856c38db1d693e581f85 |
|
17-Dec-2012 |
Bill Richardson <wfrichar@chromium.org> |
Add recovery_subcode field to nvstorage and crossystem 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>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
640b1c420748049c796b3f9d59406e38ff8f4774 |
|
22-Nov-2012 |
Bill Richardson <wfrichar@chromium.org> |
Add more recovery_reason codes 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>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
d2852eabf6da8bd36ba898c9b375f0480fab02d2 |
|
29-Oct-2012 |
Luigi Semenzato <semenzato@chromium.org> |
Add recovery reason for failure to correct TPM error 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>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
a2326ee152ab5b8aee924ccf794cee38d54909bd |
|
24-Aug-2012 |
Stefan Reinauer <reinauer@chromium.org> |
Add CTRL-L in dev screen to support a "legacy boot option" 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>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
29e8807ea045e119e3adeaec40c5f8421901b6fb |
|
19-Jun-2012 |
Randall Spangler <rspangler@chromium.org> |
Add clear TPM owner request 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
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
584e0d2070aca1a5e091442cb9bad0726451ad95 |
|
26-Jul-2012 |
Randall Spangler <rspangler@chromium.org> |
Add more specific recovery reasons for EC software sync. 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>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
d4faa060cc6445cf532e3f9c9cd785e0726f1b82 |
|
17-Jul-2012 |
Randall Spangler <rspangler@chromium.org> |
Partial EC software sync implementation 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>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
17b8224ea582b2ba90b30a3e8e2d913e49c7818a |
|
27-Jun-2012 |
Bill Richardson <wfrichar@chromium.org> |
Add bits to request and acknowledge Option ROM loading. 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>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
c0e3742996a84d3c503cfa002b09a0831bcb2c32 |
|
08-Jun-2012 |
Randall Spangler <rspangler@chromium.org> |
Remove unused test fields from VbNvStorage 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>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
35d073362603c2c3f63974d04b4af9548297e208 |
|
25-May-2012 |
Bill Richardson <wfrichar@chromium.org> |
Add DISABLE_DEV_REQUEST flag to nvram. This just creates the bit. It doesn't actually do anything yet. BUG=chrome-os-partner:9980 TEST=manual crossystem disable_dev_request=1 crossystem crossystem disable_dev_request=0 crossystem Change-Id: I0e92a6b5ef5074ee5eae2d6d469c1c9826faecb3 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/23752 Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
7272a6951107251a5c9b26330c506319a92a54b3 |
|
17-Nov-2011 |
Bill Richardson <wfrichar@chromium.org> |
Dev-mode allows booting self-signed kernels by default. 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>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
fa9d7782e837848a1aeb0e95295fa48ac23f7a26 |
|
09-Nov-2011 |
Bill Richardson <wfrichar@chromium.org> |
Dev-mode only boots official kernels by default 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>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
ad03a439bc97523e03d19aa1dcd568744d60889c |
|
22-Jul-2011 |
Randall Spangler <rspangler@chromium.org> |
Cleanup and preparation for inside-wrapper TPM refactoring. Add recovery reason for already in recovery and need to reboot to recovery to let the TPM init. Add vboot_struct fields. Fix type for keyblock flags param to SetTPMBootModeState(). BUG=none TEST=make && make runtests Change-Id: I4035bdb377aaebaca03a43799be57977166da739 Reviewed-on: http://gerrit.chromium.org/gerrit/4599 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
daa807c51ef6d5bf6599e649d1777432bea8a3e5 |
|
11-Jul-2011 |
Randall Spangler <rspangler@chromium.org> |
Add support for dev_boot_usb flag 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>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
9619112a574b975476667545e3a326052fa0c50b |
|
08-Jul-2011 |
Randall Spangler <rspangler@chromium.org> |
Vboot wrapper - add recovery reason, refactor timing 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>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
7adcc60e6f5f6db081b9ad6e02288335502a0d77 |
|
25-Jun-2011 |
Randall Spangler <rspangler@chromium.org> |
Vboot wrapper API - crossystem and header files Header file changes for wrapper API implementation Crossystem support for reading recovery reason from VbSharedData, and explicit support for version 1 VbSharedData structs. BUG=chromium-os:16970 TEST=make && make runtests; run crossystem on Alex and make sure it still reports recovery_reason in recovery mode. Change-Id: I15195b899583e425d3c9e8df09842d764528e2cb Reviewed-on: http://gerrit.chromium.org/gerrit/3203 Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org> Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
9243e616d727c3e57525f8dec2b5f22840900451 |
|
10-May-2011 |
Randall Spangler <rspangler@chromium.org> |
Add more specific recovery reasons for RW firmware invalid BUG=chrome-os-partner:3698 TEST=manual 1. Run the firmware key/version autoupdate test; this rolls forward your stored TPM version numbers. 2. Put back the original firmware. 3. Reboot. 4. Press TAB at recovery screen. 5. Should see Recovery Reason 0x14. Change-Id: I7791f594dbd8919e74d1e6b97b99775cf1e73d1d Reviewed-on: http://gerrit.chromium.org/gerrit/567 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
cabe6b3514f3228b350a7d07d6cc7cb39eecaaf6 |
|
18-Mar-2011 |
Randall Spangler <rspangler@chromium.org> |
Use VbSharedData instead of VbNvStorage for fwb_tries and kernkey_vfy Change-Id: I5ed3509a9d4e578cd2e98f493dab59bc2fbd5827 R=dlaurie@chromium.org BUG=chrome-os-partner:2748 TEST=manual crossystem fwb_tries=3 (reboot) crossystem tried_fwb (should print 1) crossystem fwb_tries=0 (reboot) crossystem tried_fwb (should print 0) In dev mode... Boot a kernel signed with the same key as in the firmware crossystem kernkey_vfy (should print sig) Boot a kernel signed with a different key than the firmware crossystem kernkey_vfy (should print hash) Review URL: http://codereview.chromium.org/6711045
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
99ca3466ba097cceacaff0129e9060578a8fcb20 |
|
15-Mar-2011 |
Randall Spangler <rspangler@chromium.org> |
LoadFirmware() and LoadKernel() handling for test errors Change-Id: Icecfcab8f5cc30e80da7a2d77a1b1729f5094fee R=wfrichar@chromium.org BUG=13107 TEST=make && make runtests Review URL: http://codereview.chromium.org/6673048
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
b17e8d353c50d46f0e5f29578f6294003692ea1d |
|
15-Mar-2011 |
Randall Spangler <rspangler@chromium.org> |
Add VB test error func/num Change-Id: Ibe253963f0424935554fe91f166ef5040a723c6f BUG=13107 TEST=make && make runtests Review URL: http://codereview.chromium.org/6698032
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
95c4031ce903258036beeed0705d25c7e9d25da0 |
|
10-Mar-2011 |
Randall Spangler <rspangler@chromium.org> |
This is necessary to pass additional information about whether firmware A or B is being run. This change also passes the GBB directly into LoadFirmware() and LoadKernel(). Change-Id: I976c11c82c3d665a4feb88226e919f16c2440f60 BUG=chrome-os-partner:1657 TEST=manual - see below make && make runtests Then test verifying a test image in both dev mode (-b1, no key specified) and recovery mode (key specified) build/utility/load_kernel_test -b1 ~/b/USB_images/0.11.224.0-alex/chromiumos_test_image.bin build/utility/load_kernel_test ~/b/USB_images/0.11.224.0-alex/chromiumos_test_image.bin tests/devkeys/recovery_key.vbpubk And make sure the firmware with this change actually boots to USB and SSD. NOTE: u-boot-next needs to change to work with this change. will attempt a follow-up CL with that change Review URL: http://codereview.chromium.org/6626045
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
640fb51d866e7ac8a92f61a2f69145bfe6b13699 |
|
03-Mar-2011 |
Randall Spangler <rspangler@chromium.org> |
Reapply patch from http://codereview.chromium.org/6594092/ (somehow that never got committed) Change-Id: I304e594066c5dd72fc7cf37d31e27b1096ae1a38 BUG=12282 TEST=make && make runtests Review URL: http://codereview.chromium.org/6610019
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
92e378e453c7c7186a06d9021fb64eb7985937f5 |
|
25-Feb-2011 |
Randall Spangler <rspangler@chromium.org> |
rename tried_fwb constants Change-Id: Ib8018bfe29eed50766c699d832efe4f1afcabb1a BUG=none TEST=make && make runtests Review URL: http://codereview.chromium.org/6597015
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
172602829dc0d79ed65d7ed81225389f090b981f |
|
25-Feb-2011 |
Randall Spangler <rspangler@chromium.org> |
Add NV storage fields for firmware flags 1) Did firmware attempt RW slot B before slot A? 2) Did firmware check the kernel keyblock signature, or just its hash? Added crossystem support as well. BUG=chrome-os-partner:1657 TEST=make && make runtests Review URL: http://codereview.chromium.org/6597011 Change-Id: I0d743ae87cedd938ba988170793717d3fdbd8ce9
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
9e162cdaa7433dff01d3e47ba3a47cb8b39ff3a1 |
|
22-Feb-2011 |
Randall Spangler <rspangler@chromium.org> |
VbNvStorage cleanup and comments BUG=12282 TEST=make && make runtests Review URL: http://codereview.chromium.org/6469059 Change-Id: I912b53ae33d65305353a747cc0bdd2b1ea62a04f
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|
b944534edd3799b3353f73bcb8ee90161d640c2b |
|
18-Feb-2011 |
Randall Spangler <rspangler@chromium.org> |
Add NV storage API to vboot reference BUG=chromium-os:12282 TEST=make && make runtests Review URL: http://codereview.chromium.org/6532040 Change-Id: I57099de54ed56aa722f1944568bbb58b71b14379
/external/vboot_reference/firmware/include/vboot_nvstorage.h
|