summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* vboot2: Add end-to-end test of firmware verificationstabilize.59781.98.Bstabilize.5978.98.Bstabilize.5978.51.Brelease-R37-5978.BRandall Spangler2014-06-203-4/+62
| | | | | | | | | | | | | | | | This constructs a test firmware using the old vboot signing utilities, and then verifies it using vboot2 libraries. This ensures vboot2 can read files signed by the current signing process. BUG=chromium:370082 BRANCH=none TEST=VBOOT2=1 make runtests Change-Id: Icc113c982e5ed99382a4592f9ab688784e853c8e Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/204561 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* vboot2: api-level routinesRandall Spangler2014-06-196-7/+1157
| | | | | | | | | | | | | | I'm breaking the last chunk of vboot2 into smaller pieces as I add tests. This has the api-level routines actually called by depthcharge. BUG=chromium:370082 BRANCH=none TEST=make clean && VBOOT2=1 COV=1 make Change-Id: Ic7c082fc5faa0b874b2fa5a15ebda7135dcafe0b Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/200151 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* vboot2: misc higher-level routines, part 2Randall Spangler2014-06-194-0/+612
| | | | | | | | | | | | | | | I'm breaking the last chunk of vboot2 into smaller pieces as I add tests. This has the higher-level routines for verifying keyblock and preamble. BUG=chromium:370082 BRANCH=none TEST=make clean && VBOOT2=1 COV=1 make Change-Id: I82da9542c8857a3f89a85f206c9f5aecadf94a79 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/203501 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* vboot2: misc higher-level routinesRandall Spangler2014-06-197-41/+970
| | | | | | | | | | | | | | | I'm breaking the last chunk of vboot2 into smaller pieces as I add tests. This has a bunch of misc routines like the dev switch logic and GBB header parsing. BUG=chromium:370082 BRANCH=none TEST=make clean && VBOOT2=1 COV=1 make Change-Id: I0f67400d9b59ec21ed5cc155a9b774fd37eb559b Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/203374 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* image_signing: tweak loem firmware signing to have real keysMike Frysinger2014-06-182-25/+38
| | | | | | | | | | | | | | | | | | | | Rather than leave the default set of keys in the firmware untouched (which are dev keys), insert the first loem keyset we find. This is for people who extract the bios.bin by hand and then blindly burn it into their flash. This way they'll still get some valid loem keys. It's not a great solution, but it's better than nothing. BUG=chromium:381862 TEST=signed recovery image by hand w/loemkeys and looked at packed bios.bin TEST=signed recovery image by hand w/devkeys and looked at packed bios.bin TEST=signed recovery image by hand w/custom loemkeys and looked at packed bios.bin BRANCH=none Change-Id: I8db1e34d9f4d85be6edf81fecf79a72031571b01 Reviewed-on: https://chromium-review.googlesource.com/204262 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Commit-Queue: Mike Frysinger <vapier@chromium.org> Tested-by: Mike Frysinger <vapier@chromium.org>
* create_new_keys: drop redundant settingsMike Frysinger2014-06-172-12/+2
| | | | | | | | | | | | | The common.sh file already defines these variables/funcs, so drop them. BUG=chromium:381862 TEST=`./create_new_keys.sh` created new keys correctly BRANCH=none Change-Id: Ie7f0f683d4971c188d4629b520938b4b65bb0a9f Reviewed-on: https://chromium-review.googlesource.com/203685 Reviewed-by: Gaurav Shah <gauravsh@chromium.org> Tested-by: Mike Frysinger <vapier@chromium.org>
* image_signing: support loem keysets with firmware shellballsMike Frysinger2014-06-1639-37/+155
| | | | | | | | | | | | | | | | | | | | | | | | | | With an loem keyset in a recovery shellball, we don't want to write the rootkeys & vblocks to the firmware image directly. Instead, we'll put them into a keyset subdir that the firmware updater will process later. bios.bin keyset/ rootkey.LOEMID vblock_A.LOEMID vblock_B.LOEMID We still write the recovery key to the firmware image though as that is shared between all the keysets. BUG=chromium:381862 TEST=Ran against a recovery image with devkeys & loemkeys and checked shellball TEST=`cbuildbot daisy-release` works BRANCH=none Change-Id: I6fc99c71e6c7dee25f7f9a466a97314ff750fda9 Reviewed-on: https://chromium-review.googlesource.com/203682 Reviewed-by: Gaurav Shah <gauravsh@chromium.org> Commit-Queue: Mike Frysinger <vapier@chromium.org> Tested-by: Mike Frysinger <vapier@chromium.org>
* sign_firmware: clean up style to use a main funcMike Frysinger2014-06-131-32/+39
| | | | | | | | | | | | | | | No real functional changes here. Tidying up to make the next CL easier. BUG=chromium:381862 TEST=ran by hand and checked output BRANCH=none Change-Id: I9ffea6eba17560797135f39cf861318b545b9a54 Reviewed-on: https://chromium-review.googlesource.com/203681 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Gaurav Shah <gauravsh@chromium.org> Tested-by: Mike Frysinger <vapier@chromium.org> Commit-Queue: Mike Frysinger <vapier@chromium.org>
* vboot_reference: Don't use session_manager_use_flags.txt.Daniel Erat2014-06-121-11/+9
| | | | | | | | | | | | | | | | | | | Make ensure_no_nonrelease_files.sh stop grepping /etc/session_manager_use_flags.txt for USE flags. Instead, look for non-comment lines in /etc/chrome_dev.conf. BUG=chromium:377301 TEST=manual: ran against images both with and without extra config directives BRANCH=none CQ-DEPEND=I86d01f4a551433527bb434dc62c30fb44082f774 CQ-DEPEND=Ic030207840b6be79b51486d1706573241a01c08d Change-Id: Iefeefd936dc7706ed74340edb6521621885bbe25 Reviewed-on: https://chromium-review.googlesource.com/203463 Reviewed-by: Mike Frysinger <vapier@chromium.org> Commit-Queue: Daniel Erat <derat@chromium.org> Tested-by: Daniel Erat <derat@chromium.org>
* vboot2: Use more specific error codes, part 3Randall Spangler2014-06-116-120/+251
| | | | | | | | | | | | | | Error codes reported by 2common.c are now very specific, and tests verify the proper errors are reported. BUG=chromium:370082 BRANCH=none TEST=make clean && VBOOT2=1 COV=1 make Change-Id: I9480bd22b60ae339196c92918a8a984a9f05ac1a Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/202938 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* vboot2: Use more specific error codes, part 2Randall Spangler2014-06-114-65/+103
| | | | | | | | | | | | | | | | Error codes reported by the aligment checks in common.c are now very specific, and tests verify the proper errors are reported. Changed args to vb2_member_inside() so I can force wraparounds. BUG=chromium:370082 BRANCH=none TEST=make clean && VBOOT2=1 COV=1 make Change-Id: Ib135674e82005b76bce7a83a1f4a65a9c5296cf4 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/202937 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* vboot2: Use more specific error codesstabilize-5944.Bstabilize-5943.Bstabilize-5942.Bfactory-samus-5939.BRandall Spangler2014-06-0712-97/+222
| | | | | | | | | | | | | | | | | | | | | Error codes reported by the crypto and storage APIs are now very specific, and tests verify the proper errors are reported. More specific error codes coming to other files next, but I don't want this CL to get too long. This also changes test_common.c so TEST_EQ() reports mismatched values in both decimal and hex, and adds TEST_SUCC() to test for a successful return value. BUG=chromium:370082 BRANCH=none TEST=make clean && VBOOT2=1 COV=1 make Change-Id: I255c8e5769284fbc286b9d94631b19677a71cdd0 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/202778 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Use the TPM to back up some of the nvram fieldsBill Richardson2014-06-0512-13/+511
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We use a few bytes of battery-backed nvram to save some flags across reboots. However if the battery discharges completely, these flags are lost. There aren't any security issues with that since they reset to safe values, but some of the flags are used to configure how the system boots in dev-mode. If a dev-mode user has completely replaced ChromeOS with some other OS, then she often needs to set the dev_boot_usb and/or dev_boot_legacy flags as well in order to boot it using Ctrl-U or Ctrl-L. If the battery dies, then those flags are cleared, and the only way to make the Chromebook boot again is by going through recovery, which wipes the disk. This change uses a new NV space in the TPM to back up some of the nvram flags. These nvram fields will be backed up: block_devmode dev_boot_legacy dev_boot_signed_only dev_boot_usb fwupdate_tries loc_idx Because writing to the TPM space is slow and limited to an unspecified but finite number of cycles, we only back up the fields when specifically requested by the new backup_nvram_request flag. This flag will be set by crossystem whenever it is used to change any of the fields listed above. The backup will be attempted at the NEXT boot (because the TPM is locked after booting), and the backup_nvram_request flag will be cleared if the backup was successfull. Note that this CL is for Top of Trunk only. The firmware will create the required TPM spaces on systems that have never been booted, but we don't yet have a secure or reliable method to update existing systems. FYI, on Link, determining that the TPM's backup NV space doesn't exist adds about 6ms to the boot time. If it does exist, the backup_nvram_request flag is cleared automatically so it won't check until it's set again. BUG=chromium:362105 BRANCH=ToT (only!) TEST=manual Testing this is a long and involved process. Read on... First, there are host-side tests for it. In the chroot: cd src/platform/ec make runtests Second, to test on a completely NEW system that was first booted with a BIOS that contains this CL, do this: Enter dev-mode Use crossystem to set values for the fields listed above Confirm that "backup_nvram_request" is set to 1 Reboot Use crossystem to confirm that "backup_nvram_request" is now 0 Remove the battery and the AC Reattach either battery or AC so it will boot again Use crossystem to confirm that the backed up fields are still good, while the others have been reset to default values Switch to normal mode Remove the battery and the AC Reattach either battery or AC so it will boot again Look at the bios info in chrome://system to see what crossystem says Confirm that the dev_boot_* flags are all 0, while the others are restored Third, to set things up to test this on an existing system (I used Link), you have update the BIOS, delete both the Kernel and Firmware NV spaces in the TPM, then reboot so that the BIOS will create the Backup, Kernel, and Firmware spaces. It will only do that if they're all missing. Open it up, disable write-protect, attach a servo, etc. Switch to dev-mode, log in. Run make_dev_firmware.sh Reboot in recovery mode, and insert a USB stick with a test image on it. NOTE: In order to fiddle with the TPM, we'll *always* have to boot in recovery mode, since that's the only time the TPM is left unlocked. That's NOT the same as pressing Ctrl-U at the scary boot screen. The rest of these steps assume you've booted in recovery mode and are running from the test image on the USB stick. Run make_dev_ssd.sh --remove_rootfs_verification --recovery_key Reboot (recovery mode) Run mv /etc/init/tcsd.conf /etc/init/tcsd.conf.disabled Reboot (recovery mode). Run "tpmc getvf". It should say deactivated 0 disableForceClear 0 physicalPresence 1 physicalPresenceLock 0 bGlobalLock 0 Run "tpmc geto". It should say Owned: no Now you'll need to build the "tpm-nvtool" utility. In the chroot: cd src/third_party/tpm/nvtool make Copy that to the DUT, in /usr/local/bin. Now run tcsd tpm-nvtool --list | grep Index You may see a number of spaces, but you should at least see these: # NV Index 0x00001007 # NV Index 0x00001008 Run tpm_takeownership It will prompt you for two passwords (and confirm each one). Respond with something you can remember like "google". Run tpm-nvtool --release --index 0x1007 --owner_password "google" tpm-nvtool --release --index 0x1008 --owner_password "google" Verify that it worked with tpm-nvtool --list | grep Index Power off. Using servo, flash the new BIOS that has this CL in it. Power on, normally this time (not recovery mode). If all goes well, it should create the correct NV spaces and boot into the SSD. Copy tpm-nvtool into this image too, and run tpm-nvtool --list | grep Index You should now see at least these spaces: # NV Index 0x00001007 # NV Index 0x00001008 # NV Index 0x00001009 Now you're ready to test the backup/recover feature. Change-Id: I00031fa0774720147327e2ae0f37e26b34b86341 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/202138 Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
* vboot2: Add common functionsRandall Spangler2014-06-057-139/+1175
| | | | | | | | | | | | | | This is the third of several CLs adding a more memory- and code-efficient firmware verification library. BUG=chromium:370082 BRANCH=none TEST=make clean && COV=1 make Change-Id: I3a5daa5438afc5598d3dfcf5a597ffb16eda8749 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/200140 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* vboot2: Add nvstorage and secdata functionsRandall Spangler2014-06-0516-1/+1907
| | | | | | | | | | | | | | This is the second of several CLs adding a more memory- and code-efficient firmware verification library. BUG=chromium:370082 BRANCH=none TEST=make clean && COV=1 make Change-Id: I1dd571e7511bff18469707d5a2e90068e68e0d6f Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/199841 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* vboot2: Add crypto functionsRandall Spangler2014-06-0512-0/+2147
| | | | | | | | | | | | | | | This is the first of several CLs adding a more memory- and code-efficient firmware verification library. This CL adds the crypto library (modified from firmware/lib/cryptolib) and unit tests for it. BUG=chromium:370082 BRANCH=none TEST=make clean && VBOOT2=1 COV=1 make Change-Id: I4240eab227bb197cacc6c8e7a6397127d74414a2 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/199578 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* vboot2: Add workbuf functionsRandall Spangler2014-06-036-5/+445
| | | | | | | | | | | | | We'll try breaking this up into smaller pieces. This one's pretty small - just the work buffer utility functions. BUG=chromium:370082 BRANCH=none TEST=make clean && VBOOT2=1 COV=1 make Change-Id: I4c417438053c155d6f7f9725552066e9b059951c Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/201141
* Workaround for failing tests when DEBUG=1Bill Richardson2014-05-312-7/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | Two changes here. First are some failing assertions in tlcl.c. These have always failed, but only when DEBUG=1, so no one noticed. I've opened a bug to find out why, but it's blocking something else. We're refactoring anyway, so for now we'll just comment around it. Second is a null-pointer dereference in VbSharedDataSetKernelKey(). Again, only when DEBUG=1. BUG=chromium:379255 BRANCH=ToT TEST=manual cd src/platform/ec \rm -rf build DEBUG=1 make runtests Change-Id: Ia5e0a742f75057b449f3c19b778c5d2f0408d7cd Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/202303 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
* lib: Handle return error code of VbExDisplaySetDimension correctly.stabilize-5899.BHung-Te Lin2014-05-221-3/+3
| | | | | | | | | | | | | | | | | The return value of VbExDisplaySetDimension should be handled as VbError_t, which means we should print error message when it's not zero. Also add the return code to debug message. BRANCH=none BUG=none TEST=emerge-nyan coreboot chromeos-bootimage, enter recovery screen. Not seeing error messages anymore. Change-Id: Icafdfd933d799e8496fedcf1633339065c6962a3 Reviewed-on: https://chromium-review.googlesource.com/200679 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Queue: Hung-Te Lin <hungte@chromium.org> Tested-by: Hung-Te Lin <hungte@chromium.org>
* Add missing #include in vboot_api.hstabilize-5875.BDavid Hendricks2014-05-151-0/+1
| | | | | | | | | | | | | | | | | This includes stdlib.h since otherwise size_t might not be defined. BUG=none BRANCH=none TEST=fixed a compilation issue with coreboot Signed-off-by: David Hendricks <dhendrix@chromium.org> Change-Id: I83e2b761d2d8e0d4899c9bdebf40190f1444cd8a Reviewed-on: https://chromium-review.googlesource.com/199840 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: David Hendricks <dhendrix@chromium.org>
* vbutil_kernel: Add enum for the mips architectureGaurav Shah2014-05-151-1/+4
| | | | | | | | | | | BUG=chromium:327749 TEST=emerge vboot_reference BRANCH=none Change-Id: I627636d8433c0a8cdbd2c7b24cc405a41173658f Reviewed-on: https://chromium-review.googlesource.com/199993 Reviewed-by: Mike Frysinger <vapier@chromium.org> Tested-by: Gaurav Shah <gauravsh@chromium.org> Commit-Queue: Gaurav Shah <gauravsh@chromium.org>
* lib: Add VbExDisplaySetDimension.Hung-Te Lin2014-05-133-0/+30
| | | | | | | | | | | | | | | | | | | | | For displaying GBB images on panels with different dimension, X86 has VESA mode and VBIOS to scale automatically but ARM does not have such mode settings. If we install a larger panel on ARM platforms, current firmware will render the screens in left-top corner and leave black borders in right-bottom corner. To render images correctly, vboot library has to send out the expected dimension (similar to the VESA mode) so display provider can scale or shift images. BUG=chrome-os-partner:28494 TEST=emerge-nyan vboot_reference CQ-DEPEND=CL:199051,CL:199045 BRANCH=none Change-Id: I6d60f755ca2bcbd3135631d7624a8a4a4cff68b1 Reviewed-on: https://chromium-review.googlesource.com/199043 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Hung-Te Lin <hungte@chromium.org> Commit-Queue: Hung-Te Lin <hungte@chromium.org>
* Add an nvram flag to block the use of dev modestabilize-swanky-5841.55.Bstabilize-gnawty-5841.84.Bstabilize-5841.83.Bstabilize-5841.76.Bstabilize-5828.0.Brelease-R36-5841.Bfirmware-tricky-5829.Bfirmware-mccloud-5827.BBill Richardson2014-05-032-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, this does nothing. It just sets a flag that nothing looks at. Don't get all wound up - we haven't abandoned our principles. This will eventually be used to allow enterprise-enrolled customers to prevent unauthorized use of developer mode in the Chrome OS devices that THEY OWN. This is not Google deciding to turn a feature off, it's allowing the OWNER to control the use of the feature. In some situations, the owner can be held liable for what others do with the owner's equipment. This will help the owner avoid those situations while their device is out of their immediate control. BUG=none BRANCH=ToT TEST=manual Set the flag with: crossystem block_devmode=1 Clear it with: crossystem block_devmode=0 Retrieve the value ("0" or "1") like so: val=$(crossystem block_devmode) echo "the flag is $val" or just test it directly like so: if crossystem 'block_devmode?1' ; then echo "devmode is blocked" else echo "devmode is allowed" fi It should be persistent across reboots. Change-Id: I097f15b307e1c3a2a9db595e9495028a2eea6309 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/197771 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* make_dev_firmware.sh: Correct firmware body size when changing rootkey.stabilize-5807.0.BHung-Te Lin2014-04-251-25/+28
| | | | | | | | | | | | | | | | make_dev_firmware.sh calls resign_firmwarefd.sh, which extracts rootkey from input image for checking VBLOCK firmware body size. As a result, we should resign firmware before changing rootkey / GBB. BUG=chromium:365738 TEST=Install Nyan/Peppy PreMP-signed firmware, run make_dev_firmware.sh, and then boot in normal mode. BRANCH=none Change-Id: I45dbcacb40b7b77bbf89f1ba244bf7fb25f9ae27 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/196521 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* vboot_reference: Provide crossystem interface stubs for mipsstabilize-5791.0.Bstabilize-5784.0.Bfirmware-nyan-5771.Bfactory-nyan-5772.BGaurav Shah2014-04-041-0/+74
| | | | | | | | | | | | BUG=chromium:358418 TEST=emerge-mipsel-o32-generic vboot_reference now builds. BRANCH=none Change-Id: Ia1414dfdef00c5b22ed0971fad814ef761b32b86 Reviewed-on: https://chromium-review.googlesource.com/193050 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Gaurav Shah <gauravsh@chromium.org> Commit-Queue: Gaurav Shah <gauravsh@chromium.org>
* set_gbb_flags: Aborts only if HW & SW WP are both enabled.test-5619.Bstabilize-zako-5712.88.Bstabilize-5712.89.Bstabilize-5712.8.Bstabilize-5712.61.Bstabilize-5712.49.Bstabilize-5696.Bstabilize-5680.Bstabilize-5656.Bstabilize-5579.Bstabilize-5511.Bstabilize-5500.71.Bstabilize-5500.26.Bstabilize-5500.130.Bstabilize-5500.100.Brelease-R35-5712.Brelease-R34-5500.Bfactory-rambi-5517.Bfactory-pit-5499.BHung-Te Lin2014-02-141-6/+7
| | | | | | | | | | | | | | | | | Early proto devices (for testers and developers) may have hardware write protection enabled and software disabled. They can still flash SPI ROM in that case, and no need to disable hardware WP switch. BRANCH=none BUG=chromium:341242 TEST=./set_gbb_flags.sh 0x39 # see WP messages. Change-Id: Id320410795a162a009b80360c2225c7510337591 Reviewed-on: https://chromium-review.googlesource.com/186336 Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org> Commit-Queue: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* set_gbb_flags: Check write protection status before starting to flash.stabilize-5463.BHung-Te Lin2014-02-111-0/+27
| | | | | | | | | | | | | | | | | | People trying to override GBB flags and not having write protection disabled may corrupt whole RW section of firmware. To avoid that, we should check write protection before starting to invoke flashrom commands. BUG=chromium:341242 TEST=./set_gbb_flags.sh 0x39 # Aborted on a write-protected system, as expected. BRANCH=none Change-Id: I6b2dcc75b87dc5ceace0d7caec62ded787b2b534 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/185653 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Hung-Te Lin <hungte@google.com>
* Fix jumping EC from RO to RW if disable-jump was called on previous bootRandall Spangler2014-02-112-12/+32
| | | | | | | | | | | | | | | | | | | | | | 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>
* tegra124: Add the tegra124 compatibility string to crossystem.test-5394.Bstabilize-5414.Bstabilize-5412.BGabe Black2014-01-291-0/+1
| | | | | | | | | | | | | | | | | | | | | Teach crossystem the tegra124 compatibility string so that it can identify the platform for tegra124 based systems. I called the platform Tegra5 to fit in with what seems to be the naming scheme for the other Tegra SOCs. BUG=chrome-os-partner:25355 TEST=Built and ran on nyan and saw the "platform_family" setting return Tegra5 instead of (error). BRANCH=None Change-Id: I1044f958ecdac37ad285fdc3d53e7bc36ca69315 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/184051 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org>
* vboot: use recovery button as dev mode switch confirmationstabilize-5339.BLuigi Semenzato2014-01-197-10/+178
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* x86: Stop building the vboot library using regparm=3.stabilize-5254.Bfactory-zako-5220.BGabe Black2014-01-101-1/+1
| | | | | | | | | | | | | | | | | | This complicates things in a number of ways, including making GDB not work properly because it assumes the standard ABI in some places. Measurements show that it doesn't really make much difference performance wise. BUG=None TEST=Built and booted with coreboot and depthcharge on link. BRANCH=None Change-Id: I7f004f8cf83b7c1a78ab12f814477504a5a5c28c Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/180874 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@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-162-2/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* crossystem: handle BayTrail gpiosAaron Durbin2013-12-111-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | BayTrail systems have 3 banks of gpios. Therefore, the Linux kernel exposes these 3 banks as 3 gpiochip entries. The kernel driver expects the 3 banks to be exposed with specific UIDs associated with a specific banks. ChromeOS firmware maps gpios within a given bank using the bank's MMIO offset. In summary: Bank Type | UID | Offset ----------+-----+------- SCORE | 1 | 0x0000 NCORE | 2 | 0x1000 SUS | 3 | 0x2000 BUG=chrome-os-partner:24408 BUG=chrome-os-partner:24324 BRANCH=None TEST=Built. 'crossystem wpsw_cur' works correctly. Change-Id: I251f86285ce9733f7ca90ed1ebef536f4fe5c07c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/179513 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* crossystem: add GpioChipset sturcture for x86Aaron Durbin2013-12-111-6/+29
| | | | | | | | | | | | | | | | | | | | | Up until recently the x86 systems had a single contiguous set of gpio numbers exported through /sys/class/gpio as /sys/class/gpiochip<X> values. BayTrail systems have 3 sets of gpio numbers. Therefore, there needs to be a translation/look-up function based on chipset. The existing chipsets have a 1:1 mapping, but this patch lays the ground- work for chipset-specific translation. BUG=chrome-os-partner:24324 BUG=chrome-os-partner:24440 BUG=chrome-os-partner:24408 BRANCH=None TEST=Built. Ran on Rambi. Change-Id: I32bcd975aea421f86a0220ee30332f48fe727656 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/179512 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* crossystem: make BayTrail a valid platform_familyAaron Durbin2013-12-111-0/+1
| | | | | | | | | | | | | | | BayTrail is a valid chromeos platform. Therefore, allow it to be returned for 'platform_family'. BUG=chrome-os-partner:24324 BUG=chrome-os-partner:24440 BRANCH=None TEST=Built. 'crossystem platform_family' reports 'BayTrail'. Change-Id: I8d0b835f5f40e7f34adb4f91bd974c428bbaf6da Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/179511 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* Disable EC jump after RW image startsstabilize-5085.BDaisuke Nojiri2013-12-064-10/+17
| | | | | | | | | | | | | | | 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>
* Make crossystem.h more polite and more useful.test-4980.Btest-4824.Bstabilize-R33-4982.Bstabilize-5062.Bstabilize-4920.6.Brelease-R32-4920.Bfirmware-bolt_kirby-4979.Bfactory-panther-4920.23.BJ. Richard Barnette2013-10-316-12/+30
| | | | | | | | | | | | | | | | | | | This adds a VB_MAX_STRING_PROPERTY for callers that don't want to guess at how big to make their buffers. Additionally, it changes the size parameter to VbGetPropertyString() from int to size_t. BUG=None TEST=compile the code BRANCH=none Change-Id: I22809d48e13b535593cb22a56444e2dcb27791a5 Reviewed-on: https://chromium-review.googlesource.com/175039 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Richard Barnette <jrbarnette@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Queue: Richard Barnette <jrbarnette@chromium.org>
* Allow <vboot/crossystem.h> to be usable in C++ code.stabilize-4886.BJ. Richard Barnette2013-10-251-0/+8
| | | | | | | | | | | | BUG=None TEST=build update_engine with a change that uses the header. BRANCH=none Change-Id: Icbfe9be615a4f7f4078a0a0cde64324908dea2a7 Reviewed-on: https://chromium-review.googlesource.com/174428 Commit-Queue: Richard Barnette <jrbarnette@chromium.org> Tested-by: Richard Barnette <jrbarnette@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Add a "debug_build" query to crossystem.J. Richard Barnette2013-10-232-8/+40
| | | | | | | | | | | | | | | | | Querying "debug_build" allows the caller to determine whether the image has requested debug, independent of the setting of the dev_mode switch. BUG=chromium:308678 BRANCH=none TEST=use the new command option on both base and dev images Change-Id: I369f26d75156f2e88d9f6f467efbf8f633e78bda Reviewed-on: https://chromium-review.googlesource.com/174107 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Richard Barnette <jrbarnette@chromium.org> Reviewed-by: Will Drewry <wad@chromium.org> Commit-Queue: Richard Barnette <jrbarnette@chromium.org>
* fwlib: Map architecture armv7 to armstabilize-4856.Bstabilize-4825.Bstabilize-4731.85.Bstabilize-4731.62.Bstabilize-4731.31.Brelease-R31-4731.Bfactory-samus-4788.Bfactory-daisy-4731.81.BStefan Reinauer2013-09-201-0/+2
| | | | | | | | | | | | | | | | | | In coreboot the architecture for our ARM platforms is armv7. In order to have vboot_reference pick up the right build parameters, map armv7 to arm. BUG=none BRANCH=none TEST=lots more changes on coreboot needed for a reasonable test. Right now coreboot compiles fine with ramstage verification and this patch. Change-Id: I64dad9be663b7bd7d80d138b3c49ae8f4699f01d Reviewed-on: https://chromium-review.googlesource.com/170071 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Stefan Reinauer <reinauer@google.com> Tested-by: Stefan Reinauer <reinauer@google.com>
* Add memory leak checkingSimon Glass2013-09-1717-6/+135
| | | | | | | | | | | | | | | | | Add checks that the vboot library does not leak memory. This works by tracking VbExMalloc() calls and making sure that they have an associated VbExFree(). Adjust host_signature to use VbExFree() instead of free(), so that this scheme works correctly for existing code. BUG=chrome-os-partner:21115 BRANCH=pit TEST=FEATURES=test emerge-peach_pit vboot_reference Change-Id: I6ccccfbcc162fc43fb75862cd0eddad78ce8b18a Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/66175
* Fix improper memset statement.stabilize-4701.BHan Shen2013-09-041-1/+1
| | | | | | | | | | | | | | | | | Instead of memset(pointer, 0, sizeof(pointer)), we should use "memset(pointer, 0, sizeof(*pointer))". BRANCH=none TEST=Built successfully BUG=None Change-Id: I72e224188ccede1a1f83efa7fa3138e4a0ecd3b3 Reviewed-on: https://chromium-review.googlesource.com/167880 Reviewed-by: Luis Lozano <llozano@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Han Shen <shenhan@google.com> Commit-Queue: Han Shen <shenhan@google.com> Tested-by: Han Shen <shenhan@google.com>
* Implementation of Region APIstabilize-4636.BSimon Glass2013-08-3031-254/+1044
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2931-1041/+254
| | | | | | | | | | | | | 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-2831-254/+1041
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present reading data from storage in Vboot is a little fragmented. For the firmware image, we expect the boot loader to handle this. For the disk we have a block-level API. For the GBB (which also sits in the firmware image) we expect the entire thing to be read before Vboot is called. Add the concept of a region, and an API to read from a region. At present, and most pressing, is reading from a GBB region. In the future this could be extended to other parts of the firmware or even the disk. Move all access to the GBB into this API so that the boot loader can provide either a GBB region in one large contiguous chunk, or a function to deal with read requests from vboot. The call to VbExRegionRead() is behind a flag since not all boot loaders support it yet. The main change for boot loaders which don't support this new API is that vboot will do more behind the scenes. For example, it will allocate memory for chunks of data that it reads from the GBB, rather than just accessing it directly. This approach is considerably simpler than trying to pass char ** everywhere and have vboot decide whether something needs to be allocated or not. The tests are updated, mainly to include setting up a GBB structure accessible from VbCommonParams, which is now required by the firmware and kernel functions. In normal operation this is set up at the start of VbLoadFIrmware() and VbSelectAndLoadKernel() but for tests which call children of these functions directly, the GBB structure must be set up manually by the test. BUG=chrome-os-partner:21115 BRANCH=none TEST=manual FEATURES=test sudo -E emerge vboot_reference Change-Id: I2c19e9dc2ed602d0642bbf4f7d27f79fe9fad873 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/63336 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Avoid exit code overflow for tpmc.Luigi Semenzato2013-08-281-5/+7
| | | | | | | | | | | | | | | | | In case of a TPM error, tpmc returns the TPM error code, which can be greater than 255. In that case the error code is truncated. Some error codes, such as TPM_E_RETRY, end with a zero byte, resulting in a successful exit code. This is despicable. BUG=chromium:234357 TEST=tested with exit codes < 255. Too hard to generate the others. BRANCH=none Change-Id: I891a5c0659c06aac778449e2a0a935c5f82ccdb8 Reviewed-on: https://chromium-review.googlesource.com/66885 Reviewed-by: Luigi Semenzato <semenzato@chromium.org> Commit-Queue: Luigi Semenzato <semenzato@chromium.org> Tested-by: Luigi Semenzato <semenzato@chromium.org>
* Revert "Enable debug flags when building natively"Hung-Te Lin2013-08-271-1/+0
| | | | | | | | | | | | | | | | | | This reverts commit e4759b782dff166600dbbfac884462babb433fac. The DEBUG flags changed something in futility's section layout and caused its command searching mechanism to fail (we can verify that by running "dump_fmap" command). BUG=chromium:279645 TEST=emerge-link vboot_reference; /build/link/usr/bin/dump_fmap # success BRANCH=none Change-Id: Ie42a33aed3fdc0443f2a758e1216d86aea5c326d Reviewed-on: https://chromium-review.googlesource.com/67015 Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Commit-Queue: Hung-Te Lin <hungte@chromium.org>
* Correct some minor compiler warningsSimon Glass2013-08-254-5/+10
| | | | | | | | | | | | | | | | | | | | | A few places in the code through up warnings when building with strict compiler flags. Correct these. BUG=chrome-os-partner:21115 BRANCH=pit TEST=manual Build with: FEATURES=test emerge-peach_pit vboot_reference and see that iot now succeeds. Warnings include: host/arch/arm/lib/crossystem_arch.c: In function 'ReadFdtValue': host/arch/arm/lib/crossystem_arch.c:93:8: error: ignoring return value of 'fread', declared with attribute warn_unused_result [-Werror=unused-result] Change-Id: I765723636e5f8979b794925c7b610081b2849026 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66174
* Improve kernel tests to pass valgrindSimon Glass2013-08-252-12/+30
| | | | | | | | | | | | | | | | | At present the kernel tests produce valgrind errors since the GPT data is sometimes accessed before it is read. This is unnecessary, so update the code to avoid this. BUG=chrome-os-partner:21115 BRANCH=pit TEST=manual valgrind --leak-check=full ./build/tests/vboot_kernel_tests See that we no longer get valgrind errors. Change-Id: I9e9660e38a62a735cf01a37c2d81ddb5ab8b1528 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66173
* Enable debug flags when building nativelySimon Glass2013-08-251-0/+1
| | | | | | | | | | | | | | | | It is still useful to build natively with debugging, particularly when improving test code, so add this to the compiler flags in this case. BUG=chrome-os-partner:21115 BRANCH=pit TEST=manual 'make DEBUG=1' in the vboot directory within the chroot. See that the test executables are now build with debugging info and gdb has line number information. Change-Id: Icaedae67151883673525930e25cf8b1f30654339 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66172
View Lorry Controller Status