2596c657958477b06d1613902dfe4d47a2ad0ae0 |
|
19-Nov-2014 |
Duncan Laurie <dlaurie@chromium.org> |
vboot: Add flag to indicate VbInit is run before option rom loading This commit adds a new VbInit() flag which will indicate that it is being called before option roms are loaded and can therefore respond to the VbNv flag without needing an immediate reboot. When the BIOS calls VbInit() in firmware it may not yet know if the system is in developer mode if there is a virtual developer mode switch, instead it relies on the VbNv flag that is prepared by VbInit(). So this new flag only affects VbInit() checks itself, the later checks still do the right thing because OPROM_LOADED can be set based on the VbNv value that is set by VbInit(). BUG=chrome-os-partner:32379 BRANCH=samus TEST=pass FAFT tests on samus Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Change-Id: I7a12f3d318a04ff43ac1ddfc0ba8baa112253bad Reviewed-on: https://chromium-review.googlesource.com/230885 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
731f8e8a1df73a00f4840120171b07a259a6304a |
|
16-Oct-2014 |
Duncan Laurie <dlaurie@chromium.org> |
vboot: Support SLOW_EC_UPDATE with OPROM_MATTERS In order to display the slow EC update screen on x86 devices in normal mode it is necessary to request a reboot where the VGA Option ROM is loaded. This needs a bit of plumbing to pass the OPROM_MATTERS and OPROM_LOADED flags into shared data so they can be consumed in the VbEcSoftwareSync() function. It also needs the VbInit() function to not immediately request a reboot if the VGA Option ROM was loaded in normal mode and the SLOW_EC flag is set as it will still need to be used during software sync. A FIXME in VbEcSoftwareSync() is implemented and the comment is removed, and two extra checks are done. First, if rebooting to RO then also check if the VGA Option ROM is needed to save an extra reboot, and second when exiting the software sync function request a reboot without the VGA Option ROM if it was done in normal mode and the option rom was needed+loaded. The request for a reboot from VbEcSoftwareSync() is saved when doing EC update in case there is an (optional) PD software sync that may also need to display the screen. BUG=chrome-os-partner:12257,chrome-os-partner:32379 BRANCH=samus TEST=all tests pass, manual testing: 1) in normal mode, with EC/PD in RW, ensure that they are rebooted to RO and the VGA Option ROM is loaded and the wait screen is displayed, and then the system is rebooted at the end and the VGA Option ROM is not loaded. 2) same as #1 with EC/PD in RO already, same result 3) same as #1 with system in developer mode, same result except there is no reboot at the end of software sync 4) same as #1 with system in developer mode and EC/PD in RO, ensure that there is no extra reboot at the beginning or end of software sync. Change-Id: Id592181efd640f4cd37a986cd1dcc29f3ca45104 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223718 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
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/lib/vboot_api_init.c
|
a53a0b040f45a1086515e7a5c8a8326c0b1d1f74 |
|
11-Jan-2014 |
Luigi Semenzato <semenzato@chromium.org> |
vboot: use recovery button as dev mode switch confirmation 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>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
527ba810eff4006cf69579f6b96cb4350cb1e189 |
|
25-Jul-2013 |
Simon Glass <sjg@chromium.org> |
Implementation of Region API 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
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
8fa13ad6f727d44fdc0ae1d2bde5f54b32dab9b9 |
|
29-Aug-2013 |
Yoshiki Iguchi <yoshiki@chromium.org> |
Revert "Implementation of Region API" This reverts commit 1d3c804b6b9d2ffb6953a7ee98fabfd548915ad7. This patch breaks cbuildbot on internal paladins bots. Change-Id: Icf7f9d9bbb56b092035888eaa3e249ffd23fac16 (cherry picked from commit 3a60335ebb1530e5fd9d5da3bc6214949bc59caf) Reviewed-on: https://chromium-review.googlesource.com/167451 Reviewed-by: Yoshiki Iguchi <yoshiki@chromium.org> Commit-Queue: Yoshiki Iguchi <yoshiki@chromium.org> Tested-by: Yoshiki Iguchi <yoshiki@chromium.org>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
1d3c804b6b9d2ffb6953a7ee98fabfd548915ad7 |
|
25-Jul-2013 |
Simon Glass <sjg@chromium.org> |
Implementation of Region API 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>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
d79f111427ab11919d9f91aa4f54c893f9e9986a |
|
26-Jul-2013 |
Aaron Durbin <adurbin@chromium.org> |
VbInit(): printout gbb flags as well It's extremely helpful to know what a device's gbb flags are when running vboot. It aids in debugging issues by providing more information and context. BUG=None BRANCH=None TEST=Built and booted. Checked log. Change-Id: I663de6f617f0e8c74e2b2f3b7a2be63f4a9c020a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/63489 Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
472d93c146403c0f95b656e182b972e15ff11835 |
|
23-Jul-2013 |
Shawn Nematbakhsh <shawnn@chromium.org> |
rollback_index: Remove recovery_mode parameter to SetupTPM. SetupTPM no longer uses recovery_mode parameter for anything other than a debug print. This change moves the debug print to a caller function, then removes recovery_mode from SetupTPM and some caller functions that no longer have a use for it. BUG=chrome-os-partner:20913. TEST=Manual. Boot factory install shim in recovery mode and verify TPM clear operations succeed. Boot in dev mode and verify "Lock physical presence" print on UART. BRANCH=None. Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I2f671f6680a6e67cf722855e659e99752bc0783c Reviewed-on: https://gerrit.chromium.org/gerrit/62916 Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
339b0ac9a0589c8287b0f9be6221934e8df268c6 |
|
10-Apr-2013 |
Randall Spangler <rspangler@chromium.org> |
Clarify comment in VbInit() In recovery mode we ignore all TPM errors. Just a comment change; no code change. BUG=none BRANCH=none TEST=build vboot Change-Id: I43ed89d0d38347b55e1f6e17b712814f9b972156 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/47747 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
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/lib/vboot_api_init.c
|
ac8805e7e9bd40c03baf44e37b26f28d9b763ab5 |
|
16-Mar-2013 |
Gabe Black <gabeblack@chromium.org> |
Get rid of some crufty macros. 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>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
7993f257af87c7c38cdc71b76bc67cde6c3cdbca |
|
30-Jan-2013 |
Randall Spangler <rspangler@chromium.org> |
Reformat to kernel style No code changes, just reformatting. BUG=none BRANCH=none TEST=make runtests Change-Id: Id690c8334147970784db5ac54933ad1f5a58dcc1 Reviewed-on: https://gerrit.chromium.org/gerrit/42263 Tested-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Queue: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
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/lib/vboot_api_init.c
|
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/lib/vboot_api_init.c
|
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/lib/vboot_api_init.c
|
9dc62178c97b94e5c308f1c36fd0858c316959e5 |
|
29-Aug-2012 |
Bill Richardson <wfrichar@chromium.org> |
Add VB_INIT_FLAG_SW_WP_ENABLED to VbInit() input flags. 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>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
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/lib/vboot_api_init.c
|
f217520215e7e3d2f5ca006992ab5002927c4f87 |
|
07-Aug-2012 |
Bill Richardson <wfrichar@chromium.org> |
vboot: add flag to indicate that the EC is slow to program 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>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
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/lib/vboot_api_init.c
|
88d9375f50726fb26f1d4fcb909aa15256e24a17 |
|
11-Jul-2012 |
Bill Richardson <wfrichar@chromium.org> |
Ensure that the VGA is enabled/disabled as needed. On some systems, we require the VGA option ROM to be loaded before VbInit() is called so we can display BIOS screens. If that hasn't happened, we request it and reboot. Alternatively, if we don't need the option ROM (normal mode) but we've already loaded it, we un-request it and reboot just in case there are security vulnerabilities that might be exposed. Not all systems need preloaded option ROMs. There is an additional input flag that indicates whether this matters or not. BUG=chrome-os-partner:8789 TEST=manual Using keyboard-based dev-mode, switch between normal and dev mode and back. It should work as expected. Change-Id: Id1d662014d47ab648c73db4b1647520801f3a0b8 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/27125 Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
dc6b642b47168a09fa1702092961595ab0674c03 |
|
02-Jul-2012 |
Che-Liang Chiou <clchiou@chromium.org> |
Set/clear developer mode flag in VbInit output This would allow caller of VbInit know if vboot is on developer mode. Signed-off-by: Che-Liang Chiou <clchiou@chromium.org> BUG=chrome-os-partner:10947 TEST=Snow U-Boot successfully read the correct value of the flag Change-Id: If1d88975892045467f5ab9d00b00ed53765b83f1 Reviewed-on: https://gerrit.chromium.org/gerrit/26557 Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org> Commit-Ready: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
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/lib/vboot_api_init.c
|
acd6f4688abb9a0253bb469a8a52046c97281347 |
|
14-Jun-2012 |
Randall Spangler <rspangler@chromium.org> |
Add GBB flags to enable dev mode by default 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>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
ec8df1628cd9cf236bf912dee7d4365d7977e697 |
|
07-Jun-2012 |
Bill Richardson <wfrichar@chromium.org> |
Support virtual dev-switch (keyboard-based dev-mode) 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>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
6f4cc5635916b071fe8c689805b65f8feff8c205 |
|
24-May-2012 |
Bill Richardson <wfrichar@chromium.org> |
Honor both fake_dev and virtual dev switch BUG=chrome-os-partner:9706 TEST=none No test yet. The entire boot/dev-mode/recovery flow depends on this working. This is only part of the process, which will eventually be tested through FAFT. Change-Id: Iea6eaf59d4f349590cf9b920e4effb6a2641b2dc Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/23657 Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
b75d8adcc01f08cf5a6d87b78aeb1d7cdfcd22af |
|
17-May-2012 |
Bill Richardson <wfrichar@chromium.org> |
Use virtual dev-mode switch when told to. If VbInit() is instructed to look at a virtual dev-mode switch, then it will use value contained in the TPM's firmware space instead of a hardware GPIO to determine if developer mode is enabled. This change just makes it look. It doesn't provide a way to actually set the value in the TPM. VbInit() isn't being told to look yet, either. Those changes are coming. BUG=chrome-os-partner:9706 TEST=none The usual sanity-check applies: make make runtests But to actually test that this stuff is working IRL requires special tweaks to other components and monitoring the serial debug output from both EC and CPU. We'll save the hands-on tests for when it's all done. Change-Id: Ie485ad2180224e192238bf2a5dbf95bbcb9130f9 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/23067 Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
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/lib/vboot_api_init.c
|
0d11efb0dc1d8d2b5eafdd5b65bce82e73fdeecc |
|
15-Nov-2011 |
Bill Richardson <wfrichar@chromium.org> |
Add VB_INIT_OUT_ENABLE_ALTERNATE_OS flag 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>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
c8e4ff7c15e6bf5992a578b66bec47d69cde3bea |
|
10-Nov-2011 |
Bill Richardson <wfrichar@chromium.org> |
Add flag to GBB to allow loading PCI Option ROMs As shipped, H2C only loads the option ROM for the built-in video, and that only when it needs display the BIOS warning screens. By setting a flag in the GBB, you can allow all option ROMs to be loaded: Note that we'll never enable this ourselves (and there's a factory test to ensure that*) because it executes non-verified code. But if a customer wants to void their warranty and set this flag in the read-only flash so they can install and use other PCI devices, they should be able to do so. BUG=chrome-os-partner:6148 TEST=none The only way to test this is to use a BIOS that was compiled with serial debugging enabled, so there's nothing for QA to do. If you have such a BIOS, you can see the difference like so: flashrom -r oldbios.bin gbb_utility -s --flags=2 oldbios.bin newbios.bin flashrom -w newbios.bin <reboot> When bit 1 of the GBB flags is 0, you'll see these lines in the serial output: LoadOpRomImage-->GetSystemConfigurationTable Status = Success LoadOpRomImage-->GetH2cBootMode Status = Success When bit 1 of the GBB flags is 1, you'll see these lines in the serial output: LoadOpRomImage-->GetSystemConfigurationTable Status = Success LoadOpRomImage-->GetH2cBootMode Status = Success LoadOpRomImage-->PCI OpRom on 1.0.0 is allowed!!! This happens in any boot mode (normal, developer, recovery). -- *The factory test for GBB zero flags is gft_clear_gbb_flags.sh, in src/platform/factory_test_tools Change-Id: I31a10cc9d562b4b83669ca8a114b60e87ae28b0a Reviewed-on: https://gerrit.chromium.org/gerrit/11505 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Gaurav Shah <gauravsh@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
1cf77cda5ea2d7549caccb953079263d463feadb |
|
25-Jul-2011 |
Randall Spangler <rspangler@chromium.org> |
Return more meaningful error codes from vboot entry points 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>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
8bf0d5ff0ff77aaf496507bbe8d65a5f3027c80c |
|
14-Jul-2011 |
Randall Spangler <rspangler@chromium.org> |
Add vboot support for RO-normal code path. BUG=chromium-os:17304 TEST=make && make runtests Change-Id: I4d0f8afd516649fba67119845ec1c4479ba54c43 Reviewed-on: http://gerrit.chromium.org/gerrit/4065 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|
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/lib/vboot_api_init.c
|
1b1998dff0002f20b3f27a21e6e79d8951e64684 |
|
02-Jul-2011 |
Randall Spangler <rspangler@chromium.org> |
Vboot wrapper initial implementation Patch 1: Initial change Patch 2: Fix comment in vboot_struct.h Patch 3: Revert files unintentionally reverted Patch 4: (rebase) Patch 5: (rebase) Patch 6: Revert files unintentionally reverted (again) Patch 7: Fix mocked tlcl for ARM build BUG=chromium-os:17010 TEST=make && make runtests; works on H2C; emerge-tegra2_seaboard chromeos-bootimage compiles Change-Id: I6e5ce72d41b9297c07a3f330a881eba68cfabee2 Reviewed-on: http://gerrit.chromium.org/gerrit/3593 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/lib/vboot_api_init.c
|