delta/coreboot/vboot.git/firmware, branch factory-3536.B

Use a separate knob for SHA512 unrolling

2012-12-26T18:37:43+00:00

The SH512 code gets quite large when unrolled, about 20KB larger on x86.
This is a net loss on machines with slow SPI. Split this out into a
separate knob, and don't enable it on any architecture for now.

Also swap the code around so that we do #ifdef...#else...#endif instead
of #ifndef...#else...#endif.

BUG=chrome-os-partner:13961
BRANCH=none
TEST=manual
build and boot to kernel on link

U-Boot image size before this change:
   text	   data	    bss	    dec	    hex	filename
 319403	   8260	  83988	 411651	  64803	u-boot

after:
 293227	   8260	  85492	 386979	  5e7a3	u-boot

This is a saving of about 25KB.

Signed-off-by: Simon Glass 

Change-Id: I9fa7ea8eba6691d8a06df9374950303e6f2ce2fd
Reviewed-on: https://gerrit.chromium.org/gerrit/40155
Reviewed-by: Randall Spangler 
Commit-Queue: Simon Glass 
Tested-by: Simon Glass

Add support for a V option which selects verbose Makefile output.

2012-12-21T20:42:42+00:00

When V=1, the full command lines are printed. When V is not 1, then only a
small summary line is printed which shows what commands are being executed.
The command lines themselves are usually quite long and are overwhelming to
see fly by on the console. Abbreviated command lines are easier to read and
don't fill up your console so quickly.

This change is primarily targeted at vboot_fw.a and probably excludes some
things which could also be converted. The indentation between the action
string (OBJCOPY, CC, etc.) and the target is three spaces longer than "normal",
aka what's used in depthcharge, so that when this make is run from the other,
you can tell the difference between the commands run by each.

BUG=chrome-os-partner:8339
TEST=Built with and without V=1 and saw and did not see the full command
lines, respectively.
BRANCH=None

Change-Id: Ibee244c24dc44b8da109b8c23ac7273174836bb9
Signed-off-by: Gabe Black 
Reviewed-on: https://gerrit.chromium.org/gerrit/40011
Reviewed-by: Randall Spangler 
Reviewed-by: Che-Liang Chiou 
Commit-Queue: Gabe Black 
Tested-by: Gabe Black

Add recovery_subcode field to nvstorage and crossystem

2012-12-18T01:05:01+00:00

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 
Reviewed-on: https://gerrit.chromium.org/gerrit/39803
Reviewed-by: Randall Spangler

tlcl: move open retry into Tlcl

2012-12-12T21:37:33+00:00

Make sure all Tlcl users benefit from the new retry logic.

BUG=None
TEST=daisy build, manual testing of racing tpmc loops
BRANCH=None

Change-Id: I8e9656a65b5d6b45694c1c8bceb95f54f7c751bb
Signed-off-by: Kees Cook 
Reviewed-on: https://gerrit.chromium.org/gerrit/39525
Reviewed-by: Luigi Semenzato

Tlcl: allow OS failures to bubble up to caller

2012-11-29T05:35:49+00:00

If there were any errors communicating with the TPM at the OS layer
(open, read, write failures), the library would immediately exit, not
allowing the caller to make any decisions about how to handle it. This
introduces a way to initialize the library so that errors will get passed
back up to the caller instead of unceremoniously exiting.

Setting the environment variable "TPM_NO_EXIT=1" enables the feature. To
avoid needing to implement supporting functions in all backends, the
feature is currently limited to just the Tlcl stub implementation.

In the case of mount-encrypted, it can now survive the kernel returning
read/write failures. In the past it had only worked around having open
fail, but that has now been replaced with more sensible logic instead of
the environment variable trickiness.

BUG=chrome-os-partner:15960
TEST=daisy built with an always-failing kernel driver, u-boot builds too
BRANCH=None

Change-Id: Ic7b217017537980f9c239d678067398613045676
Signed-off-by: Kees Cook 
Reviewed-on: https://gerrit.chromium.org/gerrit/38791
Reviewed-by: Luigi Semenzato

Add more recovery_reason codes

2012-11-26T20:04:42+00:00

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 
Tested-by: Bill Richardson 
Reviewed-by: Randall Spangler

Add FAFT keyboard remap GBB flag

2012-11-06T19:40:28+00:00

Add a new flag, 0x100, to indicate FAFT key stroke overrides.

BUG=chrome-os-partner:14056
TEST=none
BRANCH=stout

Change-Id: I76b7f3f4c51abec5528047f690f20a09b257abc2
Signed-off-by: Marc Jones 
Reviewed-on: https://gerrit.chromium.org/gerrit/37074
Reviewed-by: Ronald G. Minnich 
Reviewed-by: Gediminas Ramanauskas 
Tested-by: Gediminas Ramanauskas 
Commit-Ready: Marc Jones

vboot_reference: Fix keyboard input lag at confirm screen.

2012-10-31T01:23:50+00:00

Changing languages is terribly slow at the confirm screen, when
switching from dev to normal. Reduce sleep time to improve user
experience.

BUG=chrome-os-partner:15726
TEST=boot in dev, hit space, hit arrows rapidly to change language,
observe no lag.
BRANCH=butterfly, stout

Change-Id: I0943debc31d78dcfce87e7f7d4537ae47f5f8cfd
Reviewed-on: https://gerrit.chromium.org/gerrit/36956
Reviewed-by: Duncan Laurie 
Reviewed-by: Bill Richardson 
Commit-Ready: Shawn Nematbakhsh 
Tested-by: Shawn Nematbakhsh 
Reviewed-by: Randall Spangler

Add recovery reason for failure to correct TPM error

2012-10-29T21:49:36+00:00

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 
Reviewed-by: Randall Spangler 
Commit-Ready: Luigi Semenzato

mount-encrypted: handle missing TPM on Chrome OS

2012-10-12T21:24:42+00:00

While not having a TPM was supported for non-Chrome devices, it was not
expected for Chrome devices. This adds logic to fail the TPM calls
before making them when the TPM is missing. The tpm_lite library doesn't
handle the TPM being missing, so we have to do this ourselves.

BUG=chrome-os-partner:15192
TEST=parrot build, verified operation after "mv /dev/tpm0 /dev/tpm0.bak"
BRANCH=none

Change-Id: I2f625305dce7fa698fcad33e412ee37c60da9bc2
Signed-off-by: Kees Cook 
Reviewed-on: https://gerrit.chromium.org/gerrit/35440
Reviewed-by: Luigi Semenzato 
Reviewed-by: Will Drewry