Duncan Laurie d187cd3fc7 vb2: Modify phase2 behavior for S3 resume case
If a platform does verification of memory init then it must be careful
to use the same slot for resume that it booted from.  This is
accomplished by adding a context flag to indicate this is an S3 resume
and that vboot should treat it differently than a normal boot.

When this flag is set then the same slot that was booted is read from
VBNV and re-used for the resume path, without adjusting any try flags.
If this slot is B then the related context flag is set.

This will allow the firmware updater to update the other (non-booted)
slot and set flags indicating that on the next boot the updated slot
should be tried, while still allowing suspend/resume to work with the
existing firmware slot.

This assumes that the last tried slot was successfully booted, which
should be a safe assumption since the system was able to boot and then
suspend.  It isn't reliable to check last_fw_result for "success"
status because that status is only set some time after boot when
chromeos-setgoodkernel calls chromeos-firmwareupdate --mode=bootok
and so it may still report a status of "trying" on resume depending
on how soon after boot the suspend happened.

It also avoids setting the vboot flag indicating that a slot choice
was made in order to avoid altering the try counter on failure since
this is explicitly not attempting to boot the new slot.

BUG=chromium:577269
BRANCH=glados
TEST=manually tested on chell:
1) ensure that booting from slot A resumes from slot A.
2) ensure that booting from slot B resumes from slot B.
3) do RW update while booted from slot A (so the flags are set to try
slot B) and ensure that suspend/resume still functions properly using
current slot A.
4) do RW update while booted from slot B (so the flags are set to try
slot A) and ensure that suspend/resume still functions properly using
current slot B.

Change-Id: I500faef2b5d19a02f32839976354abf6d551c9f6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/328812
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-02-23 16:58:50 -08:00
2015-12-16 03:35:12 -08:00
2010-08-05 16:42:43 -07:00
2014-09-02 20:25:22 +00:00
2010-08-05 14:18:38 -07:00
2015-03-18 23:07:42 +00:00
2010-06-17 13:22:34 -07:00

This directory contains a reference implementation for Chrome OS
verified boot in firmware.

----------
Directory Structure
----------

The source is organized into distinct modules -

firmware/

  Contains ONLY the code required by the BIOS to validate the secure boot
  components. There shouldn't be any code in here that signs or generates
  images. BIOS should require ONLY this directory to implement secure boot.
  Refer to firmware/README for futher details.

cgpt/

  Utility to read/write/modify GPT partitions. Similar to GNU parted or any
  other GPT tool, but this has support for Chrome OS extensions.

host/

  Miscellaneous functions needed by userland utilities.

futility/

  The "firmware utility" tool, used to create, sign, and validate Chrome OS
  images.

utility/

  Random other utilities, not necesssarily related to verified boot as such.

tests/

  User-land tests and benchmarks that test the reference implementation.
  Please have a look at these if you'd like to understand how to use the
  reference implementation.

build/

  The output directory where the generated files will be placed, and where
  tests are run.

scripts/

  Tools and scripts used to generate and use new signing keypairs. These are
  typically used only on a secure machine.


--------------------
Building and testing
--------------------

The suite can be built on the host or in the chroot environment.

Building on the host could fail if certain packages are not installed. If
there are host environment build problems due to missing .h files, try
researching what packages the files belong to and install the missing packages
before reporting a problem.


The commands are the more-or-less expected ones:

  make
  make runtests
  make install [ DESTDIR=/usr/local ]



----------
Some useful utilities:
----------

futility vbutil_key         Convert a public key into .vbpubk format
futility vbutil_keyblock    Wrap a public key inside a signature and checksum
futility vbutil_firmware    Create a .vblock with signature info for a
                              firmware image
futility vbutil_kernel      Pack a kernel image, bootloader, and config into
                              a signed binary

dumpRSAPublicKey            Dump RSA Public key (from a DER-encoded X509
                            certificate) in a format suitable for use by
                            RSAVerify* functions in crypto/.

verify_data.c               Verify a given signature on a given file.



----------
Generating a signed firmware image:
----------

* Step 0: Build the tools, install them somewhere.

* Step 1: Generate RSA root and signing keys.

  The root key is always 8192 bits.

    $ openssl genrsa -F4 -out root_key.pem 8192

  The signing key can be between 1024-8192 bits.

    $ openssl genrsa -F4 -out signing_key.pem <1024|2048|4096|8192>

  Note: The -F4 option must be specified to generate RSA keys with a public
  exponent of 65535. RSA keys with 3 as a public exponent (the default)
  won't work.

* Step 2: Generate pre-processed public versions of the above keys using
          dumpRSAPublicKey. This utility expects an x509 certificate as
          input, and emits an intermediate representation for further
          processing.

    $ openssl req -batch -new -x509 -key root_key.pem -out root_key.crt
    $ openssl req -batch -new -x509 -key signing_key.pem -out signing_key.crt
    $ dumpRSAPublicKey root_key.crt > root_key.keyb
    $ dumpRSAPublicKey signing_key.crt > signing_key.keyb

************** TODO: STUFF PAST HERE IS OUT OF DATE ***************

At this point we have all the requisite keys needed to generate a signed
firmware image.

.pem   RSA Public/Private Key Pair
.crt   X509 Key Certificate
.keyb  Pre-processed RSA Public Key


* Step 3: Use utility/firmware_utility to generate a signed firmare blob.

$ utility/firmware_utility --generate \
  --root_key root_key.pem \
  --firmware_sign_key signing_key.pem \
  --firmware_sign_key_pub signing_key.keyb \
  --firmware_sign_algorithm <algoid> \
  --firmware_key_version 1 \
  --firmware_version 1 \
  --in <firmware blob file> \
  --out <output file>

Where <algoid> is based on the signature algorithm to use for firmware
signining. The list of <algoid> specifications can be output by running
'utility/firmware_utility' without any arguments.

Note: --firmware_key_version and --firmware_version are part of a signed
      image and are used to prevent rollbacks to older version. For testing,
      they can just be set to valid values.


* Step 4: Verify that this image verifies.

$ utility/firmware_utility --verify \
                         --in <signed firmware image>
                         --root_key_pub root_key.keyb
Verification SUCCESS.


Note: The verification functions expects a pointer to the
      pre-processed public root key as input. For testing purposes,
      root_key.keyb can be stored in RW part of the firmware. For the
      final firmware, this will be a fixed public key which cannot be
      changed and must be stored in RO firmware.

----------
Generating a signed kernel image:
----------

The steps for generating a signed kernel image are similar to that of
a firmware image. Since verification is chained - RO firmware verifies
RW firmware which verifies the kernel, only the keys change. An additional
kernel signing key must be generated. The firmware signing generated above
is the root key equivalent for signed kernel images.
Description
No description provided
Readme 1.4 GiB
Languages
C 64.7%
Lasso 20.7%
ASL 3.6%
JavaScript 3.2%
C# 2.9%
Other 4.6%