vbendeb 10fce4aa5d Automate bitmap image regeneration.
This CL modifies the bitmap generation script as follows:

- allow to specify required geometry of the images and to
 generate a single set per FWID instead of generating all
 geometries for all FWIDs

- store the images and the zip archive in a directory with
  the name derived from FWID.

The CL also adds a wrapper, which given the path to the tree
containing already released GBB firmware volumes would find
all valid (as verified by the CRC in the file name) FWIDs
and generate new images for all detected FWIDs.

The geometry of the generated images is based on the FWID
contents, Marios get 1280x800 and ZGAs - 1366x768.

Once this script stops running, the scripts/bitmaps
directory contains a set of subdirectories, one per
generated set of images.

Another script ran by cygwin on a windows machine was used
to pick up all image sets and regenerate GBB firmware
volumes, will be published under a separate CL.

BUG=chrome-os-partner:792
TEST=see below:

Ran the following command:
 ./process_all_targets.sh  ../../../chromeos-internal/third_party/autotest/files/client/site_tests/

After command completed, the following out_* directories showed up:

(bitmaps 144) ls -1d out*
out_ACER_ASPIREONE_001_8012/
out_ACER_ASPIREONE_001_DEV_0393/
out_ACER_ASPIREONE_002_0710/
out_ACER_ASPIREONE_002_DEV_1017/
out_IEC_MARIO_FISH_2330/
out_IEC_MARIO_PONY_6101/
out_IEC_MARIO_PONY_DEV_3342/
out_IEC_MARIO_PONY_DVT_8784/
out_IEC_MARIO_PONY_EVT_3495/
out_IEC_MARIO_PONY_PREDVT_6766/

with typical directory contents as follows:

(bitmaps 145) tree out_ACER_ASPIREONE_001_8012/
out_ACER_ASPIREONE_001_8012/
|-- 1366x768.zip
|-- BlankBmp
|   `-- BlankBmp.bmp
|-- DeveloperBmp
|   `-- DeveloperBmp.bmp
|-- RecoveryBmp
|   `-- RecoveryBmp.bmp
|-- RecoveryMissingOSBmp
|   `-- RecoveryMissingOSBmp.bmp
`-- RecoveryNoOSBmp
    `-- RecoveryNoOSBmp.bmp

5 directories, 6 files

Review URL: http://codereview.chromium.org/4147008
2010-10-29 08:09:48 -07:00
2010-08-05 16:42:43 -07:00
2010-08-05 14:18:38 -07: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.  Much like the
gpt tool, but with support for Chrome OS extensiosn.

host/ - Miscellaneous functions used by userland utilities.

utility/ - Utilities for generating and verifying signed
firmware and kernel images, as well as arbitrary blobs.

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/ - a directory where the generated files go to.

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

To build the software run

make

in the top level directory. The build output is placed in the ./build
directory.

To run the tests either invoke

RUNTESTS=1 make

in the top level directory or

cd tests
BUILD=../build make runtests


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

vbutil_key		Convert a public key into .vbpubk format
vbutil_keyblock		Wrap a public key inside a signature and checksum
vbutil_firmware		Create a .vblock with signature info for a
			firmware image
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 1: Generate RSA root and signing keys.

# Root key is always 8192 bits. 
$ openssl genrsa -F4 -out root_key.pem 8192

# 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
        utility/dumpRSAPublicKey

# dumpRSAPublicKey expects an x509 certificate as input.
$ 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
$ utility/dumpRSAPublicKey root_key.crt > root_key.keyb
$ utility/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 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%