Commit Graph

31 Commits

Author SHA1 Message Date
Kees Cook
e0e4ed404b vbutil_kernel: copy zeropage fully
When copying the vmlinuz zeropage, the entries were being truncated even
though the boot protocol version was being retained. This means that
booting a kernel that depended on details from the zeropage's ignored
areas would find invalid information. Fix this by copying out the entire
possible range of memory.

BUG=chromium:230212
TEST=kernels can boot with CONFIG_RELOCATABLE
BRANCH=None

Change-Id: Ifb94bedcf881e17ab20fff44d8c1c1885b15ef9e
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47832
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
2013-04-11 11:29:39 -07:00
Vincent Palatin
56c85db710 Allow vbutil_kernel to work on block devices
Block devices return a size of 0 when stat'ed.
In order to be able to verify directly a raw partition, let's add a
special case to query the block device size.

BUG=chromium-os:34176
TEST="vbutil_kernel --verify /dev/sda4 --verbose" shows the actual
content not an error message.
BRANCH=none

Change-Id: Ibecf0a88816abf97305f0f87c0131ba7b66e386c
Reviewed-on: https://gerrit.chromium.org/gerrit/32302
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Jon Salz <jsalz@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
2012-09-06 17:32:38 -07:00
Lucian Cojocar
2312ab6122 vbutil_kernel: gracefully exit if the config file is bad
If the config file is specified in the parameter list but we aren't able
to open (or read) the file, vbutil_kernel should return an error instead
of crashing with a Segmentation Fault.

BUG=chromium-os:33087
TEST=manual

Invoke vbutil_kernel with a bogus path for the config file (--config).

Change-Id: I32dab7c381b9094f4015a554bc59989f1bb329ef
Signed-off-by: Lucian Cojocar <cojocar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28740
Reviewed-by: Randall Spangler <rspangler@chromium.org>
2012-07-31 12:34:11 -07:00
Bill Richardson
f47291926a Require -Wall -Werror for everything.
BUG=none
TEST=none

Change-Id: Ib9781238274285f73d00d8fca4ecda28fc2c6678
Reviewed-on: https://gerrit.chromium.org/gerrit/21748
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
2012-05-03 17:38:57 -07:00
Bill Richardson
72e344d5cd Major refactoring of vbutil_kernel
This started out as a simple fix for a minor bug and turned into a nearly
complete rewrite. Now that it's done I'm not sure it really matters. This
version is a lot cleaner about handling command-line args, but isn't
otherwise noticeably better. Sigh.

BUG=none
TEST=manual

make
make runtests

Change-Id: I9c194e9c0e6418488635989ef666bc83c6e39816
Reviewed-on: https://gerrit.chromium.org/gerrit/18268
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
2012-03-20 10:26:44 -07:00
Bill Richardson
bde0696234 Make vbutil_kernel use correct size when verifying headers.
Added a test to demonstrate the fix.

BUG=none
TEST=manual

make
make runtests

Change-Id: I06e85b993cbe21088641a62d55a3d3ddb696ba76
Reviewed-on: https://gerrit.chromium.org/gerrit/18240
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
2012-03-15 12:00:24 -07:00
Bill Richardson
c8b9ca6856 Rename some static struct members in vbutil_kernel.
I've found a bug in vbutil_kernel, but the names of some of the internal
variables and struct members make it hard to follow (which is probably why
the bug exists). Before I fix it, I need to rename some things so we can see
what's wrong. This does that.

BUG=none (yet)
TEST=manual

make
make runtests

Change-Id: I8646c8acd33c58ccd52668943bcee4d0664716aa
Reviewed-on: https://gerrit.chromium.org/gerrit/18146
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
2012-03-14 17:40:06 -07:00
Sonny Rao
7455473315 vbutil: accept amd64 as a valid alias for x86
The rest of the chromiumos build system uses amd64 as the
architecture name for 64bit x86.  This adds support for this
name to vbutil.

BUG=chromium-os:21284
TEST=vbutil --arch amd64 should not return unknown architecture

Change-Id: I37531591a7a31486f6447ae611d54569d1ea59d5
Reviewed-on: http://gerrit.chromium.org/gerrit/9959
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
2011-10-12 15:53:05 -07:00
Sonny Rao
06edfc60f3 vbutil: support 64bit x86
This changes the code accept x86.* as an alias for x86 architecture
since both x86 and x86_64 systems will handle things identically

BUG=chromium-os:20336
TEST=try to use update_kernel.sh on a system running an x86_64 kernel

Change-Id: Icf18925bdb8583cd53c6f6254c7493bdec540465
Reviewed-on: http://gerrit.chromium.org/gerrit/7873
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
2011-09-19 00:28:21 -07:00
Randall Spangler
32a6526d25 Verified boot wrapper - add stub implementations for host
This is part 2 of the wrapper API refactor.  It adds stub
implementations for the host, and changes the host-side utilities to
use them.  Firmware implementation is unchanged in this CL (other than
a few updates to macros).

BUG=chromium_os:16997
TEST=make && make runtests

Change-Id: I63989bd11de1f2239ddae256beaccd31bfb5acef
Reviewed-on: http://gerrit.chromium.org/gerrit/3256
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
2011-06-27 13:30:41 -07:00
Randall Spangler
7ecb39d419 Check whether key block and preamble fit in padding.
Also add --pad as a valid option to --repack and --verify, so that
kernels with larger-than-normal padding can be verified.

BUG=chromium-os:13720
TEST=see bug 13720

Using the supplied kernel images from the bug,

vbutil_kernel --verify 007 --debug
vbutil_kernel --verify 008 --debug

These should now fail with an error that the key block extends past the padding.

Next, supply a large enough padding size that the key block and
preamble fit.  For example:

vbutil_kernel --verify 007 --pad 0x900000 --debug
vbutil_kernel --verify 008 --pad 0x900000 --debug

These should now make it past the padding check, and fail on a
subsequent test (for example, no kernel blob found).

Change-Id: I7ec32b4def29970e302bf922b96d3e206d97fe82
Reviewed-on: http://gerrit.chromium.org/gerrit/810
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
2011-05-13 12:49:22 -07:00
Randall Spangler
ae87b92cbe Add --minversion option to vbutil_kernel to check for rollback.
BUG=chrome-os-partner:3309
TEST=manual:

1. Extract a kernel partition from an image, for example, using
unpack_partitions.sh.  Or if running this on a device, use /dev/sda2
or /dev/sda4 for the kernel filename.

2. vbutil_kernel --verify part_2

3. Note the data key version and kernel version printed.  For example,

  Data key version:    1
  Kernel version:      3

4. Test specifying the same version.  This should succeed.

   vbutil_kernel --verify part_2 --minversion 0x00010003

5. Test specifying a higher data key version.  This should fail with a
data key version error.

   vbutil_kernel --verify part_2 --minversion 0x00020003

6. Test specifying a higher kernel version.  This should fail with a
kernel version error.

   vbutil_kernel --verify part_2 --minversion 0x00010004

Change-Id: I7b69041cf41527fc59ad29995135f30d9f496fac
Reviewed-on: http://gerrit.chromium.org/gerrit/792
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
2011-05-12 15:08:28 -07:00
Che-Liang Chiou
2c0711bf54 Revert "Revert "Add --kloadaddr option to utilities""
This reverts commit bc7a84d9a1.

It was a false alarm that --kloadaddr causes chromeos-install on a
x86 targets to fail. The error of chromeos-install cannot be
reproduced, and judging by the reported error message, the error
should not be attributed to --kloadaddr, which has no effect in x86
targets. So --kloadaddr is restored.

Verification process are below:

(Verify that --kloadaddr option is restored)
$ dump_kernel_config -h
Expected argument after options
dump_kernel_config - Prints the kernel command line

Usage:  dump_kernel_config [--kloadaddr <ADDRESS>] <image/blockdevice>

(Setup a x86 target with kernel-next profile)
$ rm -rf /build/${X86_TARGET}
$ ./setup_board --board=${X86_TARGET} --profile=kernel-next
$ ./build_packages --board=${X86_TARGET}
$ ./build_image --board=${X86_TARGET}

(Run chromeos-install on target machine successfully)
$ /usr/sbin/chromeos-install

(Change directory to where image sits)
$ cd ~/trunk/src/build/images/${X86_TARGET}/latest

(Unpack Chromium OS image)
$ ./unpack_partitions.sh chromiumos_image.bin

(Verify that dump_kernel_config runs successfully)
$ dump_kernel_config part_2
console=tty2 init=/sbin/init add_efi_memmap boot=local noresume noswap
i915.modeset=1 cros_secure kern_guid=%U tpm_tis.force=1
tpm_tis.interrupts=0 nmi_watchdog=panic,lapic i8042.nomux=1
root=/dev/dm-0 quiet loglevel=1 rootwait ro dm_verity.error_behavior=3
dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="vroot none ro,0 1740800
verity %U+1 %U+1 1740800 1 sha1
c357e07395150770ce25ebc0e3c6d15941675c58"

(Run load_kernel_test)
$ load_kernel_test -b 2 chromiumos_image.bin
/usr/share/vboot/devkeys/recovery_key.vbpubk
Read 2088 bytes of key from /usr/share/vboot/devkeys/recovery_key.vbpubk
bootflags = 6
Reading from image: chromiumos_image.bin
Ending LBA: 3989538
Read(1, 1)
Read(2, 32)
Read(3989506, 32)
Read(3989538, 1)
Read(4096, 128)
Read(4224, 6472)
LoadKernel() returned 0
Partition number:   2
Bootloader address: 4345856
Bootloader size:    16384
Partition guid:     b2a453b0-a64a-5c4d-a957-1388cea384a5

R=marcheu@chromium.org,sjg@chromium.org
BUG=none
TEST=see verification process above

Review URL: http://codereview.chromium.org/6685079

Change-Id: I932753197550b853495f2c03e8880ad71df765a7
2011-03-22 13:15:19 +08:00
Stéphane Marchesin
bc7a84d9a1 Revert "Add --kloadaddr option to utilities"
This reverts commit 1a0975f5f4.
This fixes chromeos-install on x86-mario with a kernel-next profile.

BUG=None
TEST=Build an x86-mario image with kernel-next, check that /usr/sbin/chromeos-install works.

Review URL: http://codereview.chromium.org/6677033

Change-Id: I67fc5c0f70a05a4d662952105542edf454da8022
2011-03-15 10:13:31 -07:00
Che-Liang Chiou
1a0975f5f4 Add --kloadaddr option to utilities
Kernel body load address was hard-coded to CROS_32BIT_ENTRY_ADDR, which
could be an invalid/unavailable memory location on other platforms.

This CL adds an option for setting the load address, and it is default to
CROS_32BIT_ENTRY_ADDR to maintain backward-compatibility.

BUG=chromium-os:1304
TEST=emerge vboot_reference successfully

Review URL: http://codereview.chromium.org/6651022

Change-Id: I158cfce10ac59bd019bca41cb061039d0085d5cc
2011-03-11 15:02:17 +08:00
Che-Liang Chiou
0376203b41 Add --arch flag to pack mode of vbutil_kernel
When --arch flag is not x86, x86-only operations in pack mode are
turned off so that we can reuse vbutil_kernel to generate kernel partition
images for other targets, such as arm.

See CL:6538014 for its application.

BUG=chromium-os:3790
TEST=Run "emerge vboot_reference" successfully

Review URL: http://codereview.chromium.org/6538015

Change-Id: If45cf092d1ecc762fad6fda1aa57d23e26a7e47a
2011-02-22 11:16:51 +08:00
Will Drewry
9342f88e42 vbutil_kernel: support exporting a keyblock file during verify
Reuses the --keyblock argument to output a keyblock if used
during Verify().

TEST=built, ran on a kernel; check if it worked for cgpt find -M :)
BUG=chromium-os:7451

Change-Id: Ibf1365dbdaeaf87442e0d12d048bc070f35662ad

Review URL: http://codereview.chromium.org/4160001
2010-10-26 10:22:05 -05:00
vbendeb
00b9088fb2 Consider zero a valid kernel version.
SAFT testing requires changing kernel version to one level
below the current value (set to 1). This change allows
version number set to zero for test purposes.

Change-Id: Ia6f11578d9a6bc8c5544c56413c5589011d6334a

BUG=chromium-os:1976
TEST=manual

Ran `vbutil_kernel --repack --version 0 <other params>'
it used to fail, now it succeeds. This is also verified by
using in http://codereview.chromium.org/3781016 to support
TPM testing.

Review URL: http://codereview.chromium.org/3968006
2010-10-21 13:46:16 -07:00
Bill Richardson
2f6a71fb34 Handle short read error correctly in vbutil_kernel.c
If you try to read a file that's all zeros, it tries to read a zero-length
kernel blob, fails to do so (or suceeds with an empty result, depending on
your point of view), and prints

  ERROR: Unable to read kernel blob from <file>: Success

That's not very helpful.

This change makes it say

  ERROR: No kernel blob found

instead.

Change-Id: I841ec6e288f47cd9b1f8e9ca1e6da0741ad20e9f

BUG=none
TEST=none

Review URL: http://codereview.chromium.org/3764004
2010-10-14 09:25:39 -07:00
vbendeb
858fffb5ce Allow --repack option to change kernel version number.
RFro TPM rollback testing we need to be able to change kernel
version number. This Cl adds this ability to the
vbutil_kernel utility.

Change-Id: I156df9b0d3467043c20a43e1c75e6d0222704f3a

BUG=chromium-os:1976
TEST=manual

1. On a target running off /dev/sda3 (as reported by
'rootdev -s') execute `/usr/bin/dev_debug_vboot' and take
note of the kernel version number in the output section
starting with 'TEST: verify HD kernel A with firmware A key',
under 'Preamble' it should read
'Kernel version:      1'

2. copy the kernel into a file:
dd if=/dev/sda2 of=/tmp/kernel

3.on the desktop (this step requires ssh setup to use the
correct keys to reach the target):

scp tests/devkeys/kernel_data_key.vbprivk <target>:/tmp

3. Modify kernel version
vbutil_kernel --repack /tmp/repacked.k --version 2 --signprivate /tmp/kernel_data_key.vbprivk  --oldblob  /tmp/kernel

4. Install the updated kernel
dd if=/tmp/repacked.k of=/dev/sda2

5. restart the system

6. Observe that it came up using /dev/sda3 as the root
file system

7. run /usr/bin/dev_debug_vboot and observe that the kernel
version is no set to 2

Review URL: http://codereview.chromium.org/3520019
2010-10-06 09:51:44 -07:00
Bill Richardson
60bcbe3cd4 New tools to help debug vboot failures.
This adds some tools to help us figure out why a particular kernel isn't
booting. Often we suspect it's because it was signed with the wrong keys, or
has flags restricting its use to certain boot modes. This change adds some
tools to extract and display all the keys from the BIOS, and try them on the
various kernels. We also display the sha1sum of all the keys we find, to
make comparing them easier.

Change-Id: I38e447bf95cb6c3a0b87aa949611bb135f2f94b4

BUG=chromeos-partner:888
TEST=manual

To test, obtain a root shell, and run dev_debug_vboot. You should see lots
of useful information go by.

Review URL: http://codereview.chromium.org/3303018
2010-09-09 14:53:56 -07:00
Che-Liang Chiou
475bf447cc Add fake e820 memory map entries to zeropage
BUG=chromium-os:4521
TEST=manual

This patch set adds two e820 memory map entries to kernel's zeropage to
trick kernel into booting; otherwise kernel will choke on missing e820
memory map.

The added e820 memory map entries should let kernel boot and should not
make the memory map differ from that without the added entries.

Test Procedure:
1. Boot your test machine and save dmesg output, referred to as LOG1.
2. Apply the following one-line patch and then compile and install
   kernel.
3. Apply this patch set and re-build zeropage on kernel partition.
4. Boot the test machine and save dmesg output, referred to as LOG2.

LOG1 would contain the following messages (the exactly addresses of
memory map should differ slightly).
...
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] bootconsole [earlyser0] enabled
...
[    0.000000] modified physical RAM map:
[    0.000000]  modified: 0000000000000000 - 0000000000002000 (usable)
[    0.000000]  modified: 0000000000002000 - 0000000000006000 (reserved)
[    0.000000]  modified: 0000000000006000 - 000000000008f000 (usable)
[    0.000000]  modified: 000000000008f000 - 0000000000090000 (ACPI NVS)
[    0.000000]  modified: 0000000000090000 - 00000000000a0000 (usable)
[    0.000000]  modified: 0000000000100000 - 0000000000f00000 (usable)
[    0.000000]  modified: 0000000001000000 - 000000003f33f000 (usable)
[    0.000000]  modified: 000000003f33f000 - 000000003f4bf000 (reserved)
[    0.000000]  modified: 000000003f4bf000 - 000000003f5bf000 (ACPI NVS)
[    0.000000]  modified: 000000003f5bf000 - 000000003f5f7000 (ACPI data)
[    0.000000]  modified: 000000003f5f7000 - 000000003f600000 (usable)
[    0.000000]  modified: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  modified: 00000000ffc00000 - 0000000100000000 (reserved)

LOG2 would contain the following messages (the exactly addresses of
memory map should differ slightly).
...
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 0000000000001000 (usable)
[    0.000000]  BIOS-e820: 00000000fffff000 - 0000000100000000 (reserved)
[    0.000000] bootconsole [earlyser0] enabled
...
[    0.000000] modified physical RAM map:
[    0.000000]  modified: 0000000000000000 - 0000000000002000 (usable)
[    0.000000]  modified: 0000000000002000 - 0000000000006000 (reserved)
[    0.000000]  modified: 0000000000006000 - 000000000008f000 (usable)
[    0.000000]  modified: 000000000008f000 - 0000000000090000 (ACPI NVS)
[    0.000000]  modified: 0000000000090000 - 00000000000a0000 (usable)
[    0.000000]  modified: 0000000000100000 - 0000000000f00000 (usable)
[    0.000000]  modified: 0000000001000000 - 000000003f33f000 (usable)
[    0.000000]  modified: 000000003f33f000 - 000000003f4bf000 (reserved)
[    0.000000]  modified: 000000003f4bf000 - 000000003f5bf000 (ACPI NVS)
[    0.000000]  modified: 000000003f5bf000 - 000000003f5f7000 (ACPI data)
[    0.000000]  modified: 000000003f5f7000 - 000000003f600000 (usable)
[    0.000000]  modified: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  modified: 00000000ffc00000 - 0000000100000000 (reserved)

Test result:
1. Compare the first paragraph of excerpts from LOG1 and LOG2:
   This shows that the fake e820 memory map entries are successfully
   added.
2. Compare the second paragraphs of excerpts from LOG1 and LOG2:
   This shows that the added entries do not modify the memory map.

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 49706d0..c9075ee 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -425,7 +425,7 @@ static int __init append_e820_map(struct e820entry
*biosmap, int nr_map)
 {
        /* Only one memory region (or negative)? Ignore it */
        if (nr_map < 2)
-               return no_e820_map_return();
+               return -1;

        return __append_e820_map(biosmap, nr_map);
 }

Review URL: http://codereview.chromium.org/3176019
2010-08-23 11:20:44 +08:00
Randall Spangler
138acfe1ba Fix KeyBlockVerify() to take an explicit param for whether to use hash only.
Fix VerifyMemberInside().

BUG=chrome-os-partner:703
TEST=make && make runtests

Review URL: http://codereview.chromium.org/3126013
2010-08-17 15:45:21 -07:00
Bill Richardson
4f36ef3360 Changes to allow user-signed kernels to be generated.
Make vbutil_keyblock handle unsigned blocks. Also enable --unpack option and
add tests for it.

Modify vbutil_kernel to allow unsigned keyblocks, correct usage message,
and fix the --debug option which was somehow disabled.

Update load_kernel_test to accept /dev/null for the public key, to test
non-signed kernel keyblocks.

Review URL: http://codereview.chromium.org/3124004
2010-08-09 17:50:14 -07:00
Randall Spangler
87c13d806b Added size param to VerifyData()
Also renamed verify preamble functions, now that they do not need the
'2' at the end to differentiate them from the now-deleted original
implementation.

BUG=4501
TEST=Ran make runtests; all pass.

Review URL: http://codereview.chromium.org/3027009
2010-07-19 10:35:40 -07:00
vbendeb
b2b0fcc0f6 Introduce ability to change the kernel command line.
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
2010-07-15 15:09:47 -07:00
Bill Richardson
abf0550458 Switch to using .vbprivk for signing everything now.
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
2010-07-01 10:22:06 -07:00
Bill Richardson
a08b5c9d03 Adding --repack and --headeronly options to vbutil_kernel
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
2010-06-30 21:59:43 -07:00
Bill Richardson
249677d0ad Add some debug output to vbutil_kernel, display values in hex.
Review URL: http://codereview.chromium.org/2859019
2010-06-23 11:16:37 -07:00
Randall Spangler
729b87258b Clean up of key block functions
No substantial new code, just making the old code consistent.

Review URL: http://codereview.chromium.org/2729021
2010-06-11 11:16:20 -07:00
Randall Spangler
7d6898dbaa Added vbutil_kernel.
Review URL: http://codereview.chromium.org/2730011
2010-06-11 09:22:13 -07:00