MSVC does not like bitfields with extra bits in them, so it made the GptEntry struct too big.
Fixed a missing return value in LoadFirmware().
Added some debug output.
Fixed calls to SetupTPM().
Tested with 'make && make runtests'. No errors.
Review URL: http://codereview.chromium.org/2865014
Note that I am still using TPM_MUST_REBOOT because if power is lost between ForceClear and resetting the deactivated flag, the TPM will *really* be disabled at the next reboot, and it's nice to fix this problem automatically.
Review URL: http://codereview.chromium.org/2859016
It turned out that shared verified boot library fails to
work properly when compiled by msc in BIOS environment.
The culprit was identified as failing 64 bit logical
operations by preprocessor. It is probably possible to
come up with a certain compile flag set to fix the
operations, but it is not easy to modify and control the BIOS
compilation environment.
The alternative solution is to limit the size of the field
in question to 16 bits (especially since this is the only
part of the attributes field which is supposed to be
altered by firmware.
A union is being introduced in firmware/lib/cgptlib/include/gpt.h:GptEntry to allow
accessing the field both as a 64 bit entity and a top
16 bit field. All places where this field is used are
being modified appropriately.
tests/Makefile is being fixed to allow controlling test run
from the top level directory.
Tested by building everything and running tests.
All tests pass.
Review URL: http://codereview.chromium.org/2799019
This is a noop for host/chroot environment. When compiling
in the firmware space the standard include files will not be
included, the definitions will be supplied by the BIOS,
through the new file (firmware/include/sysincludes.h).
Testing
=======
RUNTESTS=1 make
in the top level directory succeeds, confirming that the
tree compiles cleanly and the unit tests pass.
Review URL: http://codereview.chromium.org/2862019
properly, i.e. rebuild relevant targets if any of the
dependencies (implicit or explicit) change.
To make dependency generation easier the three source files
in the tests directory shared among many programs
(rollback_index_mock.c test_common.c timer_utils.c and
crc32_test.c) are separated into a library, with each of
them getting its own the automated dependency script
generated by the compiler.
To simplify rule definitions, all applications built in the
test directory get linked with -lcrypto and -lrt, which is
not a problem as the linker will not use the library unless
needed.
Tested by touching different .h and .c files in ./tests,
running make and then and observing the make results.
Also verified that emerging works for x86 in chroot environment.
Review URL: http://codereview.chromium.org/2847012
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
There were two changes. First, we need to pack the GPT header to make it
match the spec (duh). Second, there's a subtle bug in how the BIOS recovers
from corrupted headers. The EFI spec says that the primary GPT header must
be at sector 1 (counting from zero) and the secondary GPT header must be at
the last sector on the drive. The BIOS correctly looks in those locations to
find the headers. However, if the secondary GPT header is invalid (as it
usually is due to our build process), the BIOS is supposed to update it from
the primary header. In this case, rather than write to the last sector on
the drive where it just looked, the BIOS trusts the alternate_lba field of
the primary header. That field is supposed to point to the secondary header
location, but the BIOS just blindly uses it no matter where it points. The
cgpt tool wasn't initializing that field, so it pointed to sector 0, which
is the PMBR. The BIOS overwrote that, resulting in an unbootable drive.
Review URL: http://codereview.chromium.org/2844006
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
Changed VerifyFirmwarePreamble to check for a valid kernel_subkey_sign_algorithm from the preamble.
Originally, an incorrect kernel_subkey_sign_algorithm wouldn't be detected and could cause the RSA
verification to read past the end of a buffer.
Review URL: http://codereview.chromium.org/2837002
Patch from Axel Hansen <axelrh@google.com>.
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
Rollback_index funcs now all return 0 if succcess, nonzero if error.
(Note: not fully implemented; Luigi, please clean this up in a
subsequent CL)
LoadKernel() checks return codes from TPM funcs.
LoadKernel() only looks at versions from TPM in normal boot mode.
Review URL: http://codereview.chromium.org/2735004
Supports passing back the kernel sign key blob, and updating the
firmware data hash during decompression. Doesn't require data for
both firmware volumes before deciding which one to boot.
Intended to replace VerifyFirmwareDriver_f().
Review URL: http://codereview.chromium.org/2691006
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