summaryrefslogtreecommitdiff
path: root/utility
Commit message (Collapse)AuthorAgeFilesLines
* crossystem: provide a way to clear wipeout requeststabilize-6915.BVadim Bendebury2015-03-261-1/+1
| | | | | | | | | | | | | | | For test purposes it should be possible to clear the wipeout request raised by firmware. BRANCH=none BUG=chrome-os-partner:36059 TEST=verified that crossystem wipeout_request=0 changes the bit from 1 to 0, and wipeout_request=1 does not change it from 0 to 1. Change-Id: Ic45ec03ed3e40e6fee4244804b8c231ee88af95b Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/262466 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot_reference: crossystem: add the "tpm_attack" commandLuigi Semenzato2015-03-211-2/+6
| | | | | | | | | | | | | | | | | | | This commands reads/sets a bit in the kernel-reserved area of the vboot context nvram. The bit can also be set by the driver during execution of a TPM command, to check if the command is interrupted by a panic or power loss. Under some circumstances, this correlates with the TPM assuming it is under attack. BUG=chromium:431360 TEST=try "crossystem tpm_attack" and variations BRANCH=none Change-Id: I87215d5a0becfb5c01e0b69867a339bfe6fd0b68 Reviewed-on: https://chromium-review.googlesource.com/261339 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Luigi Semenzato <semenzato@chromium.org> Tested-by: Luigi Semenzato <semenzato@chromium.org>
* vboot: allow firmware to signal a wipeout requestVadim Bendebury2015-03-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | It has become necessary to be able to "factory reset" certain devices on firmware request. The best mechanism for this is NVRAM, as the request needs to be detected very early in the boot process, before other means of communications with the upper layers are available. A previously unused NVRAM bit (bit 0x08 at offset zero) is taken for this purpose. A new flag is introduced to allow the firmware to signal the need to assert this bit. A new variable name/parameter ('wipeout_request') added to crossystem to provide user space access to the setting of the dedicated NVRAM bit. BRANCH=storm BUG=chrome-os-partner:37219 TEST=with all the patches applied, on storm, holding the recovery button at startup for 10 seconds, causes 'crossystem wipeout_request' to report '1'. Change-Id: If1f6f061ce5b3f357b92aaa74cb129671dc30446 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/259857 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cleanup: Fix some typos in commentsBill Richardson2015-03-101-1/+1
| | | | | | | | | | | | | | No code changes, just fix a few spelling errors and change C++ style comments to C-style. BUG=none BRANCH=none TEST=make runtests Change-Id: I153f821a3f42a92867c7dc4761a2bcde7f2518c4 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/256123 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* futility: Add create command to make keypairs from RSA filesBill Richardson2015-03-101-4/+3
| | | | | | | | | | | | | | | | | | | | This command reads a single .pem file and emits the public and private keys generated from it. It can produce both the old-style vboot 1.0 keys (.vbpubk and .vbprivk), or the new vboot 2.1 format keys (.vbpubk2 and .vbprik2). The default is the new format, but you can give futility the --vb1 arg to force the old format. A test is included. BUG=chromium:231547 BRANCH=ToT TEST=make runtests Change-Id: I4713dc5bf34151052870f88ba52ddccf9d4dab50 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/246766 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* crossystem: Add fw_prev_tried and fw_prev_result to output valuesJulius Werner2015-01-311-0/+2
| | | | | | | | | | | | | | | | | | CL:221230 added the new NVRAM fields fw_prev_tried and fw_prev_result. It also provided support in the crossystem library to decode these values, but it forgot to add them to the table of allowed crossystem options so they actually cannot be queried by the command line tool. Fix that since this information is useful to debug failures after updating. BRANCH=R41 BUG=chrome-os-partner:36183 TEST=make runtests VBOOT2=1. cros deployed onto Jerry and confirmed fw_prev_tried and fw_prev_result are correct. Change-Id: I8bad7266379d959f5370b7ebeefbbba939c5de06 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/245143 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot: Plumb the two disk sizes and external GPT param throughDan Ehrenberg2014-12-151-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch reinstates the external GPT support which was previously committed and reverted. Improvements since last time include: - Cleaned-up internal interface based on code review - Function correctly on legacy bootloaders (e.g., depthcharge before NAND-related patches are added) - Better comments - Treat new field values = 0 -> not use new feature - Tests are added to ensure external GPT flag is passed down properly The original commit had change-id I5a77e417aea8ee9442d18c200d1b073aa5375ecf Its commit message is reproduced below, and then an additional test. ---- To support an external GPT, disks have two new attributes: - A binary flag indicating whether the GPT is in the same address space as the payloads or a separate one. - The number of sectors of the streaming portion of storage, as opposed to the portion containing the GPT. These have been added elsewhere to GptData (in cgptlib) and BlockDev (in depthcharge). This patch adds the plumbing between those, including in the DiskInfo interface between the firmware and vboot. BUG=chromium:425677 BRANCH=none TEST=Interactively wrote the GPT with cgpt and observed the following boot with depthcharge to read the GPT from SPI and then read from the proper locations in NAND flash. TEST=make runalltests passes. TEST=boots from USB with depthcharge from HEAD. Change-Id: Ia7956517a7b9da0301f01fac5a10204f6d78cf4f Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/234640 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Allow /etc/defaults/vboot_reference to customise some utilitiesBill Richardson2014-12-061-16/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The dev_debug_vboot program can sometimes interfere with automated firmware testing because it takes too long to read the BIOS flash. Limiting the sections of flash that are read may help, but in some cases skipping this program entirely may be better. This CL does three things: 1. dev_debug_vboot will read only some sections of the BIOS flash, falling back to reading the whole thing only if it fails at that. 2. dev_debug_vboot will source /etc/default/vboot_reference if it exists. Putting DEV_DEBUG_FORCE=1 in that file will prevent dev_debug_vboot from reading the flash at all unless it's invoked with --force option. 3. The Makefile will create the /etc/default/vboot_reference file in the install directory, setting DEV_DEBUG_FORCE to the value in effect at build time. This will let a future CL change the default behavior for each target. BUG=chromium:438854 BRANCH=none TEST=manual Built and tested on Samus. /etc/default/vboot_reference was present, containing "DEV_DEBUG_FORCE=". The dev_debug_vboot script ran normally. Manually changing /etc/default/vboot_reference to contain "DEV_DEBUG_FORCE=1" and rebooting caused dev_debug_vboot to stop before reading the BIOS flash. I also manually forced various flashrom invocations to fail to test each part of the new flow. Change-Id: Ib319dd16b9026162d01f435f15570ec8ba99c512 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/233228 Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* Revert "vboot: Plumb the two disk sizes and 'gpt on device' param through"stabilize-6480.Bfactory-ryu-6486.Bfactory-ryu-6486.1.BJulius Werner2014-11-151-1/+0
| | | | | | | | | | | | | | | | | | | | This reverts commit 5040a945dfd0dd305d3ca8e923b8bf0bd5c6528e. This patch breaks booting any image (both fixed and removable) on Veyron_Pinky (and presumably every other non-NAND board?). By the power vested in me through the office of ChromeOS tree sheriff (well, five hours early but whatever) it is hereby reverted! BUG=chromium:425677 BRANCH=none TEST=Can successfully boot on Veyron_Pinky again. Change-Id: I9323a3d5e34491337fc7eb09dd00d845ac42997d Reviewed-on: https://chromium-review.googlesource.com/229963 Reviewed-by: Julius Werner <jwerner@chromium.org> Commit-Queue: Julius Werner <jwerner@chromium.org> Tested-by: Julius Werner <jwerner@chromium.org>
* vboot: Plumb the two disk sizes and 'gpt on device' param throughDan Ehrenberg2014-11-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | To support an external GPT, disks have two new attributes: - A binary flag indicating whether the GPT is in the same address space as the payloads or a separate one. - The number of sectors of the streaming portion of storage, as opposed to the portion containing the GPT. These have been added elsewhere to GptData (in cgptlib) and BlockDev (in depthcharge). This patch adds the plumbing between those, including in the DiskInfo interface between the firmware and vboot. BUG=chromium:425677 BRANCH=none TEST=Interactively wrote the GPT with cgpt and observed the following boot with depthcharge to read the GPT from SPI and then read from the proper locations in NAND flash. make runalltests passes. Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org> Change-Id: I5a77e417aea8ee9442d18c200d1b073aa5375ecf Reviewed-on: https://chromium-review.googlesource.com/228943 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Add hwid digest field to GBB headerBill Richardson2014-10-211-1/+1
| | | | | | | | | | | | | | | | | | | This adds a field in the GBB header to store the sha256 digest of the HWID string, and updates gbb_utility so that it stores the digest when it modifies the HWID. Because this is a new field, the GBB_MINOR_VER is incremented. BUG=chromium:415227 BRANCH=ToT TEST=make runtests, VBOOT2=1 make runtests Since the GBB is in the RO firmware, there should be no side effects for existing devices (but even without that, they should handle a minor version change without complaint). Change-Id: Icdb2a0b564677b0b65e58df897d2ec5af3964998 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/221360
* Convert vbutil_what_keys to use /bin/shBill Richardson2014-10-031-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This just involves deleting the "set -o pipefail" line. With bash, that meant that any program failure in a pipe would be fatal. Without it, only the last program matters. This usually means that the last command simply gets no input, in which case the program just appears to do nothing instead of complaining about whatever the problem was. Since vbutil_what_keys is generally only used to help debug a failure to boot, that's not a major problem. BUG=chromium:419773 BRANCH=ToT TEST=manual Tried on a Pit, it works: localhost ~ # /tmp/vbutil_what_keys /dev/mmcblk0 -e IMAGE: /dev/mmcblk0 part 2 kernel: d6170aa480136f1f29cf339a5ab1b960585fa444 (!DEV DEV !REC) developer keys part 4 kernel: d6170aa480136f1f29cf339a5ab1b960585fa444 (!DEV DEV !REC) developer keys localhost ~ # flashrom -r /tmp/bios.bin flashrom v0.9.4 : 904e8a5 : Sep 22 2014 20:47:40 UTC on Linux 3.8.11 (armv7l), built with libpci 3.1.10, GCC 4.8.x-google 20140307 (prerelease), little endian Reading flash... SUCCESS localhost ~ # /tmp/vbutil_what_keys /tmp/bios.bin -e BIOS: /tmp/bios.bin hwid: PIT D3A-D4Q-A3L root key: a026a7a4a0bf0fa32d6b7aa90a80d5ef01a3b799 Daisy MP-v3, Peach-Pi MP, Peach-Pit MP-v2, Snow MP recovery key: 6d9a2ca8b3080a97e1e5a4efbc5386ead77c3c7f Peach-Pit MP-v2 localhost ~ # Change-Id: I171da3bf688032f469d7a5cdb42278d8028b7e0d Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/221176 Reviewed-by: Mike Frysinger <vapier@chromium.org>
* cleanup: remove a couple of unused functions and filesfactory-storm-6269.BBill Richardson2014-09-121-879/+0
| | | | | | | | | | | | | | | | | | | | | | | | | scripts/sign_data.sh is just a wrapper to do this: ./signature_digest_utility $1 $3 \ | openssl rsautl -sign -pkcs -inkey $2 AFAICT, that script is only invoked by the SignatureFile() function in host/lib/file_keys.c, which is not referenced by anything. I think I can remove both of those things. Also remove utility/gbb_utility.cc, which should have been done long ago in commit 6f39615. BUG=none BRANCH=ToT TEST=make runalltests Also ran it on daisy_spring-paladin and link-tot-paladin. Change-Id: I16de5022765806f11bf6144d7ffd8cc849578a68 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/216719 Reviewed-by: Mike Frysinger <vapier@chromium.org>
* futility: stop using the symlink names in utility scriptsBill Richardson2014-09-123-22/+26
| | | | | | | | | | | | | | | | | | | | | | We still create the symlinks (FOO -> futility), but this change invokes those built-in functions with "futility FOO ..." instead of using the FOO symlink. Note that the scripts/ directory is unchanged. That's a separate CL, since we don't have tests for that. BUG=chromium:231547 BRANCH=ToT TEST=make runtests In addition to running "make runtests", I temporarily modified the Makefile to avoid creating the symlinks at all. The tests still passed. Change-Id: I96863259b9df02a3611f759a7509bf4090ae03e8 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/216717 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cleanup: remove ancient tests that haven't been run in yearsBill Richardson2014-08-291-250/+0
| | | | | | | | | | | | | | | There are a number of tests that haven't even been compiled in a LOOOONG time. Let's get them out of the way. We can always put them back later. I'm adding a comment to this CL in the Makefile. BUG=none BRANCH=ToT TEST=make runalltests Change-Id: Id2d9f0b71fc40e4a260f54cf919c6af5e0ff85c5 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/214610 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot2: Move vb2_verify_fw inside of futilityRandall Spangler2014-08-251-209/+0
| | | | | | | | | | | | | | | | | | | | | Update the unit tests which use it to use futility. No functional changes to it, just relocation. Remove the futility test which checks the exact list of supported commands. This doesn't have a good way of handling conditionally-compiled commands, and will be even harder to maintain as we add more commands in the future. Presence of sub-commands is still ensured by the other tests which use them (such as vb2_firmware_tests.sh) BUG=chromium:231547 BRANCH=none TEST=make runtests && VBOOT2=1 make runtests Change-Id: Idddb639276e4c6449d023d40ac7977123113bd28 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/213191 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Update vbutil_what_keys with more sha1sumsBill Richardson2014-08-011-116/+272
| | | | | | | | | | | | | BUG=none BRANCH=ToT TEST=manual Run vbutil_what_keys on some BIOS and disk images. Change-Id: Ib757b63fa79913920da25c08b1994273fd77e53f Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/210692 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* futility: Add remaining vboot binary utilitiesBill Richardson2014-07-317-1971/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change adds these formerly external utilities into the futility binary: dev_sign_file dump_kernel_config gbb_utility vbutil_firmware vbutil_kernel These target binaries will remain independent of futility, since they are not directly related to verified boot: cgpt crossystem tpm_init_temp_fix tpmc Also, dumpRSAPublicKey is removed from the target, since it is only used on the build host to create new keypairs. This change also add several additional tests. BUG=chromium:224734 BRANCH=ToT CQ-DEPEND=CL:210391,CL:210568,CL:210587 TEST=manual make runtests make clean Also build and test: - normal image - test image - recovery image - firmware shellball Note that this CL depends on simultaneous changes to the chromeos-initramfs ebuild. Change-Id: If791b5e9b5aac218ceafa9f45fc1785f16b91a64 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/210403
* futility: add vbutil_keyblock into the built-in featuresBill Richardson2014-07-171-325/+0
| | | | | | | | | | | BUG=chromium:224734 BRANCH=ToT TEST=make runtests Change-Id: Ie9efdcf0b69ab4697f050643b8f2f588e22d20d7 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/208368 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* futility: add vbutil_key into the built-in featuresBill Richardson2014-07-171-236/+0
| | | | | | | | | | | BUG=chromium:224734 BRANCH=ToT TEST=make runtests Signed-off-by: Bill Richardson <wfrichar@chromium.org> Change-Id: I6757a9c7f70bbe8d1db9bb3f0521778fbbb9632e Reviewed-on: https://chromium-review.googlesource.com/207927 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Cleanup: remove some noisy output from some utilitiesBill Richardson2014-07-153-6/+0
| | | | | | | | | | | | | | | | | There are a few utilities that print the full path of any file they open. This isn't necessary, and it just has to be ignored when running regression tests from different directories. This just removes that extra noise. BUG=chromium:224734 BRANCH=ToT TEST=make runtests Change-Id: I4291bca7952a0d7371f8682b7d57545361c6341c Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/207619 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Split libvboot_host.a into external and local libraries.Bill Richardson2014-07-094-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've been creating and linking against a library called "libvboot_host.a" for two different reasons. The main purpose is to build the vboot_reference tools found in the utility/ directory. But there are some external userspace programs that would also like to use some functions in this library. This change establishes libvboot_host.a as the library for use by external userspace programs only, and creates a new libvboot_util.a library that's only used inside this source tree to build the vboot utilities. BUG=chromium:231567 BRANCH=ToT TEST=manual Build and run the local tests: make runalltests make clean Build Link firmware and all the utilities: emerge-link chromeos-base/vboot_reference \ sys-boot/depthcharge \ sys-boot/coreboot \ chromeos-base/chromeos-ec \ chromeos-base/chromeos-firmware-link \ chromeos-base/chromeos-cryptohome \ chromeos-base/update_engine \ chromeos-base/chromeos-installer \ chromeos-base/chromeos-login \ chromeos-base/verity Build Lumpy utilities, which include the 32-bit cros_installer: emerge-lumpy chromeos-base/vboot_reference \ chromeos-base/chromeos-login \ chromeos-base/verity \ chromeos-base/update_engine \ chromeos-base/chromeos-installer \ chromeos-base/chromeos-cryptohome Change-Id: Ie81ff1f74a6356cb8fab7d98471139d7758c4f19 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/207016 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add nvstorage / crossystem support for new vboot2 fieldsRandall Spangler2014-06-281-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows testing vboot2. These fields are ignored by original vboot firmware. BUG=chromium:370082 BRANCH=none TEST=manual crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A crossystem fw_tried=B echo $? -> 1 crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A crossystem fw_try_next=B crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=B crossystem fw_try_next=beats_me echo $? -> 1 crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=B crossystem fw_try_next=A crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A crossystem fw_result=trying crossystem -> fw_tried=A, fw_result=trying, fw_try_next=A crossystem fw_result=bupkis echo $? -> 1 crossystem -> fw_tried=A, fw_result=trying, fw_try_next=A crossystem fw_result=success crossystem -> fw_tried=A, fw_result=success, fw_try_next=A crossystem fw_result=failure crossystem -> fw_tried=A, fw_result=failure, fw_try_next=A crossystem fw_result=unknown crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A crossystem -> fw_try_count = 0, fwb_tries = 0 crossystem fw_try_count=6 crossystem -> fw_try_count = 6, fwb_tries = 6 crossystem fwb_tries=0 crossystem -> fw_try_count = 0, fwb_tries = 0 Change-Id: I1532f3384f8c05de2a7ff3f35abcc35d18049491 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/205475
* vboot2: add a flag to indicate firmware was selected by vboot2Daisuke Nojiri2014-06-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | TEST=Done manually on Nyan: localhost ~ # sudo /tmp/crossystem fw_vboot2 0 localhost ~ # sudo /tmp/crossystem fw_vboot2=1 localhost ~ # sudo /tmp/crossystem fw_vboot2 0 # reboot with vboot2 firmware localhost ~ # /tmp/crossystem fw_vboot2 1 BUG=none BRANCH=none Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Change-Id: I6ed553c48bdfebf07393f6f5f46832a60971314a Reviewed-on: https://chromium-review.googlesource.com/205664 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
* vboot2: Add end-to-end test of firmware verificationstabilize.59781.98.Bstabilize.5978.98.Bstabilize.5978.51.Brelease-R37-5978.BRandall Spangler2014-06-201-4/+4
| | | | | | | | | | | | | | | | This constructs a test firmware using the old vboot signing utilities, and then verifies it using vboot2 libraries. This ensures vboot2 can read files signed by the current signing process. BUG=chromium:370082 BRANCH=none TEST=VBOOT2=1 make runtests Change-Id: Icc113c982e5ed99382a4592f9ab688784e853c8e Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/204561 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* vboot2: api-level routinesRandall Spangler2014-06-191-0/+209
| | | | | | | | | | | | | | I'm breaking the last chunk of vboot2 into smaller pieces as I add tests. This has the api-level routines actually called by depthcharge. BUG=chromium:370082 BRANCH=none TEST=make clean && VBOOT2=1 COV=1 make Change-Id: Ic7c082fc5faa0b874b2fa5a15ebda7135dcafe0b Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/200151 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Use the TPM to back up some of the nvram fieldsBill Richardson2014-06-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We use a few bytes of battery-backed nvram to save some flags across reboots. However if the battery discharges completely, these flags are lost. There aren't any security issues with that since they reset to safe values, but some of the flags are used to configure how the system boots in dev-mode. If a dev-mode user has completely replaced ChromeOS with some other OS, then she often needs to set the dev_boot_usb and/or dev_boot_legacy flags as well in order to boot it using Ctrl-U or Ctrl-L. If the battery dies, then those flags are cleared, and the only way to make the Chromebook boot again is by going through recovery, which wipes the disk. This change uses a new NV space in the TPM to back up some of the nvram flags. These nvram fields will be backed up: block_devmode dev_boot_legacy dev_boot_signed_only dev_boot_usb fwupdate_tries loc_idx Because writing to the TPM space is slow and limited to an unspecified but finite number of cycles, we only back up the fields when specifically requested by the new backup_nvram_request flag. This flag will be set by crossystem whenever it is used to change any of the fields listed above. The backup will be attempted at the NEXT boot (because the TPM is locked after booting), and the backup_nvram_request flag will be cleared if the backup was successfull. Note that this CL is for Top of Trunk only. The firmware will create the required TPM spaces on systems that have never been booted, but we don't yet have a secure or reliable method to update existing systems. FYI, on Link, determining that the TPM's backup NV space doesn't exist adds about 6ms to the boot time. If it does exist, the backup_nvram_request flag is cleared automatically so it won't check until it's set again. BUG=chromium:362105 BRANCH=ToT (only!) TEST=manual Testing this is a long and involved process. Read on... First, there are host-side tests for it. In the chroot: cd src/platform/ec make runtests Second, to test on a completely NEW system that was first booted with a BIOS that contains this CL, do this: Enter dev-mode Use crossystem to set values for the fields listed above Confirm that "backup_nvram_request" is set to 1 Reboot Use crossystem to confirm that "backup_nvram_request" is now 0 Remove the battery and the AC Reattach either battery or AC so it will boot again Use crossystem to confirm that the backed up fields are still good, while the others have been reset to default values Switch to normal mode Remove the battery and the AC Reattach either battery or AC so it will boot again Look at the bios info in chrome://system to see what crossystem says Confirm that the dev_boot_* flags are all 0, while the others are restored Third, to set things up to test this on an existing system (I used Link), you have update the BIOS, delete both the Kernel and Firmware NV spaces in the TPM, then reboot so that the BIOS will create the Backup, Kernel, and Firmware spaces. It will only do that if they're all missing. Open it up, disable write-protect, attach a servo, etc. Switch to dev-mode, log in. Run make_dev_firmware.sh Reboot in recovery mode, and insert a USB stick with a test image on it. NOTE: In order to fiddle with the TPM, we'll *always* have to boot in recovery mode, since that's the only time the TPM is left unlocked. That's NOT the same as pressing Ctrl-U at the scary boot screen. The rest of these steps assume you've booted in recovery mode and are running from the test image on the USB stick. Run make_dev_ssd.sh --remove_rootfs_verification --recovery_key Reboot (recovery mode) Run mv /etc/init/tcsd.conf /etc/init/tcsd.conf.disabled Reboot (recovery mode). Run "tpmc getvf". It should say deactivated 0 disableForceClear 0 physicalPresence 1 physicalPresenceLock 0 bGlobalLock 0 Run "tpmc geto". It should say Owned: no Now you'll need to build the "tpm-nvtool" utility. In the chroot: cd src/third_party/tpm/nvtool make Copy that to the DUT, in /usr/local/bin. Now run tcsd tpm-nvtool --list | grep Index You may see a number of spaces, but you should at least see these: # NV Index 0x00001007 # NV Index 0x00001008 Run tpm_takeownership It will prompt you for two passwords (and confirm each one). Respond with something you can remember like "google". Run tpm-nvtool --release --index 0x1007 --owner_password "google" tpm-nvtool --release --index 0x1008 --owner_password "google" Verify that it worked with tpm-nvtool --list | grep Index Power off. Using servo, flash the new BIOS that has this CL in it. Power on, normally this time (not recovery mode). If all goes well, it should create the correct NV spaces and boot into the SSD. Copy tpm-nvtool into this image too, and run tpm-nvtool --list | grep Index You should now see at least these spaces: # NV Index 0x00001007 # NV Index 0x00001008 # NV Index 0x00001009 Now you're ready to test the backup/recover feature. Change-Id: I00031fa0774720147327e2ae0f37e26b34b86341 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/202138 Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
* vbutil_kernel: Add enum for the mips architectureGaurav Shah2014-05-151-1/+4
| | | | | | | | | | | BUG=chromium:327749 TEST=emerge vboot_reference BRANCH=none Change-Id: I627636d8433c0a8cdbd2c7b24cc405a41173658f Reviewed-on: https://chromium-review.googlesource.com/199993 Reviewed-by: Mike Frysinger <vapier@chromium.org> Tested-by: Gaurav Shah <gauravsh@chromium.org> Commit-Queue: Gaurav Shah <gauravsh@chromium.org>
* Add an nvram flag to block the use of dev modestabilize-swanky-5841.55.Bstabilize-gnawty-5841.84.Bstabilize-5841.83.Bstabilize-5841.76.Bstabilize-5828.0.Brelease-R36-5841.Bfirmware-tricky-5829.Bfirmware-mccloud-5827.BBill Richardson2014-05-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, this does nothing. It just sets a flag that nothing looks at. Don't get all wound up - we haven't abandoned our principles. This will eventually be used to allow enterprise-enrolled customers to prevent unauthorized use of developer mode in the Chrome OS devices that THEY OWN. This is not Google deciding to turn a feature off, it's allowing the OWNER to control the use of the feature. In some situations, the owner can be held liable for what others do with the owner's equipment. This will help the owner avoid those situations while their device is out of their immediate control. BUG=none BRANCH=ToT TEST=manual Set the flag with: crossystem block_devmode=1 Clear it with: crossystem block_devmode=0 Retrieve the value ("0" or "1") like so: val=$(crossystem block_devmode) echo "the flag is $val" or just test it directly like so: if crossystem 'block_devmode?1' ; then echo "devmode is blocked" else echo "devmode is allowed" fi It should be persistent across reboots. Change-Id: I097f15b307e1c3a2a9db595e9495028a2eea6309 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/197771 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Make crossystem.h more polite and more useful.test-4980.Btest-4824.Bstabilize-R33-4982.Bstabilize-5062.Bstabilize-4920.6.Brelease-R32-4920.Bfirmware-bolt_kirby-4979.Bfactory-panther-4920.23.BJ. Richard Barnette2013-10-311-6/+3
| | | | | | | | | | | | | | | | | | | This adds a VB_MAX_STRING_PROPERTY for callers that don't want to guess at how big to make their buffers. Additionally, it changes the size parameter to VbGetPropertyString() from int to size_t. BUG=None TEST=compile the code BRANCH=none Change-Id: I22809d48e13b535593cb22a56444e2dcb27791a5 Reviewed-on: https://chromium-review.googlesource.com/175039 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Richard Barnette <jrbarnette@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Queue: Richard Barnette <jrbarnette@chromium.org>
* Add a "debug_build" query to crossystem.J. Richard Barnette2013-10-231-1/+2
| | | | | | | | | | | | | | | | | Querying "debug_build" allows the caller to determine whether the image has requested debug, independent of the setting of the dev_mode switch. BUG=chromium:308678 BRANCH=none TEST=use the new command option on both base and dev images Change-Id: I369f26d75156f2e88d9f6f467efbf8f633e78bda Reviewed-on: https://chromium-review.googlesource.com/174107 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Richard Barnette <jrbarnette@chromium.org> Reviewed-by: Will Drewry <wad@chromium.org> Commit-Queue: Richard Barnette <jrbarnette@chromium.org>
* Implementation of Region APIstabilize-4636.BSimon Glass2013-08-301-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present reading data from storage in Vboot is a little fragmented. For the firmware image, we expect the boot loader to handle this. For the disk we have a block-level API. For the GBB (which also sits in the firmware image) we expect the entire thing to be read before Vboot is called. Add the concept of a region, and an API to read from a region. At present, and most pressing, is reading from a GBB region. In the future this could be extended to other parts of the firmware or even the disk. Move all access to the GBB into this API so that the boot loader can provide either a GBB region in one large contiguous chunk, or a function to deal with read requests from vboot. The call to VbExRegionRead() is behind a flag since not all boot loaders support it yet. The main change for boot loaders which don't support this new API is that vboot will do more behind the scenes. For example, it will allocate memory for chunks of data that it reads from the GBB, rather than just accessing it directly. This approach is considerably simpler than trying to pass char ** everywhere and have vboot decide whether something needs to be allocated or not. The tests are updated, mainly to include setting up a GBB structure accessible from VbCommonParams, which is now required by the firmware and kernel functions. In normal operation this is set up at the start of VbLoadFIrmware() and VbSelectAndLoadKernel() but for tests which call children of these functions directly, the GBB structure must be set up manually by the test. BUG=chrome-os-partner:21115 BRANCH=none TEST=manual FEATURES=test sudo -E emerge vboot_reference Change-Id: If2b8bbe467fdbd643239d8d9b5d7aa98df4d286f Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/63336 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/167361
* Revert "Implementation of Region API"Yoshiki Iguchi2013-08-291-4/+1
| | | | | | | | | | | | | This reverts commit 1d3c804b6b9d2ffb6953a7ee98fabfd548915ad7. This patch breaks cbuildbot on internal paladins bots. Change-Id: Icf7f9d9bbb56b092035888eaa3e249ffd23fac16 (cherry picked from commit 3a60335ebb1530e5fd9d5da3bc6214949bc59caf) Reviewed-on: https://chromium-review.googlesource.com/167451 Reviewed-by: Yoshiki Iguchi <yoshiki@chromium.org> Commit-Queue: Yoshiki Iguchi <yoshiki@chromium.org> Tested-by: Yoshiki Iguchi <yoshiki@chromium.org>
* Implementation of Region APISimon Glass2013-08-281-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present reading data from storage in Vboot is a little fragmented. For the firmware image, we expect the boot loader to handle this. For the disk we have a block-level API. For the GBB (which also sits in the firmware image) we expect the entire thing to be read before Vboot is called. Add the concept of a region, and an API to read from a region. At present, and most pressing, is reading from a GBB region. In the future this could be extended to other parts of the firmware or even the disk. Move all access to the GBB into this API so that the boot loader can provide either a GBB region in one large contiguous chunk, or a function to deal with read requests from vboot. The call to VbExRegionRead() is behind a flag since not all boot loaders support it yet. The main change for boot loaders which don't support this new API is that vboot will do more behind the scenes. For example, it will allocate memory for chunks of data that it reads from the GBB, rather than just accessing it directly. This approach is considerably simpler than trying to pass char ** everywhere and have vboot decide whether something needs to be allocated or not. The tests are updated, mainly to include setting up a GBB structure accessible from VbCommonParams, which is now required by the firmware and kernel functions. In normal operation this is set up at the start of VbLoadFIrmware() and VbSelectAndLoadKernel() but for tests which call children of these functions directly, the GBB structure must be set up manually by the test. BUG=chrome-os-partner:21115 BRANCH=none TEST=manual FEATURES=test sudo -E emerge vboot_reference Change-Id: I2c19e9dc2ed602d0642bbf4f7d27f79fe9fad873 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/63336 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Avoid exit code overflow for tpmc.Luigi Semenzato2013-08-281-5/+7
| | | | | | | | | | | | | | | | | In case of a TPM error, tpmc returns the TPM error code, which can be greater than 255. In that case the error code is truncated. Some error codes, such as TPM_E_RETRY, end with a zero byte, resulting in a successful exit code. This is despicable. BUG=chromium:234357 TEST=tested with exit codes < 255. Too hard to generate the others. BRANCH=none Change-Id: I891a5c0659c06aac778449e2a0a935c5f82ccdb8 Reviewed-on: https://chromium-review.googlesource.com/66885 Reviewed-by: Luigi Semenzato <semenzato@chromium.org> Commit-Queue: Luigi Semenzato <semenzato@chromium.org> Tested-by: Luigi Semenzato <semenzato@chromium.org>
* Change flashrom target selection parameter.Hung-Te Lin2013-08-211-3/+3
| | | | | | | | | | | | | | | The "-p internal:bus=*" is now deprecated by "-p {host,ec}" because we may have EC on SPI bus. BUG=none TEST=manually executed dev_debug_vboot and see correct output. BRANCH=none Change-Id: I6363c09c2ebf57812bf35b7db220303a2786db20 Reviewed-on: https://gerrit.chromium.org/gerrit/66321 Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org> Commit-Queue: Hung-Te Lin <hungte@chromium.org>
* vbutil_kernel: copy zeropage fullyKees Cook2013-04-112-14/+16
| | | | | | | | | | | | | | | | | | When copying the vmlinuz zeropage, the entries were being truncated even though the boot protocol version was being retained. This means that booting a kernel that depended on details from the zeropage's ignored areas would find invalid information. Fix this by copying out the entire possible range of memory. BUG=chromium:230212 TEST=kernels can boot with CONFIG_RELOCATABLE BRANCH=None Change-Id: Ifb94bedcf881e17ab20fff44d8c1c1885b15ef9e Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/47832 Reviewed-by: Luigi Semenzato <semenzato@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Build dump_fmap into futility.Bill Richardson2013-04-091-472/+0
| | | | | | | | | | | | | | | | | | This stops creating dump_fmap as a standalone utility and builds it into futility. Since it was already invoked as a symlink, no user-visible changes should be observed. BUG=chromium:224734 BRANCH=none TEST=manual, trybots sudo FEATURES=test emerge vboot_reference FEATURES=test emerge-$BOARD vboot_reference Change-Id: I68d1bea0c1867043b2633e15509b95c2717009a7 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/47672 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Massive refactoring of external header files.Bill Richardson2013-04-029-35/+19
| | | | | | | | | | | | | | | | | | | | | | | | This reduces the number of exported header files to the minimum needed by the existing userspace utilities and firmware implementations. BUG=chromium:221544 BRANCH=none TEST=manual, trybots CQ-DEPEND=CL:47019,CL:47022,CL:47023 sudo FEATURES=test emerge vboot_reference FEATURES=test emerge-$BOARD \ vboot_reference \ chromeos-cryptohome \ chromeos-installer \ chromeos-u-boot \ peach-u-boot \ depthcharge Change-Id: I2946cc2dbaf5459a6c5eca92ca57d546498e6d85 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/47021 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Simplify the exported FindKernelConfig() function.Bill Richardson2013-03-293-27/+51
| | | | | | | | | | | | | | | | | | FindKernelConfig() is used to extract the kernel cmdline from a kernel partition. It's only used in the chromeos-installer, but was a bit awkward. This changes the calling parameters to make it simpler. BUG=chromium:221544 BRANCH=none TEST=manual CQ-DEPEND=CL:46835 FEATURES=test sudo emerge vboot_reference FEATURES=test emerge-$BOARD vboot_reference Change-Id: Ib7192175d72ad51387d8d122ead4490a4aa62300 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/46834
* Apply consistent naming scheme for hostlib functions.Bill Richardson2013-03-203-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The chromeos-installer uses several functions from the vboot_reference userspace library, but the names of those functions are inconsistent: IsZero MapFile VbGetSystemPropertyString cgpt_add cgpt_boot cgpt_create cgpt_get_boot_partition_number cgpt_get_num_non_empty_partitions cgpt_get_partition_details cgpt_prioritize cgpt_set_attributes find_kernel_config The Google C++ style guide says types and functions should use CamelCase, while variables use lower_case_with_underscores. Kernel style (which vboot_reference tries to be more-or-less compatible with) uses lower_case_with_underscores for everything, but that really only has to apply to firmware stuff. For userspace, we can use the Google style. BUG=chromium:221544 BRANCH=none TEST=buildbot CQ-DEPEND=CL:46045 Renaming/cleanup only; no functional changes. Change-Id: I9c82c9ff8909be88586194c8ffdb435fc771195f Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/46044
* Get rid of some crufty macros.Gabe Black2013-03-191-3/+4
| | | | | | | | | | | | | | | | | | | | | | | These were macros that were never used, or that were only set to one thing and could be substituted up front. I left in code guarded by the HAVE_ENDIAN_H and HAVE_LITTLE_ENDIAN macros even though those are never defined because they guard a reportedly significantly faster implementation of some functionality, at least according to a comment in the source. It would be a good idea to enable that code path and see if it really does make a big difference before removing it entirely. BUG=None TEST=Built for Link, Daisy, and the host with FEATURES=test. Built depthcharge for Link and booted in normal mode. BRANCH=None Change-Id: I934a4dd0da169ac018ba07350d56924ab88b1acc Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/45687 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org>
* Wrap all vboot utilities with futility.firmware-spring-3833.Bfactory-spring-3842.BBill Richardson2013-03-113-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This moves all the old userspace utilities generated by vboot_reference into a subdirectory not in $PATH, and replaces them with symlinks to a single executable named 'futility'. At the moment that utility just execs the original utilities (optionally logging that fact first). Ultimately, the old utilities will be subsumed into a single binary instead of multiple separate executables. There is a matching CL needed to make the recovery image creation work. BUG=chromium-os:37062 BRANCH=none CQ-DEPEND=CL:44864 TEST=auto To test, build everything, test everything. It should work as before in all cases. I have built normal images, test images, factory installers, recovery images; they all seem to work. I've run trybots on daisy-paladin link-paladin lumpy-paladin and alex-paladin. Change-Id: Ie93db676f2ed2a64e4b13b3b5dc6b65a77db0f8c Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/44871 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org>
* Remove the mount-encrypted utility from vboot_referenceBill Richardson2013-02-284-2338/+0
| | | | | | | | | | | | | | | | | | | | | | | This utility sets up the encrypted directories for Chrome OS at boot time. It uses some of the TPM-related libraries from vboot_reference, but it isn't really part of the verified boot process itself so I'm moving it into the cryptohome repo where it belongs. This CL just removes the code from vboot_reference. Another CL will put it into cryptohome, and yet another will change the ebuilds to notices. BUG=chromium-os:39264 BRANCH=none TEST=auto CQ-DEPEND=CL:44301, CL:44302 This is just refactoring, not a new feature. After all the CLs are in, the platform_EncryptedStateful autotest should continue to pass as before. Change-Id: I6bb436ae57140e89581cb0be5dc2385b8f3ff5e2 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/44303 Reviewed-by: Kees Cook <keescook@chromium.org>
* mount-encrypted: issue sync()s between umount stagesKees Cook2013-02-211-0/+9
| | | | | | | | | | | | | | | | In an effort to reduce the chances of a kernel bug wrecking filesystems during encrypted-stateful shutdown, add explicit sync() calls during shutdown. BUG=chrome-os-partner:17610 TEST=link build, shutdown with simulated panic in LOOP_CLR_FD results in successful journal replays BRANCH=None Change-Id: I4be981ebd0270d275ae81a79e3195bc72b70d984 Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/43736 Reviewed-by: Grant Grundler <grundler@chromium.org>
* Remove hardcoded path in unused chromeos-tpm-recovery-testBill Richardson2013-02-131-1/+1
| | | | | | | | | | | | | | | AFAICT, we don't actually run this test anywhere. If we do, we shouldn't hard-code the path to the real chromeos-tpm-recovery utility, because we may need to move it around. BUG=none BRANCH=none TEST=none Change-Id: I295d57d659adf564ca964efc91d95dfdd1ff00aa Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/43174 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Remove unused vbutil_ecRandall Spangler2013-01-241-532/+0
| | | | | | | | | | | | | | | | | EC verification is done via software sync; the EC doesn't do vboot on its own. BUG=chromium-os:38139 BRANCH=none TEST=manual make runtests emerge-link vboot_reference chromeos-u-boot chromeos-bootimage Change-Id: I6e5c0db8fc54b474f044d37c2603a9c116747a85 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/41953 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* mount-encrypted: expprt nvram contents to tmpfsWill Drewry2013-01-171-1/+33
| | | | | | | | | | | | | | | | | Export the NVRAM contents to tmpfs (/tmp) for use during boot without incurring the cost of repeated trips through the TPM. Signed-off-by: Will Drewry <wad@chromium.org> BUG=chromium-os:37367 TEST=builds, boots, emits lockbox.nvram which validates using in-progress lockbox-cache BRANCH=none Change-Id: I8b1103f4bd22bd75e98a7617a571bdb3a06d2914 Reviewed-on: https://gerrit.chromium.org/gerrit/41433 Reviewed-by: Kees Cook <keescook@chromium.org> Commit-Queue: Will Drewry <wad@chromium.org> Reviewed-by: Will Drewry <wad@chromium.org> Tested-by: Will Drewry <wad@chromium.org>
* Make tpmc able to send and receive raw datagrams.Luigi Semenzato2013-01-111-0/+44
| | | | | | | | | | | | | | | | This is immediately needed to debug a Parrot TPM problems, but we've had similar situation in the past and probably will again in the future. BUG=chromium-os:37819 TEST=manually tested with a couple of different packets, and error inputs BRANCH=none Change-Id: Id7f66bdbdfe5887fa49cd62af4a9b807fa3d9a89 Reviewed-on: https://gerrit.chromium.org/gerrit/41166 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Luigi Semenzato <semenzato@chromium.org> Tested-by: Luigi Semenzato <semenzato@chromium.org>
* Rename files and defines to simplify makefile.Randall Spangler2013-01-118-172/+172
| | | | | | | | | | | | | | BUG=chromium-os:26317 BRANCH=none TEST=manual sudo emerge vboot_reference emerge-link vboot_reference chromeos-u-boot chromeos-installer emerge-daisy vboot_reference chromeos-u-boot chromeos-installer Signed-off-by: Randall Spangler <rspangler@chromium.org> Change-Id: I8c55ca40f3f0cacf08530ab63c886fe351bcee8e Reviewed-on: https://gerrit.chromium.org/gerrit/41152
View Lorry Controller Status