| 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
|