summaryrefslogtreecommitdiff
path: root/firmware/2lib
Commit message (Collapse)AuthorAgeFilesLines
* Add new recovery reason for rec hash space lock failure in RO firmwarestabilize-8975.BFurquan Shaikh2016-11-091-0/+3
| | | | | | | | | | | | BUG=chrome-os-partner:59355 BRANCH=None TEST=make -j runtests Change-Id: Ife661afea83f65ba262e50e9743a64628972d39e Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/408568 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* recovery: Add new recovery reason to train memory and rebootFurquan Shaikh2016-11-081-0/+3
| | | | | | | | | | | | | | | | | This new recovery reason will instruct the calling firmware in vboot_select_and_load_kernel to reboot the device (under the assumption that training of memory has already been performed by the firmware). On seeing the return code VBERROR_REBOOT_REQUESTED, calling firmware should perform a reboot. BUG=chrome-os-partner:59352 BRANCH=None TEST=make -j runtests successful Change-Id: I110a735e612665cb2378bd71ca01a111edaf58e3 Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/407656 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot: Add vb2_unpack_key_bufferRandall Spangler2016-11-061-6/+9
| | | | | | | | | | | | | | | | | Previously, vb2_unpack_key() actually unpacked a key buffer. Callers that had a vb2_packed_key had to typecast it back to a uint8_t buffer to unpack it. Rename vb2_unpack_key() to vb2_unpack_key_buffer(), and make vb2_unpack_key() unpack a vb2_packed_key. BUG=chromium:611535 BRANCH=none TEST=make runtests; emerge-kevin coreboot depthcharge; emerge-samus and boot it Change-Id: I9ee38a819c59cc58a72ead78cf5ddf3d0f301ae7 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/400906 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* vboot: use vb2 verification functions for kernel verificationRandall Spangler2016-10-291-0/+6
| | | | | | | | | | | | | This removes old vboot1 functions in favor of the new vboot2 functions. BUG=chromium:611535 BRANCH=none TEST=make runtests; emerge-kevin coreboot depthcharge Change-Id: Idc64f7714bbd9d4fa82d14b6b5d73d71c61de854 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/400900 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* tests: Fix coverity warningsRandall Spangler2016-09-151-0/+8
| | | | | | | | | | | | | | Assorted minor code issues, which we should fix so any new errors stand out more. BUG=chromium:643769 BRANCH=none TEST=make runtests Change-Id: I927571f8a30794c70228506afe4da3eda86f765b Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/383953 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* futility: Use vboot 2.0 APIs for public keysRandall Spangler2016-09-021-0/+6
| | | | | | | | | | | | | | This replaces calls to the old vboot 1 APIs with their vboot 2.0 equivalents. BUG=chromium:611535 BRANCH=none TEST=make runtests Change-Id: Ieb1a127577c6428c47ac088c3aaa0d0dad6275a8 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/356541 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* futility: Use vboot 2.0 APIs for private keysRandall Spangler2016-08-101-0/+3
| | | | | | | | | | | | | | This replaces calls to the vboot 1 host library with their vboot 2.0 equivalents. BUG=chromium:611535 BRANCH=none TEST=make runtests Change-Id: Id061554fd82ea3efe35d0fe1485693b47599a863 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/356540 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* futility: Use only vboot 2.0 APIs for keyblocksRandall Spangler2016-08-101-0/+3
| | | | | | | | | | | | | | This refactors futility and the host library to use only vboot 2.0 APIs to create and verify keyblocks. BUG=chromium:611535 BRANCH=none TEST=make runtests Change-Id: Ia3cc1e24971b94f01bcb4890c8666a3af6f84841 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/356129 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* vboot: Upgrade VerifyFirmwarePreamble() to vboot2.0Randall Spangler2016-07-262-2/+14
| | | | | | | | | | | | | | | This replaces all calls to vboot1 VerifyFirmwarePreamble() with equivalent vb2.0 functions. No effect on ToT firmware, which already uses the vboot2.0 functions. BUG=chromium:611535 BRANCH=none TEST=make runtests Change-Id: I5c84e9ed0e0c75e2ea8dbd9bfcde0597bc457f24 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/349322 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* vboot: Disambiguate vb2.1 structs and functionsRandall Spangler2016-07-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Futility needs to link against both vboot1/vboot2.0 and vboot2.1 functions. This was easy in the past because it did (vboot1 + vboot2.1) and there's no overlap. In replacing vboot1 function calls and structs with vboot2.0, now there are symbol collisions between vboot2.0 and vboot2.1. For example, both of them use a struct called vb2_signature, but the structs are defined differently. Functions which operate on those structs also overload. Rename the vb2.1 structs to start with vb21_ instead of vb2_. Do the same for vb2.1 functions which operate on vb2.1 data. BUG=chromium:611535 BRANCH=none TEST=make runtests Change-Id: I24defd87cbd9ef64239faf1a8e98ab2372d27539 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/347458 Reviewed-by: Daisuke Nojiri <dnojiri@google.com>
* vb2api: pad digest buffers if they are larger than digest sizesVadim Bendebury2016-07-061-0/+3
| | | | | | | | | | | | | | | | | Extending tpm PCRs in case of TPM2 requires 32 bit values, some digests pre-calculated in vboot source code are 20 bytes in size. To make sure that PCR extension is consistent, pad remaining buffer space when a 20 byte digest is returned in a 32 byte buffer. BRANCH=none BUG=chrome-os-partner:50645 TEST=did not verify much, made sure that PCR extension commands triggered by coreboot succeed. Change-Id: Ib16bdf782f18a6106eadb4b880cd1e67b56ad6db Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/358175 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vb2_sha: Add sha256 extendDaisuke Nojiri2016-05-202-0/+27
| | | | | | | | | | | | | | | This patch adds vb2_sha256_extend, which extends a hash using a given block. BUG=chrome-os-partner:51907 BRANCH=tot TEST=make runtests Change-Id: I512674f18dffc55692907c85b19ff19df88a5eeb Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/346234 Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Tested-by: Daisuke Nojiri <dnojiri@google.com> Reviewed-by: Randall Spangler <rspangler@google.com>
* hmac: Add HMAC to 2lib libraryDaisuke Nojiri2016-05-105-0/+158
| | | | | | | | | | | | | | | This patch adds HMAC. HMAC will be used to sign/verify NVM structures. Hash algorithms can be selected from those supported by enum vb2_hash_algorithm (i.e. SHA1, SHA256, or SHA512). BUG=chrome-os-partner:51907 BRANCH=tot TEST=make runtests Change-Id: I6d349bc807874fe2a5512aabcd7fbf67a4eaa40a Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/342880 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Support doing battery cut-off in firmware stage.Hung-Te Lin2016-04-123-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new crossystem value "battery_cutoff_request" to indicate that next reboot should cut-off battery and shutdown during firmware stage. This request is primarily for factories to ship devices in an safe state. Previously we have done same thing by running "ectool battery-cutoff" but that creates a problem which "ectool" (and the one to request for cut-off) must live in developer mode while the device must be shipped in normal mode. The mode transition was solved by setting "disable_dev_request=1", but that flag is may get lost on x86 systems (having NV storage in CMOS) when the battery is cut-off . From the experience from Ryu, such settings (dev mode transition and battery cut-off) should be done together inside firmware execution so we can create a new flag, battery_cutoff_request, to finalize device properly. BRANCH=none BUG=chromium:601705 TEST=emerge-chell depthcharge vboot_reference chromeos-bootimage crossystem battery_cutoff_request=1 # Unplug AC adapter reboot # See device rebooted and then shutdown immediately. # Press power button and system won't boot. # Attach AC adapter and now system boots. CQ-DEPEND=CL:337596,CL:338193 Change-Id: I73ccae15b337cd65786106646546c67c155b8fa6 Reviewed-on: https://chromium-review.googlesource.com/337602 Commit-Ready: Hung-Te Lin <hungte@chromium.org> Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* vb2: Modify phase2 behavior for S3 resume casestabilize-7978.Bstabilize-7978.74.Bstabilize-7978.66.Bstabilize-7978.51.Bstabilize-7978.18.Bstabilize-7956.Brelease-R50-7978.BDuncan Laurie2016-02-232-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a platform does verification of memory init then it must be careful to use the same slot for resume that it booted from. This is accomplished by adding a context flag to indicate this is an S3 resume and that vboot should treat it differently than a normal boot. When this flag is set then the same slot that was booted is read from VBNV and re-used for the resume path, without adjusting any try flags. If this slot is B then the related context flag is set. This will allow the firmware updater to update the other (non-booted) slot and set flags indicating that on the next boot the updated slot should be tried, while still allowing suspend/resume to work with the existing firmware slot. This assumes that the last tried slot was successfully booted, which should be a safe assumption since the system was able to boot and then suspend. It isn't reliable to check last_fw_result for "success" status because that status is only set some time after boot when chromeos-setgoodkernel calls chromeos-firmwareupdate --mode=bootok and so it may still report a status of "trying" on resume depending on how soon after boot the suspend happened. It also avoids setting the vboot flag indicating that a slot choice was made in order to avoid altering the try counter on failure since this is explicitly not attempting to boot the new slot. BUG=chromium:577269 BRANCH=glados TEST=manually tested on chell: 1) ensure that booting from slot A resumes from slot A. 2) ensure that booting from slot B resumes from slot B. 3) do RW update while booted from slot A (so the flags are set to try slot B) and ensure that suspend/resume still functions properly using current slot A. 4) do RW update while booted from slot B (so the flags are set to try slot A) and ensure that suspend/resume still functions properly using current slot B. Change-Id: I500faef2b5d19a02f32839976354abf6d551c9f6 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/328812 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* vb20: add vb2api_check_hash_get_digest() for retrieving hash resultAaron Durbin2016-01-262-0/+15
| | | | | | | | | | | | | | | | | | | | | | For x86 systems, which resume through the boot reset vector, to implement vboot verification of the memory init code one needs check that the slot chosen on the resume path is the same as the original boot path. That check is done by storing the resulting hash of the slot. However, vb2api doesn't export the resulting hash from vb2api_check_hash(). Thus, provide a variant which saves the resulting digest in the supplied buffer. BUG=chrome-os-partner:46049 BRANCH=glados TEST=Suspended and resumed on chell. Also, tested with an EC build which returns a bad hash to ensure that is properly caught. Change-Id: Ic20be2024afedabc2d8bc767f1b794376348523c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/323460 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* vboot2: Add try RO software sync flagMary Ruthven2016-01-063-1/+11
| | | | | | | | | | | | | | This flag will be used by the firmware updater to indicate that RO software sync should be attempted. BUG=chrome-os-partner:48703 BRANCH=None TEST=make runtests Change-Id: I42090ac47da45c724e66334648ab447ad3c21178 Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/320621 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot: Add GBB flag to turn on serial outputMary Ruthven2015-11-031-0/+3
| | | | | | | | | | | | | | Currently this does nothing. This will eventually be used to enable serial output. BUG=chromium:210230 BRANCH=none TEST=none Change-Id: I5c25fd7406e30b96d12bc4bf8210d3c3f4ae79f1 Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/309716 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Save recovery reason before user three-finger-salutesDaisuke Nojiri2015-10-261-15/+20
| | | | | | | | | | | | | | | | When a user hits esc+refresh+power to start recovery, the true recovery reason will be lost after reboot. (It would always look like VB2_RECOVERY_RO_MANUAL.) This patch makes VbBootRecovery save the reason in the subcode area before entering the new 'broken' loop. BUG=chromium:501060 BRANCH=tot TEST=test_that -b veyron_jerry suite:faft_bios Change-Id: Ib536daa0633721bfc975381782d348f122b3d337 Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/307586 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add NV flag to default boot legacy OSMary Ruthven2015-10-134-1/+34
| | | | | | | | | | | | | | | | 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>
* recovery: Add recovery reason for fastboot mode requested inFurquan Shaikh2015-10-081-0/+3
| | | | | | | | | | | | | | | | | | | | user-mode. BUG=chrome-os-partner:42674 BRANCH=None TEST=Compiles successfully and behavior verified. Change-Id: I67ec056f28596dd0c0005a54e454abe1b4104cfb Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/294276 Trybot-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Commit-Queue: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 6d9a9a9fdd3bcdadbfc4f44640da4c462803a69d) Reviewed-on: https://chromium-review.googlesource.com/304673 Commit-Ready: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot2: tpm error doesn't block gbb dev flagRandall Spangler2015-09-222-32/+63
| | | | | | | | | | | | | | | | | | In recovery mode, the TPM may be bad / corrupt. This prevents access to the soft developer switch stored in secdata. But it should not prevent setting dev mode via GBB or context flags. Those flags may be set during manufacturing or testing, and override the contents of secdata anyway. BUG=chrome-os-partner:45511 BRANCH=ryu TEST=make runtests Change-Id: I242714528203cc7cf78a714c660b7f8bbd0e04d0 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/300621 Commit-Ready: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* vboot2: Support reboot requested by secdataRandall Spangler2015-09-176-3/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* VBOOT2: Add work buffer too small error messageLee Leahy2015-08-271-1/+3
| | | | | | | | | | | | | | | Update VBOOT2 to add work buffer too small error message. BRANCH=none BUG=None TEST=Build and run on kunimitsu Change-Id: Icb4b873e0c350a5667948e106c111356acab6a82 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://chromium-review.googlesource.com/295753 Commit-Ready: Leroy P Leahy <leroy.p.leahy@intel.com> Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* VbNvStorage: Add flags for misc settingsFurquan Shaikh2015-08-013-7/+16
| | | | | | | | | | | | | | | | | | | | 1. Change offset 8 to hold all misc settings (fastboot, boot_on_ac detect) instead of only fastboot settings. 2. Add flag to hold state of boot_on_ac_detect (If set to 1, AP should start booting as soon as AC is connected in off-state). BUG=chrome-os-partner:41680 BRANCH=None TEST=Compiles successfully. make runtests successful. Change-Id: I64b3fc69bd52cbcaf5899c953ccafa2e81b5b8a5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/289900 Trybot-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Furquan Shaikh <furquan@chromium.org>
* futility: Compute / verify root key hashRandall Spangler2015-07-211-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ryu will store a hash of the GBB root key in a struct inside its boot block. Add a vb2_ryu_root_key_hash struct for that. If 'futility gbb_utility' is used to set the root key, also look for a root key hash struct and fill it in. No error if not found, because this needs to work on other platforms where the struct is not present. This way, we don't need to change the signing scripts. Added a --roothash option which can be used to check if the root key hash is found, and if so, whether it's empty, valid, or invalid. BUG=chromium:511405 BRANCH=ryu TEST=manual Take any existing image.bin. cp image.bin image.orig gbb_utility --roothash image.bin - ryu root hash not found Extract the root key gbb_utility -k rootkey.bin image.bin - exported root_key to file: rootkey.bin Now, append a blank ryu root hash struct to it echo '0000000: 5274 4b79 4861 7368 0100 0000 3000 0000' | xxd -r >> image.bin echo '0000000: 0000 0000 0000 0000 0000 0000 0000 0000' | xxd -r >> image.bin echo '0000000: 0000 0000 0000 0000 0000 0000 0000 0000' | xxd -r >> image.bin Nothing is set yet gbb_utility --roothash image.bin - ryu root hash is unset Setting the root key also sets the root hash gbb_utility -s -k rootkey.bin image.bin - import root_key from rootkey.bin: success - calculate ryu root hash: success successfully saved new image to: image.bin See, it verifies gbb_utility --roothash image.bin - ryu root hash verified Now, append a bad ryu root hash struct to it cp image.orig image.bin echo '0000000: 5274 4b79 4861 7368 0100 0000 3000 0000' | xxd -r >> image.bin echo '0000000: 0001 0000 0000 0000 0000 0000 0000 0000' | xxd -r >> image.bin echo '0000000: 0000 0000 0000 0000 0000 0000 0000 0000' | xxd -r >> image.bin See, it fails gbb_utility --roothash image.bin - ryu root hash does not verify Make sure the library doesn't contain the magic string strings `which futility` | grep RtKyHash (should be no output) Change-Id: Ib46f93cac0f2b532bada4b187ae48efcf4926702 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/286237 Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* recovery: Add recovery reason for fastboot mode requested in fwstabilize-7204.BFurquan Shaikh2015-06-231-0/+3
| | | | | | | | | | | | | | BUG=chrome-os-partner:40196 BRANCH=None TEST=Compiles successfully Change-Id: Ic69834f2e23926e618349b5a56db549a290cd0c2 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/280922 Trybot-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Furquan Shaikh <furquan@chromium.org>
* vboot2: Add 2.0 api layer to verify kernel partitionRandall Spangler2015-06-093-2/+146
| | | | | | | | | | | | | | | | | | | This allows the caller to load the kernel partition and then pass it to vboot for verification, rather than having vboot assume the kernel partitions are all on a block storage device. Next up, APIs for the caller to parse partition information from a GPT (yes, that's cgptlib, but we'll make it more easily callable by depthcharge). BUG=chromium:487699 BRANCH=none TEST=make -j runtests Change-Id: I388085c7023f4c76d416f37df0607019bea844ac Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/275646 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* recovery: Add recovery reasons for BCBstabilize-7155.BFurquan Shaikh2015-06-041-0/+6
| | | | | | | | | | | | | | | | | | | BCB is bootloader control block. Add reasons specific to BCB: 1. In case of any error reading/writing BCB (internal FW error) 2. User-mode requested recovery via BCB (user-mode requested) BUG=chrome-os-partner:40960 BRANCH=None TEST=Compiles successfully Change-Id: I0ac362ba7267a08313cb3077be686aa73367e53b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/275222 Trybot-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Furquan Shaikh <furquan@chromium.org>
* vboot2: Add routines to load kernel preambleRandall Spangler2015-06-043-1/+38
| | | | | | | | | | | | | | The kernel data itself will be read and verified by a subsequent change. BUG=chromium:487699 BRANCH=none TEST=make -j runtests Change-Id: Ife4f8250493ec6457f91fda57ae8d4d7bf18ec89 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/274038 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* vboot2: secdata: Check struct_version on initializationstabilize-7134.BJulius Werner2015-06-022-2/+6
| | | | | | | | | | | | | | | | | | This patch reintroduces a vb2_secdata->struct_version check similar to the one that was removed in CL:244846. The CRC is not a reliable way to detect zeroed buffers, so this check helps vboot fail earlier and more clearly in certain situations. BRANCH=kitty,smaug,storm,veyron BUG=chrome-os-partner:40778 TEST=make runtests. Rebooted Jerry with 'mem w 0xff7601b0 0xfdb9', saw that recovery reason was now 0x2b (VBNV_RECOVERY_VB2_SECDATA_INIT). Change-Id: Ic4376d127e6d14d4ef9c2f53c83090040ca4cb68 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/274138 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* fastboot: Add fastboot related flags to vb2Furquan Shaikh2015-05-294-2/+34
| | | | | | | | | | | | | | BUG=chrome-os-partner:40196 BRANCH=None TEST=Compiles successfully. Change-Id: I4305436b2ae46254e4e8b12039ffed95634d62c2 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/273181 Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Furquan Shaikh <furquan@chromium.org> Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
* Provide a way to disable counting failed bootsPatrick Georgi2015-05-282-2/+6
| | | | | | | | | | | | | | | | | | | | | | | When the lid is closed and external power is applied the system may boot and shut down faster than required for the OS to determine that things were alright. In timed charging setups this led to systems ending up to consider the current version broken because it "failed" repeatedly. Remain generic about the reason for not counting boots since there may be more situations in which we want to handle the situation optimistically. BRANCH=none BUG=chromium:446945 TEST=none Change-Id: Iea350e3c98d5c00156da682e52c90a882ba017c0 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/249150 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot2: Add routines to load and verify kernel keyblockRandall Spangler2015-05-224-3/+86
| | | | | | | | | | | | | | These are slightly more complex than the firmware versions, because they need to deal with developer-signed keyblocks and keyblock flags. BUG=chromium:487699 BRANCH=none TEST=make -j runtests Change-Id: I682c14ddfe729984f2629dfbe66750e5cd5ab75e Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/272541 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* vboot2: Add routine to verify kernel preambleRandall Spangler2015-05-211-0/+6
| | | | | | | | | | | | | | | | | This also checks that the bootloader and vmlinuz headers, if present, are within the signed part of the kernel blob; the vboot1 routines didn't do that. That wasn't harmful at firmware boot time because the vboot1 routines would only load as much data as was signed, but in vboot2 loading the kernel data is the responsibility of the caller so we need to check. BUG=chromium:487699 BRANCH=none TEST=make -j runtests Change-Id: I73eb4831e5d3d7a642b6cb85cb55857d87fcc0af Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/270797
* GBB: Add missing flag LID_SHUTDOWN to vb2_gbb_flag structurestabilize-7077.134.Bstabilize-7077.123.Bstabilize-7077.122.Bstabilize-7077.111.Brelease-R44-7077.Bfactory-test-7077.114.Bfactory-arkham-7077.113.BFurquan Shaikh2015-05-161-0/+3
| | | | | | | | | | | | | | BUG=None BRANCH=None TEST=Compiles successfully Change-Id: I80a501efc3940ca5657dc143c0ab3c6b020dc1e0 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/271620 Trybot-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Commit-Queue: Furquan Shaikh <furquan@chromium.org>
* GBB: Add flag for forcing full fastboot capability in firmwareFurquan Shaikh2015-05-161-0/+6
| | | | | | | | | | | | | | | | | This flag is equivalent to FORCE_DEV_BOOT_USB. It allows full fastboot capability in firmware for developer mode. BUG=chrome-os-partner:40196 BRANCH=None TEST=Compiles successfully for smaug. Change-Id: I82a2ebe7a8b3bbf38694ab81ca2678624f77fca1 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/271410 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Furquan Shaikh <furquan@chromium.org> Trybot-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org>
* vboot2: Support VB2_GBB_FLAG_DISABLE_FW_ROLLBACK_CHECKJulius Werner2015-05-161-0/+4
| | | | | | | | | | | | | | | Looks like the DISABLE_FW_ROLLBACK_CHECK GBB flag (0x200) was forgotten in the vboot2 implementation. It's too late for Veyron now, but let's at least fix it for future devices. BRANCH=none BUG=None TEST=make runtests Change-Id: I867f7aada28be3897efda73a6bdc3b0848c23dca Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/271419 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Detect GBB 1.1 also as impcompatible versionDaisuke Nojiri2015-05-141-2/+2
| | | | | | | | | | | | | | | Older GBB headers (e.g. 1.0 and 1.1) do not have hwid_digest. In such cases, PCR1 is currently extended from 0, causing a remote attestation failure. This change makes all GBB headers older than 1.2 incompatible. BUG=none BRANCH=tot TEST=make -j runtests Change-Id: I7a3b19c2da325a3fa4b9c1fe06ed6f43cb51fb9e Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/270796 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* vboot2: Add support for kernel version secure data spaceRandall Spangler2015-05-135-8/+297
| | | | | | | | | | | | | | Holds kernel rollback information. Will be used by vboot 2.0 kernel verification. BUG=chromium:487699 BRANCH=none TEST=make -j runtests Change-Id: Ib4a70e943ebd79aac06404df09cf4ce62d719201 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/270626 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Make SHA library accessible to calling firmwareRandall Spangler2015-05-072-11/+41
| | | | | | | | | | | | | | | | | | | | | | And add a vb2_digest_buffer() call which produces the hash of a buffer all in a single function call. That function actually already existed, but was in a unit test file rather than in the library itself. It's a small function, so adding it won't increase the size of the library significantly - or at all, on platforms which compile with -ffunction-sections. This allows coreboot to reuse this SHA library for hashing CBFS entries and file data. All it has to do is #define NEED_VB2_SHA_LIBRARY and then #include "vb2_api.h". BUG=chromium:482652 BRANCH=none TEST=make -j runtests Change-Id: Ice2d0929324b58b2665f3989b5b887225f6ef61e Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/269523 Reviewed-by: Julius Werner <jwerner@chromium.org>
* Disable dev mode on recovery, when configured.stabilize-6912.Bstabilize-6909.BVadim Bendebury2015-03-232-0/+11
| | | | | | | | | | | | | | | If so desired by the firmware, disable developer mode each time the recovery mode is entered. BRANCH=storm BUG=chrome-os-partner:36059 TEST=with the rest of the patches applied observed desired behavior on an SP5 (developer mode state wiped out on entering recovery) Change-Id: If08dc517363bcc36fcc8b0b875a8700bbcefde4c Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/261630 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot: allow firmware to signal a wipeout requestVadim Bendebury2015-03-135-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* vb21: Rename struct vb2_guid to struct vb2_idBill Richardson2015-03-107-44/+44
| | | | | | | | | | | | | | Since the ID structure isn't a true GUID anymore, let's call it something else. BUG=none BRANCH=none TEST=make runtests Change-Id: I96f511bd5587a94d2cc20764e26d7ef0096de04c Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/256182 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vb21: Replace the key GUID with a sha1sum insteadBill Richardson2015-03-101-24/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want a quick and human-friendly way to match keys with signatures, so we decided to give each key a unique GUID and carry that ID around when signing things. But then we realized that we could autogenerate a unique identifier from the .pem file itself, which is even better because then we can match our binary keypair structs with the openssl file used to generate them. This change replaces the GUID id with a sha1sum calculated from the public key's "keyb" blob. BUG=none BRANCH=none TEST=make runtests Also: futility show tests/testkeys/key_rsa4096.pem futility create tests/testkeys/key_rsa4096.pem foo futility show foo.vbp* Note that the GUID is the same for all files. Change-Id: Ie44e46c83433718b1ff0163c1e7c51ec331b99f9 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/256181 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cleanup: Fix some typos in commentsBill Richardson2015-03-106-11/+11
| | | | | | | | | | | | | | 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-102-2/+8
| | | | | | | | | | | | | | | | | | | | 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>
* vboot2: Add more precise recovery reasons to firmware verificationstabilize-6783.BJulius Werner2015-02-121-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vboot1 kept track of an internal "LoadFirmware() check" value for both firmware slots and encoded the value for the slot that managed to go further in the verification flow into a special range of recovery reasons. vboot2 instead uses the generic "invalid RW" reason for all firmware verification failures and communicates further information through the subcode. While the subcode may be good enough for developers, it's difficult to communicate failure reasons to "normal" users (like non-firmware developers) on the TAB screen. Currently we just display a couple of numbers that people won't know how to interpret and "RW firmware failed signature check" for any verification error (including rollback, which might be the most commonly encountered in practice). Since our recovery reason space is big enough (and we don't reuse old numbers anyway), we might as well reuse the more precise numbers (and strings) from vboot1 to communicate the failure reason, even if we don't implement its "which slot came further" algorithm. This patch translates the most common/useful VBSD_LF_CHECK numbers into plain VB2_RECOVERY reasons and uses them where appropriate. CQ-DEPEND=CL:248400 BRANCH=veyron BUG=None TEST=make runtests VBOOT2=1 test_that my_jerry firmware_CorruptBothFwSigAB firmware_CorruptBothFwBodyAB firmware_RollbackFirmware (Confirmed that matched recovery reasons are the more precise ones in the 0x10-0x1F range.) Change-Id: I51ecf1b820d1faa40405cb84377380d6f3f6ca1d Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/248392 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* vboot2: Fail vb2_secdata_(get|set) when secdata was not initializedJulius Werner2015-02-042-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a check to vboot2 secdata accessor functions that returns an error if vb2_secdata_init() has not yet been called or failed for some reason. This avoids a problem where vboot may misinterpret random garbage (e.g. from transient read failures) as valid secdata in recovery mode and write it back to the TPM (bricking the device in a way that requires manual repair). Also removes VB2_ERROR_SECDATA_VERSION check. This check was not terribly useful since there should be no way a vboot2 device could ever have secdata version 1 (and if it did, it should still fail CRC checks). This error can trigger for cases when secdata contains random garbage (e.g. all zeroes) and prevent the much more appropriate VB2_ERROR_SECDATA_CRC error from even being checked for, which just creates confusion and makes it harder to determine the real problem. BRANCH=veyron BUG=chrome-os-partner:34871 TEST=Emulated TPM read errors by just manually memset()ing secdata to 0 in coreboot, verified that vboot does not write back to the TPM and the device will start working fine again once the disruption is removed. Change-Id: I76bcbdbcd8106a0d34717cc91a8f2d7cda303c3f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/244846
* vboot2: Add sd->fw_version_secdata field to communicate to crossystemJulius Werner2015-01-312-0/+9
| | | | | | | | | | | | | | | | | | | This patchs adds a new vb2_shared_data field to store the current rollback prevention version number stored in secdata (TPM). This information needs to be retrieved from there by coreboot (current hack) or vboot2 kernel verification (bright shiny future) so it can be passed along to the operating system and user space. BRANCH=veyron BUG=chrome-os-partner:35941 TEST=make runtests. Booted Jerry in recovery mode (with corresponding coreboot patch), ensured that crossystem tpm_fwver still shows the correct value. Change-Id: I2a0c3e51b158a35ac129d2abce19b40c6c6381a6 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/244601 Reviewed-by: Randall Spangler <rspangler@chromium.org>
View Lorry Controller Status