mirror of
https://github.com/Telecominfraproject/OpenCellular.git
synced 2026-01-11 18:35:28 +00:00
c3574086a8
This CL builds upon earlier firmware and kernel changes (see CLs
related to the same bug, chromium-os:12522).
ARM firmware now simulates both Nvram storage and VDAT buffer, the
structures the x86 version uses extensively to communicate back and
forth between firmware/kernel/userland.
So, to make crossystem work on arm, all what's needed is to provide
architecture specific interface to Nvram and VDAT simulation, and
architecture specific processing for variables which are accessed on
ARM platforms in a different way.
The few discrepancies and platform specifics which had to be addressed
for ARM specifically are as follows:
- the Nvram contents are cached in the shared memory and available for
reading as part of /sys/kernel/debug/chromeos_arm. When writing
Nvram, the same file needs to be written, but only the 16 bytes
(representing the Nvram contents) are aacepted.
- the VDAT buffer also comes from the shared memory (as part of the
same sysfs file)
- when crossystem starts, it needs to read in this shared memory
contents, a` weak' function VbArchInit() is being added such that it
is provided on ARM platforms only, on x86 an empty stub is called.
- current developer/recovery request/ro firmware switch states are
retrieved through GPIO drivers. The GPIO numbers are defined in the
file, the GPIO driver is supposed to be configured before
crsossystem can operate.
- the BINF values are supplied through an array within shared memory,
it would be easy to refactor both x86 and ARM use the same code to
process BINF values, but with this submission the code is duplicated
to minimize x86 impact.
- the following crossystem variables do not have ARM equivalents,
thier values are reported as '(error)':
recoverysw_ec_boot
savedmem_base
savedmem_size
BUG=chromium-os:12522
TEST=manual:
. bring up a kaen system
. execute the following script to enable the appropriate GPIOSs:
for gpio in 56 59 168; do echo $gpio > /sys/class/gpio/export; done
. run `crossystem' and observe reasonable output values
. to verify that it reads GPIOs properly, try
echo $(./crossystem recoverysw_cur)
with the miniservo 'GOOG_REC' button pressed and released, observe
different readings (note that the state of the button is reversed,
the released button is reported as '1')
. to verify the write capabilities, note that the nvram contents can
be accessed using the following shell commands
echo 3 > /proc/sys/vm/drop_caches
2>/dev/null dd if=/dev/mmcblk0 of=/tmp/blk bs=16 count=1 && \
od -t x1 /tmp/blk | head -1
(the first command cause the device cache dropped, and the second
command accesses the device contents.
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
localhost var # echo $(./crossystem fwb_tries)
10
localhost var # echo 3 > /proc/sys/vm/drop_caches
localhost var # 2>/dev/null dd if=/dev/mmcblk0 of=/tmp/blk bs=16 count=1 && od -t x1 /tmp/blk | head -1
0000000 60 0a 00 be 00 00 00 00 00 00 00 02 00 00 00 a2
localhost var # ./crossystem fwb_tries=9
localhost var # echo $(./crossystem fwb_tries)
9
localhost var # echo 3 > /proc/sys/vm/drop_caches
localhost var # 2>/dev/null dd if=/dev/mmcblk0 of=/tmp/blk bs=16 count=1 && od -t x1 /tmp/blk | head -1
0000000 60 09 00 be 00 00 00 00 00 00 00 02 00 00 00 8a
localhost var #
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Change-Id: Ie4c6ff44441d98a42b1057953208fdb90c08f46d
Reviewed-on: http://gerrit.chromium.org/gerrit/113
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
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.