delta/coreboot/vboot.git/utility, branch firmware-tricky-5829.B

Add an nvram flag to block the use of dev mode

2014-05-03T02:12:09+00:00

Currently, this does nothing. It just sets a flag that nothing looks at.

Don't get all wound up - we haven't abandoned our principles. This will
eventually be used to allow enterprise-enrolled customers to prevent
unauthorized use of developer mode in the Chrome OS devices that THEY OWN.

This is not Google deciding to turn a feature off, it's allowing the OWNER
to control the use of the feature. In some situations, the owner can be held
liable for what others do with the owner's equipment. This will help the
owner avoid those situations while their device is out of their immediate
control.

BUG=none
BRANCH=ToT
TEST=manual

Set the flag with:

  crossystem block_devmode=1

Clear it with:

  crossystem block_devmode=0

Retrieve the value ("0" or "1") like so:

  val=$(crossystem block_devmode)
  echo "the flag is $val"

or just test it directly like so:

  if crossystem 'block_devmode?1' ; then
    echo "devmode is blocked"
  else
    echo "devmode is allowed"
  fi

It should be persistent across reboots.

Change-Id: I097f15b307e1c3a2a9db595e9495028a2eea6309
Signed-off-by: Bill Richardson 
Reviewed-on: https://chromium-review.googlesource.com/197771
Reviewed-by: Hung-Te Lin 
Reviewed-by: Randall Spangler

Make crossystem.h more polite and more useful.

2013-10-31T21:56:58+00:00

This adds a VB_MAX_STRING_PROPERTY for callers that don't
want to guess at how big to make their buffers.

Additionally, it changes the size parameter to VbGetPropertyString()
from int to size_t.

BUG=None
TEST=compile the code
BRANCH=none

Change-Id: I22809d48e13b535593cb22a56444e2dcb27791a5
Reviewed-on: https://chromium-review.googlesource.com/175039
Reviewed-by: Randall Spangler 
Tested-by: Richard Barnette 
Reviewed-by: Bill Richardson 
Commit-Queue: Richard Barnette

Add a "debug_build" query to crossystem.

2013-10-23T18:53:43+00:00

Querying "debug_build" allows the caller to determine whether the
image has requested debug, independent of the setting of the
dev_mode switch.

BUG=chromium:308678
BRANCH=none
TEST=use the new command option on both base and dev images

Change-Id: I369f26d75156f2e88d9f6f467efbf8f633e78bda
Reviewed-on: https://chromium-review.googlesource.com/174107
Reviewed-by: Bill Richardson 
Tested-by: Richard Barnette 
Reviewed-by: Will Drewry 
Commit-Queue: Richard Barnette

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

Avoid exit code overflow for tpmc.

2013-08-28T15:50:54+00:00

In case of a TPM error, tpmc returns the TPM error code, which can
be greater than 255.  In that case the error code is truncated.
Some error codes, such as TPM_E_RETRY, end with a zero byte,
resulting in a successful exit code.  This is despicable.

BUG=chromium:234357
TEST=tested with exit codes < 255.  Too hard to generate the others.
BRANCH=none

Change-Id: I891a5c0659c06aac778449e2a0a935c5f82ccdb8
Reviewed-on: https://chromium-review.googlesource.com/66885
Reviewed-by: Luigi Semenzato 
Commit-Queue: Luigi Semenzato 
Tested-by: Luigi Semenzato

Change flashrom target selection parameter.

2013-08-22T02:19:43+00:00

The "-p internal:bus=*" is now deprecated by "-p {host,ec}" because we may have
EC on SPI bus.

BUG=none
TEST=manually executed dev_debug_vboot and see correct output.
BRANCH=none

Change-Id: I6363c09c2ebf57812bf35b7db220303a2786db20
Reviewed-on: https://gerrit.chromium.org/gerrit/66321
Tested-by: Hung-Te Lin 
Reviewed-by: Yung-Chieh Lo 
Commit-Queue: Hung-Te Lin

vbutil_kernel: copy zeropage fully

2013-04-11T18:29:39+00:00

When copying the vmlinuz zeropage, the entries were being truncated even
though the boot protocol version was being retained. This means that
booting a kernel that depended on details from the zeropage's ignored
areas would find invalid information. Fix this by copying out the entire
possible range of memory.

BUG=chromium:230212
TEST=kernels can boot with CONFIG_RELOCATABLE
BRANCH=None

Change-Id: Ifb94bedcf881e17ab20fff44d8c1c1885b15ef9e
Signed-off-by: Kees Cook 
Reviewed-on: https://gerrit.chromium.org/gerrit/47832
Reviewed-by: Luigi Semenzato 
Reviewed-by: Bill Richardson

Build dump_fmap into futility.

2013-04-09T22:55:02+00:00

This stops creating dump_fmap as a standalone utility and builds it into
futility. Since it was already invoked as a symlink, no user-visible changes
should be observed.

BUG=chromium:224734
BRANCH=none
TEST=manual, trybots

  sudo FEATURES=test emerge vboot_reference
  FEATURES=test emerge-$BOARD vboot_reference

Change-Id: I68d1bea0c1867043b2633e15509b95c2717009a7
Signed-off-by: Bill Richardson 
Reviewed-on: https://gerrit.chromium.org/gerrit/47672
Reviewed-by: Randall Spangler