Vboot Reference: Add the "real" reference firmware verification function (VerifyFirmware).

Vboot Reference: Add the "real" reference firmware verification function (VerifyFirmware). 

The old VerifyFirmware function (now called VerifyFirmwareImage) works on the FirmwareImage structure. This CL adds a verification function which can be used directly on packed binary verified boot firmware blobs. This function can be used as the reference implementation for verified boot in firmware. In addition, all functions that work on FirmwareImage structure have been renames to distinguish them from those which work on binary firmware blobs. 

In addition, this adds some new crypto utility functions and refactors old ones. 
BUG=670
TEST=Added tests for the new function and they pass.

[sosa, 2010-02-22 23:31:16]

Overall looks good.  Can you be check your utility functions and make sure that
you are consistent in your use of return int's as 0 == success and != 0 = fail
vs. boolean status codes (isSuccess).  I think it would make more sense to
change to the former method for all functions that return an int o/w others
using your utilities will always have to remember which ones have 0 == success
and which are 1 == success

http://codereview.chromium.org/650105/diff/1/13
File src/platform/vboot_reference/utils/firmware_image.c (right):

http://codereview.chromium.org/650105/diff/1/13#newcode167
src/platform/vboot_reference/utils/firmware_image.c:167: FirmwareImage* image) {
You over-indented this whole func

http://codereview.chromium.org/650105/diff/1/13#newcode310
src/platform/vboot_reference/utils/firmware_image.c:310: firmware_data_start +
signature_len,  /* Data to verify. */
80 chars

http://codereview.chromium.org/650105/diff/1/15
File src/platform/vboot_reference/utils/verify_data.c (right):

http://codereview.chromium.org/650105/diff/1/15#newcode83
src/platform/vboot_reference/utils/verify_data.c:83: fprintf(stderr, "Signature
Verification \e[1;32mSUCCEEDED\e[m\n");
What's this???

[gauravsh, 2010-02-23 00:45:05]

So the only functions that respond with 0 for success are the ones that are
required to return different error codes (most notable the VerifyFirmware
function) to the caller. I changed the definition for SafeMemcmp to make it act
like a Memcmp (0 on comparison success, something else other wise) but am vary
of changing this logic for RSAVerify since I suspect someone will definitely use
them wrong in the future. What do you think?

I also ended up discovering a bug with SafeMemcmp() (yeah, I know) which
paradoxically, got added as part of a previous code review and fix cycle
. :)

http://codereview.chromium.org/650105/diff/1/13
File src/platform/vboot_reference/utils/firmware_image.c (right):

http://codereview.chromium.org/650105/diff/1/13#newcode167
src/platform/vboot_reference/utils/firmware_image.c:167: FirmwareImage* image) {
On 2010/02/22 23:31:16, sosa wrote:
> You over-indented this whole func

Fixed.

http://codereview.chromium.org/650105/diff/1/13#newcode310
src/platform/vboot_reference/utils/firmware_image.c:310: firmware_data_start +
signature_len,  /* Data to verify. */
On 2010/02/22 23:31:16, sosa wrote:
> 80 chars

Done.

http://codereview.chromium.org/650105/diff/1/15
File src/platform/vboot_reference/utils/verify_data.c (right):

http://codereview.chromium.org/650105/diff/1/15#newcode83
src/platform/vboot_reference/utils/verify_data.c:83: fprintf(stderr, "Signature
Verification \e[1;32mSUCCEEDED\e[m\n");
On 2010/02/22 23:31:16, sosa wrote:
> What's this???
ANSI color coding escape sequence. I put them as macro definitions to make that
clearer.

[sosa, 2010-02-24 00:04:08]

I LGTM'd in my mind but not by body.

Having said that, LGTM