summaryrefslogtreecommitdiff
path: root/firmware/lib/vboot_api_kernel.c
Commit message (Collapse)AuthorAgeFilesLines
* firmware: Remove VbLockDevice()stabilize-10452.96.Bstabilize-10452.90.Bstabilize-10452.85.Bstabilize-10452.81.Brelease-R66-10452.BRandall Spangler2018-03-011-15/+0
| | | | | | | | | | | | | | | | | VbLockDevice() would be inconvenient to port to 64-byte NV storage records because it doesn't take VbSharedData flags or a vb2_context. So, just have depthcharge call vbnv_write() directly (as it does in other places in fastboot.c) and get rid of this API. BUG=chromium:789276 BRANCH=none TEST=make runtests CQ-DEPEND=CL:944183 Change-Id: I2aeaecf7f929cd1a1ebd1f6850d0dd96c6fabb49 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/944243 Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* firmware: Stop using vboot1 cparams internallyRandall Spangler2018-01-091-23/+13
| | | | | | | | | | | | | | | | | | Now that vb2_shared_data / vb2_context provides all the same data to lower-level kernel verification code that cparams did, stop passing cparams down to those functions. No change in functionality. BUG=chromium:611535 BRANCH=none TEST=make -j runtests; build bob firmware and boot it Change-Id: I86eb1801ee96d8b56404b74843a8d09e3122567f Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/852814 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* firmware: Prune down old region APIRandall Spangler2018-01-091-19/+5
| | | | | | | | | | | | | | | | | | | | | | | | The region API was a way for firmware and kernel verification to get at various blocks of caller-provided data. In practice, we only used it internally as a way to get at parts of the GBB. Prune it down to access only the bits of GBB we still need, from the buffer we already know we have. In the long run we should use the same vb2ex_read_resource() API that vb2 firmware verification does, but that should be done in a follow-up CL since it'll need to be coordinated with support in depthcharge. No change in functionality. BUG=chromium:611535 BRANCH=none TEST=make -j runtests; build bob firmware and boot it Change-Id: I5715cb8d88274164a1a73ed4a56bbd93af46f9bf Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/852798 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* firmware: Include vb1 shared data in vb2 structRandall Spangler2018-01-091-26/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, firmware verification uses entirely vb2 structs, including vb2_shared_data. This goes through an ugly translation to the old vb1 VbSharedData to pass it to depthcharge. The vboot kernel verification maintains an equally ugly translation back to the vb2 struct internally. Eventually, we want to get rid of all that and use vb2 all the way down to what crossystem picks up from the OS. But before we can do that, we need to finish translating kernel verification code to use the new vb2 structs. This is a step on that path, using vb2_shared_data equivalents where present and hiding the old vb1 shared data struct as a member of vb2_shared_data so at least the vboot functions don't need to pass around cparams to get at it. This will be followed by more CLs which convert more vboot internals to use vb2 structs directly, and eventually coreboot/depthcharge CLs which pass the vb2 structs from firmware verification directly to kernel verification. No change in functionality. BUG=chromium:611535 BRANCH=none TEST=make -j runtests; build bob firmware and boot it Change-Id: I5df8ce81ba3c3ac3f2cb4229db5461757cd89d8d Reviewed-on: https://chromium-review.googlesource.com/852856 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* firmware: Remove bmpblk codeRandall Spangler2018-01-091-5/+0
| | | | | | | | | | | | | | | | | | | | All screens are now drawn by depthcharge. ToT firmware does not include a bmpblk / bmpfv section in the GBB. Remove the code paths which are no longer used. Also drop a few cparams parameters from functions that no longer use it, now that those functions don't need to access the GBB. BUG=chromium:502066 BRANCH=none TEST=make -j runtests; build bob firmware and check recovery screens Change-Id: I4d2d0a3ba57c34151e65c6f42581df823192a4ae Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/852371 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* ec_sync: Use vboot2 context instead of cparamsRandall Spangler2018-01-091-0/+17
| | | | | | | | | | | | | | | | | | | Copy sync-related flags from cparams / vboot1 shared data to the equivalent vboot2 structs. This removes the need for ec_sync to access the old structs, which are on their way out. No change in functionality. BUG=chromium:611535 BRANCH=none TEST=make -j runtests; build bob firmware and boot it Change-Id: I50ee76cf275a7fba894c2ec2c3dd83b9a8d91b53 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/852489 Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* firmware: use sd->gbb_flagsRandall Spangler2018-01-051-3/+6
| | | | | | | | | | | | | | | | | | Vboot1 code directly referenced the GBB from cparams even though now it has access to the GBB flags via the vb2 context. Refactor all existing code to use the vb2 context, since that takes us one step closer to getting rid of the old vboot1 cparams. No change in functionality. BUG=chromium:611535 BRANCH=none TEST=make -j runtests; build bob firmware and boot it Change-Id: Ic4a5bf215b723a2eacbf0a4cf0eba8b1338155a2 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/847310 Reviewed-by: Shelley Chen <shchen@chromium.org>
* vboot: Use 2nvstorage instead of vboot_nvstorageRandall Spangler2017-12-111-85/+46
| | | | | | | | | | | | | | | | | | Remove the old vboot1 vboot_nvstorage library (VbNv*() functions) and use the vboot2 library (vb2_nv_*()) instead. This is needed in preparation for moving to 64-byte records; no sense in implementing that change twice... Should be (better be) no change in system behavior. BUG=chromium:789276 BRANCH=none TEST=make runtests compare output of crossystem before/after change (should be identical) Change-Id: I10f9975b0824263064b9a74a3c6daadcecc085d3 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/794732
* vboot: Use kernel max rollforward NV storage fieldRandall Spangler2017-11-171-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Kernel verification will now roll forward the minimum allowable version in the TPM no farther than the kernel_max_rollforward setting. Note that CL:765573 changes chromeos-setgoodkernel so it always sets kernel_max_rollforward to 0xfffffffe when marking a kernel as good. That ensures that firmware with this setting will behave the same for now as existing firmware. BUG=chromium:783997 BRANCH=none CQ-DEPEND=CL:765573 TEST=make runtests Manual testing: crossystem tpm_kernvel --> print current kernel version in TPM - Resign the kernel with a higher version - Reboot - Wait a minute for chromeos-setgoodkernel to run crossystem kernel_max_rollforward=0 - Reboot crossystem tpm_kernvel --> has not changed - Wait a minute for chromeos-setgoodkernel to run crossystem kernel_max_rollforward -> 0xfffffffe - Reboot crossystem tpm_kernvel --> has changed to the higher version Change-Id: Ia32ecb7fa4078548cd311541ccbe120570cf1bc5 Reviewed-on: https://chromium-review.googlesource.com/765574 Commit-Ready: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@google.com>
* vboot: use VBNV_ constants with VbNvGet()Randall Spangler2017-11-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The vboot1 library VbNvGet() / VbNvSet() functions use enum VbNvParam (VBNV_*) constants. The vboot2 library vb2_nv_get() / vb2_nv_set() functions use enum vb2_nv_param constants. Do not mix the two. In the one instance where this happens in the current code, we get lucky, because VBNV_DEV_BOOT_FASTBOOT_FULL_CAP and VB2_NV_DEV_BOOT_FASTBOOT_FULL_CAP evaluate to the same value, so this was harmless. But fix that now so nobody else copy/pastes that pattern for a param where this isn't true. BUG=none BRANCH=none TEST=make runtests Change-Id: I1facbe1d97591dc8b1e6b38717924b884949da57 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/764970 Reviewed-by: Julius Werner <jwerner@chromium.org>
* Check EC_IN_RW before proceeding to recovery modeDaisuke Nojiri2017-10-051-12/+14
| | | | | | | | | | | | | | | | | | | | | | Depthcharge currently asks EC whether recovery was requested manually or not without verifying EC is in RO or not. If EC-RW is compromised, recovery switch state can be spoofed. This patch makes Depthcharge check EC_IN_RW to determine whether EC is in RO or not. Only if it's in RO and it says recovery button was pressed at boot, we proceed to the recovery process. All other recovery requests including manual recovery requested by a (compromised) host will end up with 'broken' screen. BUG=b:66516882 BRANCH=none TEST=Boot Fizz. make runtests. Change-Id: I01d2df05fe22e79bbc949f5cb83db605147667b3 Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/693008 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* 2lib: add VB2_DEBUG_RAW() to print without function nameRandall Spangler2017-01-201-12/+9
| | | | | | | | | | | | | | | | | | | | | | | | Currently, VB2_DEBUG() will print the function name as a prefix to the debug output. Add VB2_DEBUG_RAW() to print without that, so that it's possible to print little bits of debug output. Use this in ec_sync to hex dump the hashes. And then clean up all of the debug calls which explicitly did things like: VB2_DEBUG("%s: foo", __func__); to just: VB2_DEBUG("foo"); so they don't double-print the function name BUG=chromium:683391 BRANCH=none TEST=build_packages --board=reef chromeos-firmware && DEBUG=1 make -j runtests CQ-DEPEND=CL:430978,CL:431111 Change-Id: I0c35519d2e670d55d65d01eaa60d61f3e3edf419 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/431171 Reviewed-by: Julius Werner <jwerner@chromium.org>
* firmware: calling menu ui when using detachablesstabilize-fsi-9202.5.0.Bstabilize-fsi-9202.10.Bstabilize-M57-9202.35.0.Bstabilize-9202.Bstabilize-9202.64.Bstabilize-9202.56.Bstabilize-9202.28.Bstabilize-9202.18.Bstabilize-9199.Brelease-R57-9202.BShelley Chen2017-01-181-2/+8
| | | | | | | | | | | | BUG=chrome-os-partner:61275 BRANCH=None TEST=compile depthcharge with inflags=VB_SALK_INFLAGS_ENABLE_DETACHABLE_UI and run. Change-Id: I4c2351feef51bbf88fefd37986de6f853cd1942e Signed-off-by: Shelley Chen <shchen@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/424091 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* firmware: replace VBDEBUG(()) macro with VB2_DEBUG()Randall Spangler2017-01-121-30/+30
| | | | | | | | | | | | | | | | The original VBDEBUG macro used doubly-nested parens to work with MSVC, which didn't support varargs in macros. We now only use more modern compilers, so replace it with the VB2_DEBUG macro and get rid of the ugly and fragile double parens. BUG=chromium:611535 BRANCH=none TEST=make runtests; build_packages --board=reef chromeos-firmware Change-Id: Ifc0cb0733b14daaa1fde095fab7da4215a538c77 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/425133 Reviewed-by: Shelley Chen <shchen@chromium.org>
* firmware: Split out kernel UIRandall Spangler2017-01-121-547/+14
| | | | | | | | | | | | | | | This moves the UI loops out of vboot_api_kernel.c into vboot_ui.c, so that it'll be easier to support different UIs for different form factors. BUG=chromium:611535 BRANCH=none TEST=make runtests; build_packages --board=reef chromeos-firmware; boot reef Change-Id: I451b15f65aceb427ffdd94b19f44e91ebc10a860 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/414289 Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-by: Shelley Chen <shchen@chromium.org>
* firmware: Remove LoadKernelParams from APIsRandall Spangler2017-01-121-192/+180
| | | | | | | | | | | | | | This cleans up the vboot functions which handle display so they don't need to pass it around. Eventually, it'll be absorbed by vb2_context. BUG=chromium:611535 BRANCH=none TEST=make runtests; build_packages --board=reef chromeos-firmware; boot reef Change-Id: I58169dfd37abe657f9b9aa339cc72ffa398329e0 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/414288 Reviewed-by: Shelley Chen <shchen@chromium.org>
* firmware: Refactor and clean up ec_syncChromeOS Developer2017-01-121-28/+7
| | | | | | | | | | | | | | | | | | | | Previously, the EC software sync process called VbDisplayScreen() from several function calls deep. Refactor software sync so that the UI decisions are at a higher level (in ec_sync_all.c) and isolated from the low-level EC software sync functionality (in ec_sync.c). This is one in a series of changes which are more clearly separating out the UI, to make it easier to support multiple UI across a range of devices. BUG=chromium:611535 BRANCH=none TEST=make runtests; build_packages --board=reef chromeos-firmware; boot reef Change-Id: I40597abeb5b0cc8f5d8fc2098e4acbed4bf59bf6 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/411921 Reviewed-by: Shelley Chen <shchen@chromium.org>
* vboot: Pass vb2 context and use vboot2 NV routinesRandall Spangler2016-12-221-118/+161
| | | | | | | | | | | | | | | Passing the vb2 context around allows using more of the vb2 functions in future changes, and prepares for a future where we directly use the context as it was set up in firmware verification. BUG=chromium:611535 BRANCH=none TEST=make runtests; emerge-kevin coreboot depthcharge Change-Id: I8efa606dbdec5d195b66eb899e76fdc84337ad36 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/404997 Reviewed-by: Shelley Chen <shchen@chromium.org>
* vboot: Split ec software sync to its own fileRandall Spangler2016-12-201-369/+11
| | | | | | | | | | | | | | | | This was previously done inside vboot_api_kernel. But it has nothing to do with kernel verification; that's just the only place where we could easily put it given that vboot (currently) owns the firmware UI. No outwardly-visible functionality changes. BUG=chromium:611535 BRANCH=none TEST=make runtests; emerge-kevin coreboot depthcharge Change-Id: I8a434eb4449a5a86b129ecac61ad81d0ad55549c Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/404920
* vboot: Split partition and vblock verification from LoadKernel()stabilize-8992.BRandall Spangler2016-11-141-4/+2
| | | | | | | | | | | | | | | | | | | LoadKernel() was a big function which did everything from looping over partitions on a drive to loading the data within them to calling the low-level verification functions on that data. Split it apart into more manageable chunks. This also reduces indentation of the inner parts of the code, whic increases readability. No outwardly-visible functionality changes. BUG=chromium:611535 BRANCH=none TEST=make runtests; emerge-kevin coreboot depthcharge Change-Id: Iea79e70163f5d9f1a9d0d897e4a9bacc925a742d Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/404919 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* recovery: Add new recovery reason to train memory and rebootFurquan Shaikh2016-11-081-4/+9
| | | | | | | | | | | | | | | | | 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-9/+4
| | | | | | | | | | | | | | | | | 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 malloc and free directlyRandall Spangler2016-11-061-7/+7
| | | | | | | | | | | | | | | | Originally, vboot1 code used VbExMalloc() and VbExFree() since it needed to talk to EFI firmware that didn't have standard malloc() and free(). Now, coreboot and depthcharge implement them as wrappers around those standard calls. vboot2 code already calls them directly, so let vboot1 code do that too. BUG=chromium:611535 BRANCH=none TEST=make runtests; emerge-kevin coreboot depthcharge Change-Id: I49ad0e32e38d278dc3589bfaf494bcf0e4b0a4bd Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/400905
* vboot2: Allocate more buffer for kernel verificationRandall Spangler2016-11-061-4/+2
| | | | | | | | | | | | | | | | | | | | | | The low-level verification functions' *_WORKBUF_BYTES constants assume the work buffer is already aligned to VB2_WORKBUF_ALIGN. But malloc() may return a less-aligned pointer, in which case vb2_workbuf_init() aligns it (and loses a bit of space in the process). This can cause an error "vb2_rsa_verify_digest: ERROR - vboot2 work buffer too small!". High-level functions should be using the *_WORKBUF_RECOMMENDED_SIZE constants for allocation, which have enough padding to compensate for alignment problems. BUG=chrome-os-partner:59306 BRANCH=none TEST=make runtests; boot a recovery image on reef Change-Id: I1055fa56072b3fe1cd07c5c090293635c42c77a2 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/406526 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* vboot: use vb2 verification functions for kernel verificationRandall Spangler2016-10-291-15/+54
| | | | | | | | | | | | | 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>
* vboot: use vb2_safe_memcmp instead of SafeMemcmpRandall Spangler2016-10-291-2/+4
| | | | | | | | | | | | | No need to have two implementations of this now. BUG=chromium:611535 BRANCH=none TEST=make runtests; emerge-kevin coreboot depthcharge Change-Id: I18bac928eb09971c37f3e1d7cbfd2009999b1f31 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/400899 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* vboot: use standard memcmp, memcpy, memsetRandall Spangler2016-10-231-5/+5
| | | | | | | | | | | | | | Originally, we didn't trust the firmware to provide these functions from a standard library. Now, with coreboot, we do. BUG=chromium:611535 BRANCH=none TEST=make runtests; emerge-kevin coreboot depthcharge Change-Id: I4e624c40085f2b665275a38624340b2f6aabcf11 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/399120 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* Fix coverity warnings in firmwareRandall Spangler2016-09-061-16/+17
| | | | | | | | | | | | | | 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: I84182df0d0e222f4f60206c621ec62e1ee283adb Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/380697 Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* vboot_api_kernel: Remove assumptions about EC-RW hash type and sizeJulius Werner2016-05-311-156/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | With newer PD chips and different update mechanisms, we can no longer guarantee that the "hash" (really just a sort of version identifier) of an EC-RW image will always be a SHA256. This patch removes any hardcoded assumptions about that from vboot, and instead accepts any hash size returned by VbExEcHashImage() and VbExEcGetExpectedImageHash(). It also removes the assumption that the hash can be regenerated by running SHA256 over the full image returned by VbExEcGetExpectedImage(). We can thus no longer support VBERROR_EC_GET_EXPECTED_HASH_FROM_IMAGE, which is fine since that functionality hasn't been needed for years and there would be no reason why we might need it in the future. This also allows simplifying the code flow of EcUpdateImage() a bit (since you can really just return very early if you already figured out that you don't need to update). BRANCH=None BUG=chrome-os-partner:53780 TEST=Tested software sync on Oak both after cold and warm boot. Change-Id: I498f3d39085a38740734fff9f2d1a186a0801489 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/348001 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot: Add firmware management parametersRandall Spangler2016-05-081-1/+70
| | | | | | | | | | | | | | | | This adds RW firmware support for the optional firmware management parameters TPM space. System-level tests require CL:339262 to add cryptohome support. BUG=chromium:601492 BRANCH=baytrail and newer platforms TEST=make -j runtests Or better, COV=1 make, and then make sure all new code is covered. Change-Id: Ifaf644c80809552d5961615be6017c2a332a034b Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/339234
* Support doing battery cut-off in firmware stage.Hung-Te Lin2016-04-121-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* vboot: Disable VBNV_OPROM_NEEDED after successful updateDuncan Laurie2016-01-201-0/+1
| | | | | | | | | | | | | | | | | | | | The VBOOT_OPROM_NEEDED flag is used for EC software sync when the VBSD_EC_SLOW_UPDATE flag is set. After a successful EC software sync vboot requests a reboot to disable graphics but it is not clearing the VBNV flag first. With vboot1 this was getting cleared as a side effect of calling VbInit in normal mode. BUG=chrome-os-partner:49560 BRANCH=glados TEST=Enable EC_SLOW_UPDATE on chell and test EC software sync in normal mode and ensure that it reboots and does not do graphics init if the update is successful. Change-Id: I2aa0c4c3b1ad357a5b8ddc14539e264a1f5b76b2 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/322731 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* Modify EC software sync to update RO if necessarystabilize-7834.66.Bstabilize-7821.Brelease-R49-7834.BMary Ruthven2016-01-101-157/+243
| | | | | | | | | | | | | | | | | | | | | | Allow the AP to sync and verify the EC read only image after updating the rewritable image. BUG=chrome-os-partner:48703 BRANCH=none TEST=manual 1. Update EC to a new version 2. rebuild EC code 3. Update AP firmware 4. Reboot and check that the RO image is updated after the RW image is updated. CQ-DEPEND=CL:319213 Change-Id: I774ef25320103f20d8c7d1c180a220dd0819c04d Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/320614 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot: Change VbExEc implementations to support RO updateMary Ruthven2016-01-061-19/+18
| | | | | | | | | | | | | | | | | This change will be used to support EC-RO software sync by allowing for access to the readonly region of firmware. Currently only the writable section is accessed by vboot using VB_SELECT_FIRMWARE_A and B. BUG=chrome-os-partner:48703 BRANCH=none TEST=built on jerry and check that the RO hash can be read and the image can be updated. CQ-DEPEND=CL:319185,CL:320425,CL:320598 Change-Id: Ic3942d86b65da3123798cfd11a78056f5dab6699 Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/319213 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot_api_kernel: Add new EcVbootDone APIShawn Nematbakhsh2015-10-291-0/+5
| | | | | | | | | | | | | | | | | | | Add a new post-EC software sync API VbExEcVbootDone() to take actions which normally need to happen after EC verification / sysjump. BUG=chromium:537269 TEST=Manual on Glados. Set CHG_MW thresh to 20000, BAT_PCT to 50. Verify that LIMIT_POWER host event is set until Zinger negotiates to 20V. Also verify that we do not proceed with boot when Donette is plugged. BRANCH=None CQ-DEPEND=CL:307885,CL:309523 Change-Id: I77e6000aa8a44e3aca4fb5982e5b5f5191774989 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/307952 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* VbVerifyMemoryBootImage: Allow integrity-only check in dev mode withFurquan Shaikh2015-10-281-3/+15
| | | | | | | | | | | | | | | | | | | FASTBOOT_FULL_CAP set This change allows developers to boot dev-signed boot images in unlocked mode if DEV_BOOT_FASTBOOT_FULL_CAP is set in VbNvStorage or GBB_FLAG_FORCE_DEV_BOOT_FASTBOOT_FULL_CAP is set. BUG=chrome-os-partner:47002 BRANCH=None TEST=Compiles successfully. make -j runtests Change-Id: I56e3879594da1b57051dfe242ff347ac970c96bb Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/309606 Commit-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* Save recovery reason before user three-finger-salutesDaisuke Nojiri2015-10-261-7/+28
| | | | | | | | | | | | | | | | 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-131-20/+50
| | | | | | | | | | | | | | | | 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>
* Add broken screenDaisuke Nojiri2015-10-121-49/+10
| | | | | | | | | | | | | | | | | In the new recovery process, a user will see 'broken' screen instead of 'remove' screen, where usb stick presence is no longer detected. A user instead has to hit esc+refresh+power to proceed to recovery mode. BUG=chromium:501060 BRANCH=tot TEST=make runtests Change-Id: Icd511c1ca892628b96befbb0a34c2c84b881c857 Reviewed-on: https://chromium-review.googlesource.com/304404 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot_reference: fix unittest when building with clang.Yunlian Jiang2015-06-111-1/+2
| | | | | | | | | | | | | | | | | | | | When linking vboot_api_kernel4_tests, there are two VbBootNormal() available, the gcc chooses the one in vboot_api_kernel4_tests.c and the test passes, the clang chooses the one in vboot_api_kernel.c and make the unittest fail. This CL makes the one in vboot_api_kernel.c a weak symbol so that clang can choose the one in vboot_api_kernel4_tests.c BUG=chromium:498469 BRANCH=none TEST=CC=x86_64-cros-linux-gnu-clang FEATURES='test' emerge-amd64-generic vboot_reference Change-Id: Ibcb78ee055fc9485dbc2bcc1d1cf98144a1a3b64 Reviewed-on: https://chromium-review.googlesource.com/276504 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Yunlian Jiang <yunlian@chromium.org> Tested-by: Yunlian Jiang <yunlian@chromium.org>
* vboot_api_kernel: Do not pre-populate variables inFurquan Shaikh2015-06-021-4/+3
| | | | | | | | | | | | | | | | | | | | VbVerifyMemoryBootImage Do not use values from the header or preamble until it is known to be good. BUG=None BRANCH=None TEST=Compiles successfully and VbVerifyMemoryBootImage returns early for images with bad values in header. Change-Id: Ic026f49292a139e0a04c2556ca9fa62ff277b18f Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/274141 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>
* fastboot: Add routines for unlock and lock devicestabilize-7131.BFurquan Shaikh2015-05-291-0/+31
| | | | | | | | | | | | | | | | | | | | | | | Add support for functions to request unlock and lock of devices in response to fastboot oem unlock/lock commands. Unlock operation is equivalent to enabling dev mode and lock operation is equivalent to leaving dev mode. It is the responsibility of the caller to ensure that user confirmation is obtained before unlock/lock operations. BUG=chrome-os-partner:40196 BRANCH=None TEST=Compiles successfully and fastboot lock/unlock operations work as expected on smaug. Added tests to ensure lock/unlock operations are covered. Verified using make -j runtests. Change-Id: Ibafe75abdd1202473009208a414f3996d537db4f Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/273182 Reviewed-by: 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> Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
* fastboot: Add routine for verifying kernel image loaded in memoryFurquan Shaikh2015-05-271-0/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | This API allows fastboot boot from memory command to verify that the image loaded in memory is signed properly using recovery keys. Thus, only officially signed recovery images can be booted using fastboot boot command in recovery mode. However, if GBB_FLAG_FORCE_DEV_BOOT_FASTBOOT_FULL_CAP is set, then this routine will not perform any check and return okay for any image sent by fastboot boot. BUG=chrome-os-partner:40196 BRANCH=None TEST=Compiles successfully. With GBB override for FASTBOOT_FULL_CAP set any signed image is allowed to boot. With FASTBOOT_FULL_CAP not set, then only officially signed image is allowed to boot. (make -j runtests successful) Change-Id: I78028853bd1ad09d3c610a687f327560557d5681 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/272696 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>
* vboot1: Condition default legacy boot on dev_boot_legacystabilize-7060.Bstabilize-7059.BJulius Werner2015-05-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes what I think is an inconsistency in the existing legacy boot behavior: when the GBB flag that defaults to legacy boot is set, running out the 30 second timer would still boot legacy mode even if dev_boot_legacy is not actually set (whereas pressing CTRL+L in the same configuration would beep and refuse). This patch makes both legacy boot trgiggers check the same condition before boot. This does not restrict functionality since anyone who sets the DEFAULT_DEV_BOOT_LEGACY GBB flag could simply set FORCE_DEV_BOOT_LEGACY at the same time. It does however open up an interesting new use case of using NVRAM to change back-and-forth between legacy and normal developer mode (after GBB flags are changed once and write-protection is enabled again). If this is updated in the field it might lock existing devices out of legacy mode... however, since by far the most common GBB flag combination recommended on the internet seems to be 0x489 (including FORCE_DEV_BOOT_LEGACY), I doubt this would be a problem in practice. BRANCH=tbd BUG=chrome-os-partner:39999 TEST=Booted with GBB flags 0x4b9 and 0x439, observed difference. Change-Id: If6a6d99ab2cf116db2237fdc3df97fc22a68251c Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/270182 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* vboot1: Lock TPM physical presence (kernel rollback) on legacy bootJulius Werner2015-05-121-19/+17
| | | | | | | | | | | | | | | | | | | Even though legacy boot is an unsafe mode that has to be manually initiated by the user, we should still lock the kernel TPM space to be consistent with existing developer mode practice. BRANCH=tbd BUG=chrome-os-partner:39999 TEST=Spent over an hour unsuccessfully trying to get SeaBIOS to boot a Chromium test image on my Falco. Decided that's not worth it an just tested the firmware side of this (pressing CTRL+L when legacy mode is enabled and disabled, multiple times, with and without GBB flag DEFAULT_DEV_BOOT_LEGACY). Change-Id: I3b02b59a9055431d222c0c7446de2cd7d2e0bb82 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/270181 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* enable USB boot on transition to dev on some devicesVadim Bendebury2015-04-071-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some Chrome OS devices do not allow to login even in developer mode, as they do not have display/keyboard and sshd is not part of the Chrome OS image. Even enabling developer mode on those devices is very involved (requires taking the device apart and is guaranteed to take long time). We still want to allow the end user to control those devices in dev mode. The solution is enabling the ability to boot from the USB stick when the device transitions from normal to developer mode. A simple way to do it is to set the NVRAM flag, which allows USB boot. The flag is set on normal=>dev transition only, and only on those devices where it is configured (as discovered by invoking VbExGetSwitches with the appropriate parameters). BRANCH=storm BUG=chrome-os-partner:38303 TEST=tested with the corresponding depthcharge patches Change-Id: I5fa58963256598cde3b534f5250101fba6042f8c Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/264187 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* kernel flags: Pass back kernel premable flags in kparamsFurquan Shaikh2015-02-121-0/+2
| | | | | | | | | | | | | | | | | | Kernel preamble flags are set by the signer for passing hints about the image. Read these flags from the preamble and pass it back to the caller in kparams structure. BUG=chrome-os-partner:35861 BRANCH=None TEST=Compiles and boots to kernel prompt for both CrOS image and bootimg. Change-Id: I07a8b974dcf3ab5cd93d26a752c989d268c8da99 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/245951 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Furquan Shaikh <furquan@chromium.org>
* nand: Allow smaller disks for booting a kernelfactory-samus-6658.BDan Ehrenberg2015-01-061-1/+1
| | | | | | | | | | | | | | | | | | When vboot eliminates trivially small disks, it checks the GPT size for external GPT disks. For upcoming NAND devices, the GPT size is 8kB. This patch changes the definition of trivially small disks to be those under 8kB so that NAND can be booted from. BUG=chromium:433433 TEST=make runalltests TEST=Booted and saw a kernel from NAND selected on from an 8kB GPT. BRANCH=none Change-Id: I5047b9b642d564d5e4d77dd0b6dafb9eea09176a Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/238463 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot: Handle GBB_FLAG_DISABLE_LID_SHUTDOWNstabilize-6592.BShawn Nematbakhsh2014-12-171-4/+21
| | | | | | | | | | | | | | | | Handle GBB_FLAG_DISABLE_LID_SHUTDOWN to disable lid-triggered system shutdown. BUG=chromium:434462 BRANCH=Auron TEST=Manual on Auron, with corresponding depthcharge change. Set GBB flag 0x1000 and disable powerd launch on boot. Close lid and issue 'reboot' command over ssh. Verify system reboots successfully into OS. Change-Id: Id2731508296a5ba9229f969f8224565d64f3d4a3 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/234995 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot: Plumb the two disk sizes and external GPT param throughDan Ehrenberg2014-12-151-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
View Lorry Controller Status