crossystem now covers all data currently provided by chromeos_acpi.
Change-Id: I3364c4d65ddf63fe788d3d9c1e9d05e64be22856
BUG=chromium-os:12282
TEST=manual - test on Cr-48 and compare with ACPI values
Review URL: http://codereview.chromium.org/6557001
crossystem can now be used in place of reboot_mode.
BUG=12327
TEST=manual by comparing with the old reboot_mode utility
crossystem recovery_request=1
reboot_mode
crossystem dbg_reset=1
reboot_mode
crossystem fwb_tries=1
reboot_mode
crossystem recovery_request=0
reboot_mode
crossystem dbg_reset=0
reboot_mode
crossystem fwb_tries=0
reboot_mode
Review URL: http://codereview.chromium.org/6538066
Change-Id: Ifde661d4621129d52e757654d85e386e65f90df5
Note that both the current and boot settings are incorrect as reported
by the BIOS. This fixes both.
Change-Id: Iebd2b4ac91232444e538f6e2763a22cb227f2e4f
BUG=chrome-os-partner:2078
TEST=manual
Run crossystem on Mario and Alex with WP enabled, disabled and check
Verify true hardware WP status by doing:
flashrom --wp-enable
flashrom --wp-status
flashrom --wp-disable
flashrom --wp-status
On a system with hardware WP enabled, the disable step should fail and write
protect will still report enabled.
Review URL: http://codereview.chromium.org/6531035
Works for getting switch positions, hwid, fwid.
BUG=chrome-os-partner:1940
TEST=ran manually on Mario and Alex
Review URL: http://codereview.chromium.org/6413002
Change-Id: I874df3b5adf872fec2d36e574cb4b8b4a72d331c
BUG=chromium-os:8621
TEST=See below
1. Build and run tests of vboot (including linktest)
$ make && make runtests
2. Check if *_stub.o are not in vboot_fw.a
$ nm /build/<board>/usr/lib/vboot_fw.a | grep _stub.o
3. Build and boot x86-generic image
$ ./build_packages --board=x86-generic && ./build_image --board=x86-generic
(Then successfully boot the image you just built)
See CL=4372001 for u-boot side changes
Review URL: http://codereview.chromium.org/4266002
Change-Id: Icc2bcc551c998f370e4b737fbe442ebf029cd81c
Maximum output size is the signature size.
BUG=7676
TEST=manual
1) Verified that earlier outbufsize value was more than what the external signer would return.
2) Re-ran run_vbutil_tests.sh
Change-Id: I180cfea7625ee09a51709d8f7735884c32b8b409
Review URL: http://codereview.chromium.org/4251006
This allows signing using a .pem file using an external program.
It is assumed that the external program reads input from stdin, and outputs signed data on stdout. It takes one argument - the file name for the .pem private key reference. See external_rsa_signer.sh for an example external program.
Example usage:
vbutil_keyblock --pack 4096.keyblock \
--datapubkey 4096.vbpubk \
--signprivate_pem 4096.pem \
--pem_algorithm 8 \
--externalsigner "external_rsa_signer.sh"
I have tried to make the change such that it doesn't impact existing tools/interfaces (since these are used at various places). That said, I am aware of the places where we could just extend an old interface an avoid code duplication but thought I'd put that re-factoring in as a TODO for now. Let me know if you disagree and I can merge them (and changing the existing interface).
BUG=7576
TEST=Extended run_vbutil_tests.sh to test vbutil_keyblock packing using an external signer.
To test, make && make runtests (or just run tests/gen_test_keys.sh; tests/run_vbutils_tests.sh)
Review URL: http://codereview.chromium.org/4194003
Change-Id: I7cc52c8293c04ef9ba074794d046c9a4f19f6bdd
This adds some tools to help us figure out why a particular kernel isn't
booting. Often we suspect it's because it was signed with the wrong keys, or
has flags restricting its use to certain boot modes. This change adds some
tools to extract and display all the keys from the BIOS, and try them on the
various kernels. We also display the sha1sum of all the keys we find, to
make comparing them easier.
Change-Id: I38e447bf95cb6c3a0b87aa949611bb135f2f94b4
BUG=chromeos-partner:888
TEST=manual
To test, obtain a root shell, and run dev_debug_vboot. You should see lots
of useful information go by.
Review URL: http://codereview.chromium.org/3303018
Also, make algorithm unsigned int in most places.
BUG=chrome-os-partner:701
TEST=existing RSA verification tests still pass
Review URL: http://codereview.chromium.org/3136017
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
Since the kernel vblocks are always padded out to a fixed size, the unused (padded) memory was ending up containing random bytes, leading to vbutil_kernel generating vblocks that are not bit-identical when run with the same inputs.
BUG=none
TEST=see below
1) Use vbutil_kernel with the same set of inputs to generate two alternative vblocks.
2) Compare the 2 files - they must be bitwise identical space. The padding bytes must all be set to 0.
3) Generate a new signed image using the resign_image.sh script under scripts/image_signing. This signed image should be boot and install successfully on a maching running our custom firmware using the same set of root, firmware, and kernel keys.
Review URL: http://codereview.chromium.org/3076033
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
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
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
