summaryrefslogtreecommitdiff
path: root/utility
Commit message (Collapse)AuthorAgeFilesLines
* crossystem: Remove savedmem_base and savedmem_size fieldsstabilize-7647.74.Bstabilize-7647.72.Bstabilize-7647.32.Bstabilize-7628.Brelease-R48-7647.BJulius Werner2015-11-091-2/+0
| | | | | | | | | | | | | | | | | | | I don't even know what this is. It seems to have marked some kind of debug buffer provided by H2C BIOS on pre-Daisy Chromebooks and has not been touched since it was copied in here when crossystem was first added. I can't find any references in our codebase so I doubt anybody would miss it. Let's remove it so the '(error)' fields returned there on any modern Chromebook stop confusing our vendors. BRANCH=None BUG=chromium:551715 TEST=Built for Falco and Jerry. Change-Id: Ie2baec536b50bb192eb4cd3e48df212cce53561a Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/311346 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
* crossystem: Remove platform_family fieldJulius Werner2015-11-091-1/+0
| | | | | | | | | | | | | | | | | This field doesn't seem to be used for anyone and it keeps adding work for people trying to bring up new platforms. If we ever needed something like this again, we'd probably prefer to have it in mosys now anyway. Let's get rid of it. BRANCH=None BUG=chromium:551715 TEST=Built for Falco and Jerry. Change-Id: I6b96e255968fdd22a345d4a75bfdc1e79d3f5896 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/311345 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
* Add NV flag to default boot legacy OSMary Ruthven2015-10-131-0/+2
| | | | | | | | | | | | | | | | In developer mode, this option will make the system try to boot into a legacy OS first after the 30 second timeout. This removes the need to press a key during boot to try legacy mode and the need to remove the write protect screw to boot legacy as default. BUG=chromium:310697 BRANCH=none TEST=make runtests Change-Id: I9a9f64c14ad015e21d08eec36e8fc187189cd2f2 Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/304077 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot2: Support reboot requested by secdataRandall Spangler2015-09-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a TPM goes from the disabled state to the enabled state, it must reboot after being enabled, before it can be initialized. In vboot1, TLCL was part of vboot and this was handled internally. In vboot2, the caller must set a context flag, so that vboot can decide whether to allow the reboot, or whether to go directly to recovery mode. This check is necessary to handle the following cases: 1) The device is booting normally, but the TPM needs a reboot. This should simply reboot, without going to recovery mode. 2) The device is booting in recovery mode, but the TPM needs a reboot. If this is the first time it asked us, allow the reboot. 3) The TPM asked for a reboot last time, so we did. And it's still asking. Don't reboot, because that runs the risk that whatever is wrong won't be fixed next boot either, and we'll get stuck in a reboot loop that will prevent recovery. Boot into recovery mode. Add a new NvStorage bit to track whether the TPM requested a reboot on the previous boot. That's better than what we did in vboot1, where we used a special recovery request. Vboot1 couldn't track getting stuck in a reboot loop in normal mode, only in recovery mode. The new code can catch both. BUG=chrome-os-partner:45462 BRANCH=ryu TEST=make runtests Change-Id: I2ee54af107275ccf64a6cb41132b7a0fc02bb983 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/300572 Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
* Add "tpmc pcrextend" command to extend a PCRstabilize-7356.BKevin Cernekee2015-08-101-0/+37
| | | | | | | | | | | | | | | | | | | | | | | This is useful for testing different configurations without repeatedly reflashing the firmware, e.g. # stop tcsd # tpmc pcr 0 0000000000000000000000000000000000000000 # tpmc pcrextend 0 c42ac1c46f1d4e211c735cc7dfad4ff8391110e9 # tpmc pcr 0 865aedd337518e56f648440b81b4cbd9359fdff3 <reboot and try another value> BUG=none BRANCH=none TEST=manual Change-Id: Ie5814ca2a3a5cf5a0eaf0ffee0385315db09bf25 Signed-off-by: Kevin Cernekee <cernekee@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/289009 Reviewed-by: Luigi Semenzato <semenzato@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org>
* crossystem: Revise description of sw_wpsw_boot.release-R45-7262.BHung-Te Lin2015-07-091-1/+1
| | | | | | | | | | | | | | | | The sw_wpsw_boot was made for some feature that was almost never completed, and only makes sense on Baytrail platforms. To prevent confusion we should address that in the crossystem description. BRANCH=none BUG=chromium:508269 TEST=make test Change-Id: I1fbc7a0e9e8c1f8503ae8ae9dfb6e80c8da892e3 Reviewed-on: https://chromium-review.googlesource.com/284425 Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Queue: Hung-Te Lin <hungte@chromium.org>
* chromeos-tpm-recovery: Convert to manual TPM reset script for developersJulius Werner2015-05-161-249/+35
| | | | | | | | | | | | | | | | | | | | | chromeos-tpm-recovery has not been used for anything in forever (see CL:238236), but it is still installed on every image. Resetting the TPM (e.g. to resolve rollback issues when reflashing an MP-signed device to dev firmware) is a common request by developers, and I get tired of always digging out the required tpmc commands manually again. Let's repurpose this script as a simple one-shot tool for developers to reset their TPM, so the next time someone asks we can just tell them 'boot a test image in recovery mode and run chromeos-tpm-recovery'. BRANCH=none BUG=chromium:419942 TEST=Ran on a Jerry, confirmed that TPM spaces were reset. Change-Id: Ia95246cfed3dc9b0c6fdb0481218e3ae14d8318a Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/271512 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
* vboot_reference: remove dependency on trousersLuigi Semenzato2015-04-291-1/+1
| | | | | | | | | | | | | | | | | | This is done to break a circular DEPENDency as we want to send UMA stats from tcsd. Without this, metrics depends on vboot_reference which depends on trousers which depends on metrics. Technically the vboot_reference dependency on trousers is header-file only, but we can't cope with that. BUG=chromium:481552 TEST=compiled with emerge-<something> vboot_reference BRANCH=none Change-Id: Iea5c0c39bb70977c9d375e63ea607687debe9f9f Reviewed-on: https://chromium-review.googlesource.com/267744 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Luigi Semenzato <semenzato@chromium.org> Tested-by: Luigi Semenzato <semenzato@chromium.org>
* crossystem: Deprecate ddr-typeDavid Hendricks2015-04-071-1/+0
| | | | | | | | | | | | | | | | | AFAICT this property is not really used by anything. All factory scripts that need detailed memory info get it from mosys. Most platforms display "unknown" which causes confusion whenever a bug is filed to support crossystem on a new platform. BUG=chrome-os-partner:36176 BRANCH=none TEST=no more "unknown" ddr-type shown in crossystem output on speedy Signed-off-by: David Hendricks <dhendrix@chromium.org> Change-Id: I97e66c362e9d88c843128a411512d5a76ac5f87d Reviewed-on: https://chromium-review.googlesource.com/263982 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot: fix name-collision with OpenSSL.stabilize-6946.55.Bstabilize-6937.Brelease-R43-6946.BAdam Langley2015-04-021-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | vboot currently uses the |SHA256_CTX| name, which is claimed by OpenSSL. To work around this, it defines OPENSSL_NO_SHA, but that can't be done at compile time: The OPENSSL_NO_* defines are set by OpenSSL to reflect the configuration that it was built with so that users of OpenSSL can disable features as needed. They can affect the contents of structures any thus the ABI of the library. If these defines are set outside of OpenSSL, then the library and the code that uses it will have incompatible ABIs. At that point it's only functioning by blind luck. This change renames the name-collisions so that this hack isn't needed. This is the same change as was made internally in cl/85758149. BUG=none BRANCH=none TEST=emerge-samus coreboot; make runtests Change-Id: I709da2507f341896d89d50129ce30ffb111a20d1 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/263506 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* 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
View Lorry Controller Status