Change kernel vboot header layout and add support for separate header verification.

Change kernel vboot header layout and add support for separate header verification.

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.

[gauravsh, 2010-05-26 14:55:24]

As per our discussion yesterday, here are the changes that hopefully make it
possible to use kernel verification functions in LoadKernel(). 

In addition to the kernel vboot header layout changes (config is gone, replaced
by a preamble), I also added a new VerifyKernelHeader() function which just
verifies the key header and the preamble. It also extracts pointers to the
signing key, the kernel data length, etc which can subsequently be used in a
call to VerifyKernelData().

Let me know if you want header verification to also extract out the other
preamble parameters like the bootloader offset, etc.

[Randall Spangler, 2010-05-26 16:35:23]

LGTM

http://codereview.chromium.org/2234003/diff/2001/3007
File src/platform/vboot_reference/vkernel/kernel_image_fw.c (right):

http://codereview.chromium.org/2234003/diff/2001/3007#newcode222
src/platform/vboot_reference/vkernel/kernel_image_fw.c:222: /* Note: All the
offset calculations are based on struct FirmwareImage which
KernelImage

[Randall Spangler, 2010-05-26 16:35:57]

On 2010/05/26 16:35:23, Randall Spangler wrote:
> LGTM

(Though needs updating to the new locations of these files after Bill's CL last
night)

> 
> http://codereview.chromium.org/2234003/diff/2001/3007
> File src/platform/vboot_reference/vkernel/kernel_image_fw.c (right):
> 
> http://codereview.chromium.org/2234003/diff/2001/3007#newcode222
> src/platform/vboot_reference/vkernel/kernel_image_fw.c:222: /* Note: All the
> offset calculations are based on struct FirmwareImage which
> KernelImage

[Bill Richardson, 2010-05-26 16:41:01]

This is a good incremental step, but it won't do what we want yet. First, I've
refactored the directories, so all the _fw.c files are in a new location.
Second, we want to verify the components separately. This implementation of
VerifyKernel() assumes that the entire disk-partition content is copied into RAM
as a single entity. That's not the case. The header from the disk partition is
in RAM in one place, and the kernel_data (without any headers) is in RAM in
another place.

Also: Do we want to move the kernel_data signature inside the preamble? That
would prevent us from needing to re-validate the preamble in order to validate
the kernel_data.

[gauravsh, 2010-05-26 17:03:24]

On Wed, May 26, 2010 at 9:41 AM,  <wfrichar@chromium.org> wrote:
> This is a good incremental step, but it won't do what we want yet. First,
> I've
> refactored the directories, so all the _fw.c files are in a new location.
> Second, we want to verify the components separately. This implementation of
> VerifyKernel() assumes that the entire disk-partition content is copied into
> RAM
> as a single entity. That's not the case. The header from the disk partition
> is
> in RAM in one place, and the kernel_data (without any headers) is in RAM in
> another place.
>

With this change, VerifyKernel() will no longer need to be called.
Instead, we call VerifyKernelHeader() first to just verify the vboot
header. A separate call to VerifyKernelData() [the required parameters
will be filled in by the first call)] verifies the actual kernel image
data. Isn't that what is required?

> Also: Do we want to move the kernel_data signature inside the preamble? That
> would prevent us from needing to re-validate the preamble in order to
> validate
> the kernel_data.
>
All the preamble data needs to logically considered a part of kernel
data when the kernel_signature is verified (otherwise we loose the
preamble-kernel association which makes splicing attacks possible).

> http://codereview.chromium.org/2234003/show
>



-- 
-g

[gauravsh, 2010-05-26 19:48:31]

On Wed, May 26, 2010 at 10:03 AM, Gaurav Shah <gauravsh@chromium.org> wrote:
> On Wed, May 26, 2010 at 9:41 AM,  <wfrichar@chromium.org> wrote:
>> This is a good incremental step, but it won't do what we want yet. First,
>> I've
>> refactored the directories, so all the _fw.c files are in a new location.
>> Second, we want to verify the components separately. This implementation of
>> VerifyKernel() assumes that the entire disk-partition content is copied into
>> RAM
>> as a single entity. That's not the case. The header from the disk partition
>> is
>> in RAM in one place, and the kernel_data (without any headers) is in RAM in
>> another place.
>>
>
> With this change, VerifyKernel() will no longer need to be called.
> Instead, we call VerifyKernelHeader() first to just verify the vboot
> header. A separate call to VerifyKernelData() [the required parameters
> will be filled in by the first call)] verifies the actual kernel image
> data. Isn't that what is required?
>
>> Also: Do we want to move the kernel_data signature inside the preamble? That
>> would prevent us from needing to re-validate the preamble in order to
>> validate
>> the kernel_data.
>>
> All the preamble data needs to logically considered a part of kernel
> data when the kernel_signature is verified (otherwise we loose the
> preamble-kernel association which makes splicing attacks possible).

With the latest CL that is out for review, kernel_signature is now a
part of the preamble while still defending against splicing attacks.

>
>> http://codereview.chromium.org/2234003/show
>>
>
>
>
> --
> -g
>



-- 
-g