summaryrefslogtreecommitdiff
path: root/firmware/lib/vboot_api_kernel.c
Commit message (Collapse)AuthorAgeFilesLines
...
* 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>
* 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-4/+2
| | | | | | | | | | | | | | | | | | | | 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-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* vboot: Support SLOW_EC_UPDATE with OPROM_MATTERSDuncan Laurie2014-10-171-6/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to display the slow EC update screen on x86 devices in normal mode it is necessary to request a reboot where the VGA Option ROM is loaded. This needs a bit of plumbing to pass the OPROM_MATTERS and OPROM_LOADED flags into shared data so they can be consumed in the VbEcSoftwareSync() function. It also needs the VbInit() function to not immediately request a reboot if the VGA Option ROM was loaded in normal mode and the SLOW_EC flag is set as it will still need to be used during software sync. A FIXME in VbEcSoftwareSync() is implemented and the comment is removed, and two extra checks are done. First, if rebooting to RO then also check if the VGA Option ROM is needed to save an extra reboot, and second when exiting the software sync function request a reboot without the VGA Option ROM if it was done in normal mode and the option rom was needed+loaded. The request for a reboot from VbEcSoftwareSync() is saved when doing EC update in case there is an (optional) PD software sync that may also need to display the screen. BUG=chrome-os-partner:12257,chrome-os-partner:32379 BRANCH=samus TEST=all tests pass, manual testing: 1) in normal mode, with EC/PD in RW, ensure that they are rebooted to RO and the VGA Option ROM is loaded and the wait screen is displayed, and then the system is rebooted at the end and the VGA Option ROM is not loaded. 2) same as #1 with EC/PD in RO already, same result 3) same as #1 with system in developer mode, same result except there is no reboot at the end of software sync 4) same as #1 with system in developer mode and EC/PD in RO, ensure that there is no extra reboot at the beginning or end of software sync. Change-Id: Id592181efd640f4cd37a986cd1dcc29f3ca45104 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223718 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot: Notify EC of current boot modeSheng-Liang Song2014-09-031-0/+3
| | | | | | | | | | | | | | | | | | | | Notify EC of boot mode, i.e. normal, developer or recovery. This is necessary for battery firmware updates. BUG=chrome-os-partner:24741 CQ-DEPEND=CL:205323 CQ-DEPEND=CL:210033 CQ-DEPEND=CL:215720 BRANCH=ToT TEST=Verified on samus & glimmer. Passed runalltests. ~/trunk/src/platform/vboot_reference $ make runalltests -j Change-Id: I1613ede34b4a929d1e8114fb519861f349377e94 Signed-off-by: Sheng-Liang Song <ssl@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/210032 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add GBB flag to disable PD software syncstabilize-6146.Brelease-R38-6158.BDuncan Laurie2014-08-121-4/+6
| | | | | | | | | | | | | | | | | | | | | | In order to disable PD software sync but still do EC software sync it is useful to have a separate GBB flag for it. This will allow me to release a Samus P2B firmware image that will update the EC but not the PD, since the PD FW that comes on P2B devices cannot be updated with software sync. BUG=chrome-os-partner:30079 BRANCH=None TEST=flash BIOS with updated EC+PD: 1) no GBB flags to override behavior updates both EC and PD 2) GBB flag to disable EC software sync disables both EC and PD update 3) GBB flag to disable PD software sync disables only PD update Change-Id: I49ffb59238bee4a2dd66b24f2516e3ce46ea06cd Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/211910 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Call software sync a second time for PD, if necessaryRandall Spangler2014-08-011-1/+9
| | | | | | | | | | | | | | | | | If a device has both an EC and a separate PD chip, call software sync for each chip. BUG=chrome-os-partner:30079 BRANCH=none TEST=Flash image.bin with new AP+EC+PD firmware, reboot. See EC and PD both update and jump to RW. On next cold boot, they jump to RW without again updating. CQ-DEPEND=CL:210520 Change-Id: Ie445336ade46f0009c040afc14b3f40452caf27b Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/210536 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Change VbExEc functions to take a devidx parameterstabilize-6092.Bstabilize-6082.BRandall Spangler2014-07-191-15/+15
| | | | | | | | | | | | | | | | | | | | This will be used in subsequent CLs to support PD software sync. For now, only devidx=0 is used. This changes the external vboot API, so must be checked in at the same time as changes to the u-boot and depthcharge implementations. For now, those implementations should simply check if devidx=0 and fail if it's not. BUG=chrome-os-partner:30079 BRANCH=none TEST=make runtests CQ-DEPEND=CL:208195,CL:208196 Change-Id: Iad3be9d676ac224c4582669bcd67176b39f75c73 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/208210 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Fix jumping EC from RO to RW if disable-jump was called on previous bootRandall Spangler2014-02-111-12/+27
| | | | | | | | | | | | | | | | | | | | | | It's possible for the AP to get updated and remove the RO-normal flag without needing to update EC-RW firmware - for example, if it only needs to update the BIOS. In this case, the EC doesn't need update, but does need to jump to its RW firmware. But if the EC is already booted RO-normal with jump disabled, it will refuse that request and go to recovery mode. The fix is simply to check if the request to jump to RW requires the EC to cold-boot first, and pass through that error code to the caller. BUG=chrome-os-partner:22617 BRANCH=none (affects all platforms, but only in this odd case, and this is a change to the RW portion of the code) TEST=pass new unit test which triggers this condition Change-Id: Ia8d64dff784a9135ef23f6eb26bbca4ad9df57c3 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170168 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* vboot: use recovery button as dev mode switch confirmationstabilize-5339.BLuigi Semenzato2014-01-191-6/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't allow ENTER from a USB keyboard as the confirmation in the switch from normal to developer mode. For devices that have a physical recovery button, we require a recovery button press instead. For other devices, we require that ENTER be pressed on the internal keyboard. This prevents an "evil keyboard" attack in which a USB keyboard (or other USB device pretending to be a keyboard) sends a control-D/ENTER sequence shortly after every boot (followed by more evil keys). In that situation, when users power-on in recovery mode, they will be forced to dev mode even if it was not their intention. Further attacks are easy at that point. TESTING. On a panther device: 1. powered on with recovery button pressed -> booted in recovery mode 2. pressed control-D on external USB keyboard -> got to ToDev? screen 3. pressed ENTER -> system beeped 4. pressed recovery button -> system rebooted in DEV mode ... all as expected Also: 1. powered on with recovery button pressed and HELD recovery button 2. pressed control-D -> system beeped BUG=chrome-os-partner:21729 TEST=manual (see commit message) BRANCH=none CQ-DEPEND=CL:182420,CL:182946,CL:182357 Change-Id: Ib986d00d4567c2d447f8bbff0e5ccfec94596aa7 Reviewed-on: https://chromium-review.googlesource.com/182241 Reviewed-by: Luigi Semenzato <semenzato@chromium.org> Tested-by: Luigi Semenzato <semenzato@chromium.org> Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
* VbBootRecovery: Make second check for 'remove' devices if none foundstabilize-springlte-5116.46.Bstabilize-5116.88.Bstabilize-5116.53.Bstabilize-5116.115.Bstabilize-5116.113.Brelease-R33-5116.Bfirmware-winky-5216.1.Bfirmware-clapper-5218.Bfactory-monroe-5140.Bfactory-beltino-5140.14.BShawn Nematbakhsh2013-12-161-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | There is some inherent latency between the time the USB root hub is initialized and the time USB devices are detected. This can lead to a situation where USB media is attached, yet not found when we do our initial device poll. The device may be detected in subsequent polls, so the media can be booted and no 'remove' screen will be displayed. With this change, if no media to remove is initially found, a second poll will be made after a 500ms delay. This will be enough time for USB devices to be correctly detected in our test cases. Also, it is necessary to change the unit test due to the fact that we now call VbExDiskGetInfo twice before actually displaying any screen. TEST=Manual on Monroe. Insert USB media and trigger recovery boot. Verify 'remove' screen is seen, 'insert' screen is seen after removing media, and system boots after re-inserting media. Also passes vboot_reference unit tests. BUG=chrome-os-partner:23840 BRANCH=Panther, Monroe Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: Ia902c3a126588cd7ea618f2dbbca6b38d35d6ea0 Reviewed-on: https://chromium-review.googlesource.com/179757 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Disable EC jump after RW image startsstabilize-5085.BDaisuke Nojiri2013-12-061-2/+11
| | | | | | | | | | | | | | | TEST=Built and booted Peppy. Ran flashrom from user space and verified the EC firmware was updated after reboot. CQ-DEPEND=CL:172651, CL:172652, CL:178324 BRANCH=none BUG=chromium:325286 Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Change-Id: Ia73da70dbf3abb5ced48666e86715c8d24a431a0 Reviewed-on: https://chromium-review.googlesource.com/172635 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@google.com> Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
* Implementation of Region APIstabilize-4636.BSimon Glass2013-08-301-6/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-27/+6
| | | | | | | | | | | | | 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-6/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Enable vboot for sandbox and improve debugging/format stringsSimon Glass2013-08-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Some functions of vboot are disabled for sandbox because sandbox could not support them. This has changed, so remove the sandbox #ifdefs in the code. Some printf() strings cause warnings on sandbox - mostly that uin64_t is not 'long long' on a 64-bit machine. The existing format strings in U-Boot do not seem to take account of this, so add casts to remove the warnings. Also add a few more debug strings to make it easier to see what is happening in the vboot flow. BUG=chrome-os-partner:21115 BRANCH=pit TEST=manual crosfw -b sandbox -V See there are no warnings. Change-Id: I86f90a693e4bd23fcacf6d48297dd32229348dd4 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/65621 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
View Lorry Controller Status