VBoot Reference: 18 Exabytes ought to be enough for everybody

Propagate use of uint64_t to more functions that may need to deal with arbitrary length data.

This CL fixes some functions to use uint64_t that I missed the first time around. It ended up requiring some minor changes to how some of the helper functions work (StatefulMemcpy*()).

Also adds new tests to make sure that reference code can verify/process big firmware and kernel images.

BUG=670
TEST=Adds some new, old ones still pass.

[Chris Masone, 2010-03-30 02:17:03]

in general, in the test programs, can you store the file basenames in constants,
and then just append the extensions?  Seems less error prone.

Also, do your tests run your code through the error pathways at all?  Like, can
you force an overrun to make sure you catch it?

http://codereview.chromium.org/1519008/diff/5001/6008
File src/platform/vboot_reference/tests/big_firmware_tests.c (right):

http://codereview.chromium.org/1519008/diff/5001/6008#newcode27
src/platform/vboot_reference/tests/big_firmware_tests.c:27: uint8_t*
firmware_sign_key_buf= BufferFromFile("testkeys/key_rsa1024.keyb",
Any reason these filenames aren't symbolic constants?

[gauravsh, 2010-03-30 03:19:01]

On Mon, Mar 29, 2010 at 7:17 PM,  <cmasone@chromium.org> wrote:
> in general, in the test programs, can you store the file basenames in
> constants,
> and then just append the extensions?  Seems less error prone.

Agreed. Done. Also made the same change to other tests, no point in
doing it in a separate CL.

>
> Also, do your tests run your code through the error pathways at all?  Like,
> can
> you force an overrun to make sure you catch it?

Most of the testing that I have done to make sure errors are handled
gracefully is through fuzz testing by "bunny" (a smart fuzzer). It's
smart enough to notice how changing parts of the input changes program
control flow and focuses its attention on that. I could write manual
tests for those too but there are just too many cases to consider.

Before uint64_t changes in this CL, the Big[Firmware|Kernel]Tests were
failing - so the tests helped me debug and figure out where exactly
things were not being handled correctly. So, in a sense, they do
exercise code pathways where overflows might cause a problem.

In any case, I guess what I will do is to add some tests for corner
cases (like header length field all maxed out, etc.). That's a
separate CL though. Let me know if this is not what you were exactly
asking.

>
>
> http://codereview.chromium.org/1519008/diff/5001/6008
> File src/platform/vboot_reference/tests/big_firmware_tests.c (right):
>
> http://codereview.chromium.org/1519008/diff/5001/6008#newcode27
> src/platform/vboot_reference/tests/big_firmware_tests.c:27: uint8_t*
> firmware_sign_key_buf= BufferFromFile("testkeys/key_rsa1024.keyb",
> Any reason these filenames aren't symbolic constants?
>
> http://codereview.chromium.org/1519008
>



-- 
-g

[Chris Masone, 2010-03-30 03:37:24]

Cool.  LGTM

On 2010/03/30 03:19:01, gauravsh wrote:
> On Mon, Mar 29, 2010 at 7:17 PM,  <mailto:cmasone@chromium.org> wrote:
> > in general, in the test programs, can you store the file basenames in
> > constants,
> > and then just append the extensions? &nbsp;Seems less error prone.
> 
> Agreed. Done. Also made the same change to other tests, no point in
> doing it in a separate CL.
> 
> >
> > Also, do your tests run your code through the error pathways at all?
&nbsp;Like,
> > can
> > you force an overrun to make sure you catch it?
> 
> Most of the testing that I have done to make sure errors are handled
> gracefully is through fuzz testing by "bunny" (a smart fuzzer). It's
> smart enough to notice how changing parts of the input changes program
> control flow and focuses its attention on that. I could write manual
> tests for those too but there are just too many cases to consider.
> 
> Before uint64_t changes in this CL, the Big[Firmware|Kernel]Tests were
> failing - so the tests helped me debug and figure out where exactly
> things were not being handled correctly. So, in a sense, they do
> exercise code pathways where overflows might cause a problem.
> 
> In any case, I guess what I will do is to add some tests for corner
> cases (like header length field all maxed out, etc.). That's a
> separate CL though. Let me know if this is not what you were exactly
> asking.
> 
> >
> >
> > http://codereview.chromium.org/1519008/diff/5001/6008
> > File src/platform/vboot_reference/tests/big_firmware_tests.c (right):
> >
> > http://codereview.chromium.org/1519008/diff/5001/6008#newcode27
> > src/platform/vboot_reference/tests/big_firmware_tests.c:27: uint8_t*
> > firmware_sign_key_buf= BufferFromFile("testkeys/key_rsa1024.keyb",
> > Any reason these filenames aren't symbolic constants?
> >
> > http://codereview.chromium.org/1519008
> >
> 
> 
> 
> -- 
> -g
>