Also includes part of LoadKernel(), which I'll split into a separate
CL. With some hacks, gets into VerifyKernel() before dying because
I'm not passing in the right key blob.
cgptlib is now pretty stable, and worth looking at. LoadKernel() less so.
Thanks,
Randall
Review URL: http://codereview.chromium.org/2438005
With this change, just like the kernel signing utility, the firmware signing utility now supports outputting the key signature (subkey) header and reusing it to generate new signed firmware images without requiring the root key (assuming the firmware signing key doesn't change).
Also, some minor comment fixes I missed the last time around.
Review URL: http://codereview.chromium.org/2366004
This allows for using an existing key signature (subkey) header to generate new signed images if the kernel signing is unchanged. This obviates the need to take out the firmware private key each time a new signed kernel image is generated.
A similar change will also be propagated to the firmware signing utility. We would REALLY like to reduce the need to take out the verified boot private root key (used for generating R/W firmware key signature headers) everytime we generate a new signed R/W firmware image.
Review URL: http://codereview.chromium.org/2372001
Rather than copying individual fields. More suitable for use in LoadKernel().
Added StatefulSkip(), so that fields in the input stream can be skipped more cleanly.
Review URL: http://codereview.chromium.org/2327001
This option makes the signing utility just output the kernel subkey (key signature) header which can be used to generate subsequent signed kernel images without needing the firmware root key and using the same kernel signing key. (This feature will be a part of a subsequent CL).
Review URL: http://codereview.chromium.org/2310002
We want the BIOS to implement the stub functions, but that shouldn't include
our StatefulMem* functions.
Also, we ensure that we don't accidently use native linux functions instead
of the stub functions.
Review URL: http://codereview.chromium.org/2255006
For the --generate operation, the --in <file> option is gone and there are
three new required options:
--vmlinuz <file> Embedded kernel image
--config <file> Embedded kernel command-line parameters
--bootloader <file> Embedded bootloader stub
This takes the specified kernel, extracts the 32-bit component, and combines
that with the configuration file (essentially just the kernel cmdline
string) and the bootstub image . The resulting blob is signed and ready to
put in a kernel partition.
There's also an optional --padding parameter, to specify how much extra
(unsigned) space to leave between the signature header and the kernel blob.
The default is 0x4000, which is about four times as much needed when using
the largest signature size we currently support.
Review URL: http://codereview.chromium.org/2283005
Sorry for late. I spent some time to handle Guid endian issue and UTF16/UTF8 consversion. Also, refactored code for incoming commands.
Review URL: http://codereview.chromium.org/2231002
With this change, the kernel signature is a part of the preamble block (and therefore, used during preamble signature verification).
BUG=670
TEST=image verification tests still pass. corrected splicing test expectations (and it passes).
Review URL: http://codereview.chromium.org/2292001
This CL adds 2 things:
- Instead of having a kernel config, now we have a kernel preamble which contains some important parameters needed by the bootloader in the firmware to kernel hand-off. These parameters are verified using a separate preamble signature in addition to the kernel signature on actual kernel image data.
- Adds a new VerifyKernelHeader() API function which verifies the kernel verified boot header excluding the kernel data and also extracts parameters out of this header needed to verify the actual kernel image data (if deemed necessary). This allows for vboot header verification and data verification to be performed separately.
Review URL: http://codereview.chromium.org/2234003
This creates a new vboot_firmware subdirectory, and which contains the
entirety of the BIOS code. There shouldn't be anything in this directory
that is NOT required by the BIOS.
Review URL: http://codereview.chromium.org/2219004
LoadKernel() needs to pass the kernel partition number out to the
BIOS, so it can be passed to the bootloader.
Review URL: http://codereview.chromium.org/2161007
Fix improper test of return value, replace order-dependent indices with
enumerated types in option parsing.
Review URL: http://codereview.chromium.org/2183001
The kernel_config is now stored as a 4K binary block instead of the kconfig_options structure that was being used before. Since the verified boot code doesn't care what kernel config options are (other than the length of the kernel image and for verifying them before the rest of kernel), it is ok to keep them as a blackbox.
This CL also changes the verified boot kernel layout - VBlock Data followed by Kernel Config followed by the Kernel Image. This will allow them to be stored separately, or as a concatenated block (for easy memory mapping during kernel load). This should ease the process of generating a layout for verified boot kernel images which is also compatible with legacy BIOSes that don't support this mechanism.
Finally, there is also a new firmware API function to determine the size of a kernel verified boot block, given a pointer to its beginning (for determining the offset to the kernel config and data).
Review URL: http://codereview.chromium.org/1732022
The CL adds the --config and --vblock option to kernel_utility.
--config <file> uses the file to populate the configuration portion within a signed vbootimage
Currently, the configuration file is assumed to only contain command line options to be passed to the kernel. In the future, we might want to change it so that it contains information about the kernel load address, entry points, etc. (refer to rspangler@ drive map design doc)
--vblock makes the tool only output the verification header instead of a one monolithic signed kernel image containing the verification information (with config information contained within it) followed by the actual kernel image
Review URL: http://codereview.chromium.org/1752013
The firmware verification code no longer assumes that verification data and firmware data are contiguous and follow each other. Needed for EFI where the actual firmware must be stored in its own firmware volume.
BUG=1704
TEST=modified existing tests for the new API, and they still pass
Review URL: http://codereview.chromium.org/1578035
Needed if the verification block needs to be stored separately than the actual firmware data instead of one monlithic blob.
TEST = Tried the new option and verified that the output is correct.
Review URL: http://codereview.chromium.org/1525032
This should make it easier to switch off debug messages if needed.
TESTS=builds fine, autotest builds fine (using both arm/x86-generic)
Review URL: http://codereview.chromium.org/1607006
Refactor and restructure reference code into individual self-contain modules. I have revamped the way the code is structured to make it easy to determine which parts belong in the firmware and which are used by userland tools.
common/ - common utilities and stub functions (Firmware)
cryptolib/ - crypto library (Firmware)
misclibs/ - miscellaneous userland libraries (Userland)
sctips/ - Miscellaenous scripts (Userland)
tests/ - Tests (Userland)
vfirmware/ - Verified Firmware Implementation
vfirmware/firmware_image_fw.c (Firmware)
vfirmware/firmware_image.c (Userland)
vkernel/ - Verified Kernel Implementation
vkernel/kernel_image_fw.c (Firmware)
vkernel/kernel_image.c (Userland)
Review URL: http://codereview.chromium.org/1581005
