delta/coreboot/vboot.git/firmware, branch stabilize-5712.61.B

Fix jumping EC from RO to RW if disable-jump was called on previous boot

2014-02-11T05:30:34+00:00

It's possible for the AP to get updated and remove the RO-normal flag
without needing to update EC-RW firmware - for example, if it only
needs to update the BIOS.  In this case, the EC doesn't need update,
but does need to jump to its RW firmware.  But if the EC is already
booted RO-normal with jump disabled, it will refuse that request and
go to recovery mode.

The fix is simply to check if the request to jump to RW requires the
EC to cold-boot first, and pass through that error code to the caller.

BUG=chrome-os-partner:22617
BRANCH=none (affects all platforms, but only in this odd case, and this
       is a change to the RW portion of the code)
TEST=pass new unit test which triggers this condition

Change-Id: Ia8d64dff784a9135ef23f6eb26bbca4ad9df57c3
Signed-off-by: Randall Spangler 
Reviewed-on: https://chromium-review.googlesource.com/170168
Reviewed-by: Vadim Bendebury

vboot: use recovery button as dev mode switch confirmation

2014-01-19T04:14:59+00:00

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 
Tested-by: Luigi Semenzato 
Commit-Queue: Luigi Semenzato

VbBootRecovery: Make second check for 'remove' devices if none found

2013-12-16T22:57:58+00:00

There is some inherent latency between the time the USB root hub is
initialized and the time USB devices are detected. This can lead to a
situation where USB media is attached, yet not found when we do our
initial device poll. The device may be detected in subsequent polls, so
the media can be booted and no 'remove' screen will be displayed.

With this change, if no media to remove is initially found, a second
poll will be made after a 500ms delay. This will be enough time for USB
devices to be correctly detected in our test cases.

Also, it is necessary to change the unit test due to the fact that we
now call VbExDiskGetInfo twice before actually displaying any screen.

TEST=Manual on Monroe. Insert USB media and trigger recovery boot.
Verify 'remove' screen is seen, 'insert' screen is seen after removing
media, and system boots after re-inserting media. Also passes
vboot_reference unit tests.
BUG=chrome-os-partner:23840
BRANCH=Panther, Monroe

Signed-off-by: Shawn Nematbakhsh 
Change-Id: Ia902c3a126588cd7ea618f2dbbca6b38d35d6ea0
Reviewed-on: https://chromium-review.googlesource.com/179757
Reviewed-by: Randall Spangler

Disable EC jump after RW image starts

2013-12-06T02:13:49+00:00

TEST=Built and booted Peppy. Ran flashrom from user space and
verified the EC firmware was updated after reboot.

CQ-DEPEND=CL:172651, CL:172652, CL:178324
BRANCH=none
BUG=chromium:325286
Signed-off-by: Daisuke Nojiri 
Change-Id: Ia73da70dbf3abb5ced48666e86715c8d24a431a0
Reviewed-on: https://chromium-review.googlesource.com/172635
Reviewed-by: Randall Spangler 
Tested-by: Daisuke Nojiri 
Commit-Queue: Daisuke Nojiri

Add memory leak checking

2013-09-17T23:17:17+00:00

Add checks that the vboot library does not leak memory. This works by
tracking VbExMalloc() calls and making sure that they have an associated
VbExFree().

Adjust host_signature to use VbExFree() instead of free(), so that this
scheme works correctly for existing code.

BUG=chrome-os-partner:21115
BRANCH=pit
TEST=FEATURES=test emerge-peach_pit vboot_reference

Change-Id: I6ccccfbcc162fc43fb75862cd0eddad78ce8b18a
Signed-off-by: Simon Glass 
Reviewed-on: https://chromium-review.googlesource.com/66175

Implementation of Region API

2013-08-30T16:47:03+00:00

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 
Signed-off-by: David Hendricks 
Reviewed-on: https://chromium-review.googlesource.com/63336
Reviewed-by: Randall Spangler 
Reviewed-on: https://chromium-review.googlesource.com/167361

Revert "Implementation of Region API"

2013-08-29T05:36:12+00:00

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 
Commit-Queue: Yoshiki Iguchi 
Tested-by: Yoshiki Iguchi

Implementation of Region API

2013-08-28T18:30:35+00:00

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 
Reviewed-on: https://chromium-review.googlesource.com/63336
Reviewed-by: Randall Spangler

Improve kernel tests to pass valgrind

2013-08-25T23:57:27+00:00

At present the kernel tests produce valgrind errors since the GPT data is
sometimes accessed before it is read. This is unnecessary, so update the
code to avoid this.

BUG=chrome-os-partner:21115
BRANCH=pit
TEST=manual
valgrind --leak-check=full  ./build/tests/vboot_kernel_tests

See that we no longer get valgrind errors.

Change-Id: I9e9660e38a62a735cf01a37c2d81ddb5ab8b1528
Signed-off-by: Simon Glass 
Reviewed-on: https://gerrit.chromium.org/gerrit/66173

Enable vboot for sandbox and improve debugging/format strings

2013-08-24T16:37:48+00:00

Some functions of vboot are disabled for sandbox because sandbox could not
support them. This has changed, so remove the sandbox #ifdefs in the code.

Some printf() strings cause warnings on sandbox - mostly that uin64_t is
not 'long long' on a 64-bit machine. The existing format strings in U-Boot
do not seem to take account of this, so add casts to remove the warnings.

Also add a few more debug strings to make it easier to see what is happening
in the vboot flow.

BUG=chrome-os-partner:21115
BRANCH=pit
TEST=manual
crosfw -b sandbox -V

See there are no warnings.

Change-Id: I86f90a693e4bd23fcacf6d48297dd32229348dd4
Signed-off-by: Simon Glass 
Reviewed-on: https://gerrit.chromium.org/gerrit/65621
Reviewed-by: Bill Richardson 
Reviewed-by: Randall Spangler