The make_dev_ssd.sh is made for devinstall shim to
change SSD kernels to be signed by dev keys.
- Kernel A, B will be resigned with dev keys (ignore if A/B seems not bootable)
- Adding param --remove_rootfs_verification can even disable rootfs hash check
This CL also includes some shared refine/fix to make_dev_firmware.sh
BUG=chrome-os-partner:1276
TEST=sudo ./make_dev_ssd.sh; (seeing Kernel A is resigned and B is ignored)
then reboot without developer mode (OK),
rootdev shows /dev/dm-0, rootdev -s shows /dev/sda3
sudo ./make_dev_ssd.sh --remove_rootfs_verification;
then reboot without developer mode (OK), rootdev shows /dev/sda3
Change-Id: Ic20f734b2af42e50a43c19a565a166a39d57a7fd
Review URL: http://codereview.chromium.org/3772013
Change-Id: I2e798ac8898852aa44a8979e67dfa4de385a6e34
BUG=none
TEST=ran the autotest on a CRB with special firmware
Review URL: http://codereview.chromium.org/3389029
While trying to debug/test some vbutil_kernel changes
(coming in a different CL) it was noticed that this utility
is not covered by tests, and the script which runs it to set
up further testing (tests/gen_fuzz_test_cases.sh) fails
because of the key format mismatch.
Some investigation has shown that this was left behind when
vboot_reference key storage format was changed.
To make gen_fuzz_test_cases.sh work again a new set of test
keys is required, the keys are generated by
tests/gen_test_keys.sh. This utility had to be changed to
generate the proper set of wrapped public and private keys.
Actually code in tests/gen_test_keys.shgenerate_keys() is
copied in pasted in many scripts in this tree, this has to
be refactored, but under a different CL.
Once the changes were made, two scripts were run:
./tests/gen_test_keys.sh
./gen_test_cases.sh
resulting in the new and updated keys generated.
firmware/stub/tpm_lite_stub.c was edited to fix compilation
warning issued when compiling with debugging enabled.
Change-Id: I26a45cbad00d21a29195f2a89b4df7d3559133fe
BUG=chromium-os:7178
TEST=described below
The following commands succeed:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
make
make runtests
./tests/gen_fuzz_test_cases.sh
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note that ./tests/gen_fuzz_test_cases.sh was failing
before this change.
The upcoming CL modifying vbutil_kernel will make sure
gen_fuzz_test_cases.sh is executed when tests are run and
will enhance it to cover vbutil_kernel testing.
Review URL: http://codereview.chromium.org/3423022
Change-Id: I4c9b7a937103f3978cbed6629ee4057018b80eae
More cleanup. Also allow some tests to run even when TPM is already started.
Change-Id: I23558b96a1de55bbeca42dbf2e44f6802a0ec85b
Reorganize and standardize behavior of tests.
Change-Id: Id32fd09211a72deaa66a3dd0f973d35506ff96f2
BUG=433
TEST=ran all the tests I could run without TPM-free BIOS
Review URL: http://codereview.chromium.org/3389004
Update list of scripts and test binaries - slightly more involved since the test runner scripts and the test binaries themselves reside in different directories.
BUG=none
TEST=manual (Ran make, went into the tests/ directory and ran the tests)
Change-Id: I97bd36d806726f6005e35490173cfcd0300add95
Review URL: http://codereview.chromium.org/3326014
Add some extra cases to SanityCheckTest() to test both header and entries
being garbled at either end of the disk.
Add DuplicateUniqueGuidTest() to check that GPTs having duplicate
UniqueGuids in the entries are rejected. We can only check this per-disk, of
course.
Made some changes to the library to enforce the UniqueGuid requirement that
I just started testing for.
BUG=chromium-os:4854
Review URL: http://codereview.chromium.org/3135044
Change-Id: I86458faf9cc99aa3f29aac0d5b144dbd05067181
I'm getting ready to add a bunch more cgpt tests. This is just to clear the
way.
Change-Id: I5cb781e85938b94da9c59528872ddfd386712726
Review URL: http://codereview.chromium.org/3162023
Changed TlclRead / TlclWrite to take void* / const void* to reduce typecasts.
Much restructuring of rollback_index.c.
Fixed a version-packing bug in rollback_index.c (& --> |)
BUG:chrome-os-partner:304
TEST:manual testing of all code flows on CRB
Review URL: http://codereview.chromium.org/3084030
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
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
This code compiles and installs using a modified ebuild (which needs to be committed after this change).
Review URL: http://codereview.chromium.org/2857030
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
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
This is a mostly NOOP change which modifies the source code
to compile cleanly in the MSVC command line build
environment.
A new makefile is introduced (msc/nmakefile) along with a
README.txt in the same directory explaining how to build
the code in the DOS window. As of this submission the build
is running in a 32 bit environment, the intention is to use
the same makefile for 64 bit builds in the future.
Enabling high compilation warnings level allowed to
identify a couple of bugs in the code which are being fixed.
Not all sources are being compiled in the MSVC environment,
only those in firmware/ and most of those in test/
subdirectories. The benchmark calculations require porting
of the timer facilities and are being postponed.
TEST
Built in DOS and linux environments. Ran unit tests in
linux environment.
Review URL: http://codereview.chromium.org/2809037
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
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
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
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