After this change vbutil_kernel allows to repack an existing
signed ChromeOS kernel such that the kernel command line is
changed on operator's request.
The new command line parameter is --verbose which causes
--verify to print out current contents of the kernel
command line.
Some refactoring and cleaning were also done:
- provide a macro to access command line buffer inside
a kernel blob
- ReadConfigFile() a new wrapper to preprocess the
config file.
- keep the key_block and preamble in the blob when
unpacking an existing signed kernel for --repack and
--verify.
- make --pack expect at least one of the two:
--config or --keyblock, thus allowing to change the
command line without replacing anything else in the
signed kernel image.
- refactor Verify() to use OldBlob() to preprocess the
image.
The top level Makefile was changed to allow compiling for debugging.
Build with DEBUG=1 in the make command line to enable gdb debugging and debug printouts. Build with DISABLE_NDEBUG=1 in the make command line to enable cryptolib debug outputs.
BUG=http://code.google.com/p/chromium-os/issues/detail?id=4814
TEST=see below
1. Observe that all unit tests still pass by running
(vboot_reference $) RUNTESTS=1 make
2. On a working DVT system copy the running kernel into a
file using
dd if=/dev/sda2 of=/tmp/dev.kernel
and transfer the file to the host into /tmp/try/dev.kernel
Then create the new config file in /tmp/try/new.conf.txt and run the following commands:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
(vboot_reference $) ./build/utility/vbutil_kernel --verify /tmp/try/dev.kernel --signpubkey tests/devkeys/kernel_subkey.vbpubk --verbose
Key block:
Size: 0x4b8
Data key algorithm: 4 RSA2048 SHA256
Data key version: 1
Flags: 7
Preamble:
Size: 0xfb48
Header version: 2.0
Kernel version: 1
Body load address: 0x100000
Body size: 0x302000
Bootloader address: 0x3fe000
Bootloader size: 0x4000
Body verification succeeded.
Config:
earlyprintk=serial,ttyS0,115200 console=ttyS0,115200 init=/sbin/init add_efi_memmap boot=local rootwait ro noresume noswap i915.modeset=1 loglevel=7 cros_secure root=/dev/sd%D%P dm_verity.error_behavior=2 dm_verity.max_bios=1024 dm="0 2097152 verity ROOT_DEV HASH_DEV 2097152 1 sha1 a7fbd641ba25488509987959d5756d802790ef8f" noinitrd
(vboot_reference $) ./build/utility/vbutil_kernel --repack /tmp/try/dev.kernel.repacked --signprivate tests/devkeys/kernel_data_key.vbprivk --oldblob /tmp/try/dev.kernel --config /tmp/try/new.conf.txt
(vboot_reference $) ./build/utility/vbutil_kernel --verify /tmp/try/dev.kernel.repacked --signpubkey tests/devkeys/kernel_subkey.vbpubk --verbose
Key block:
Size: 0x4b8
Data key algorithm: 4 RSA2048 SHA256
Data key version: 1
Flags: 7
Preamble:
Size: 0xfb48
Header version: 2.0
Kernel version: 1
Body load address: 0x100000
Body size: 0x302000
Bootloader address: 0x3fe000
Bootloader size: 0x4000
Body verification succeeded.
Config:
console=tty2 init=/sbin/init add_efi_memmap boot=local rootwait ro noresume noswap i915.modeset=1 loglevel=7 cros_secure root=/dev/sd%D%P dm_verity.error_behavior=2 dm_verity.max_bios=1024 dm="0 2097152 verity ROOT_DEV HASH_DEV 2097152 1 sha1 ff06384015a7726baff719ee68eab312b1d45570" noinitrd
(vboot_reference $)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Observe the chanegd command line printed by --verify --verbose. Then transfer the new kernel image back to the DVT system, dd it into /dev/sda2 and restart the DVT system.
Observe kernel startup messages dumped on the screen (due to the changed kernel command line).
Then examine /proc/cmdline to verify that the command line indeed matches the contents of /tmp/try/new.conf.txt on the host.
3. Build the code with
(vboot_reference$) DEBUG=1 make
observe that debug information is visible by gdb.
Build the code with
(vboot_reference$) DISABLE_DEBUG=1 make
and observe that -DNDEBUG is dropped from the compiler invocation line.
Review URL: http://codereview.chromium.org/3004001
This makes it much simpler to keep track of what we're doing.
vbutil_key can now wrap both .keyb and .pem keys. It figures out which is
which by trying both and just using the one that works.
vbutil_keyblock and vbutil_kernel now use .vbprivk files for signing.
replace debug() with VBDEBUG(()) in host-side sources, too.
rename PrivateKeyRead to PrivateKeyReadPem
Add real PrivateKeyRead and PrivateKeyWrite for .vbprivk files.
Review URL: http://codereview.chromium.org/2871033
The --repack option lets us sign a previously signed kernel blob with a new
kernel data key.
The --headeronly option is so we can emit the new verification header
separately from the kernel blob.
More work to come...
Review URL: http://codereview.chromium.org/2812034
Adds dump_kernel_config.c which takes in a file, reads it
all in to memory, then walks the blob until it can determine
the location of the kernel command line.
This is needed to allow the kernel config to inform legacy bootloader
configuration during autoupdates without packaging up dm-verity specific
options in some additional update metadata.
TEST=manual run over build_kernel_image.sh output
BUG=chromium-os:327
Review URL: http://codereview.chromium.org/2811029
This is a mostly NOOP change which modifies the source code
to compile cleanly in the MSVC command line build
environment.
A new makefile is introduced (msc/nmakefile) along with a
README.txt in the same directory explaining how to build
the code in the DOS window. As of this submission the build
is running in a 32 bit environment, the intention is to use
the same makefile for 64 bit builds in the future.
Enabling high compilation warnings level allowed to
identify a couple of bugs in the code which are being fixed.
Not all sources are being compiled in the MSVC environment,
only those in firmware/ and most of those in test/
subdirectories. The benchmark calculations require porting
of the timer facilities and are being postponed.
TEST
Built in DOS and linux environments. Ran unit tests in
linux environment.
Review URL: http://codereview.chromium.org/2809037
This makes it much easier to port vboot_firmware to platforms (such as
UEFI) which don't have the standard include files; only sysincludes.h
needs to be altered.
Review URL: http://codereview.chromium.org/2833012
CL (http://codereview.chromium.org/2845001) resulted in broken
dependencies.
This CL completes the modification (the trick is to ensure
that the default target is always the first).
Note that the tests subdirectory Makefile still does not
properly follow the dependencies, it will have to be
addressed in a separate CL.
Tested by touching different .h and .c files and observing the results.
Review URL: http://codereview.chromium.org/2819004
The fix is to use an explicit format statement.
Tested in chroot environment for x86-generic - was failing before the fix and passes after the fix.
TBR: msb
Review URL: http://codereview.chromium.org/2808009
Based on utility/vbutil_kernel.c.
Should be merged with it eventually. Not really tested either, suggesting to submit it just to have a baseline for the verified boot chain.
Review URL: http://codereview.chromium.org/2792014
After this change the generated files are placed in a
separate tree (such thet they don't show in the
`git status' output anymore) and the dependencies are
followed properly (if a .h file changes the
appropriate .o files and apps get rebuilt).
Tested as follows:
> $ make clean
> $ make # build succeeds
> $ git status # shows clean directory
> $ RUNTESTS=1 make # (captured test output matches that of the test run before any changes)
> $ touch ./vboot_firmware/include/tlcl.h
> $ make # make succeeds
> $ find build -type f -newer ./vboot_firmware/include/tlcl.h
build/vboot_firmware/lib/rollback_index.o
build/vboot_firmware/lib/rollback_index.o.d
build/vboot_firmware/a.out
build/vboot_fw.a
build/utility/vbutil_key
build/utility/kernel_utility.d
build/utility/vbutil_key.d
build/utility/verify_data
build/utility/load_kernel_test.d
build/utility/vbutil_keyblock.d
build/utility/vbutil_kernel
build/utility/vbutil_kernel.d
build/utility/firmware_utility
build/utility/signature_digest_utility.d
build/utility/kernel_utility
build/utility/verify_data.d
build/utility/vbutil_keyblock
build/utility/signature_digest_utility
build/utility/load_kernel_test
build/utility/firmware_utility.d
build/tests/vboot_common3_tests
build/tests/vboot_common2_tests
build/host/a.out
$ >
Review URL: http://codereview.chromium.org/2845001
This fixes a number of bugs, adds a bunch of commands, and essentially makes
cgpt ready to use as a replacement for gpt. Still to do is to add commands
and options that will let it generated intentionally bad partitions, for use
in testing.
Review URL: http://codereview.chromium.org/2719008
Firmware-side code for LoadKernel() is in place now. LoadFirmware() replacement coming soon.
The new functions are implemented in parallel to the existing ones (i.e., everything that used to work still does).
Review URL: http://codereview.chromium.org/2745007
We know where to look, and we'll look there regardless. We don't care where
the header creator thinks it should be.
Update tests to match.
Oh, and don't assume that I mean "/dev/FOO" if I just say "FOO". That's
really annoying.
Review URL: http://codereview.chromium.org/2606002
* now -g (get mode) becomes default
* properties are now managed in a more generalized way so adding new property would be more easy
Review URL: http://codereview.chromium.org/2549001
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
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
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
