summaryrefslogtreecommitdiff
path: root/tests/vboot_api_init_tests.c
Commit message (Collapse)AuthorAgeFilesLines
* Improve coverage of vboot_api_init.cRandall Spangler2013-01-241-3/+106
| | | | | | | | | | | | BUG=chromium-os:38139 BRANCH=none TEST=make runtests Change-Id: I3d39feb712eb7e572f9c57f27449f19e8e809ed0 Reviewed-on: https://gerrit.chromium.org/gerrit/41896 Commit-Queue: Randall Spangler <rspangler@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Reformat vboot_api_init_testsRandall Spangler2013-01-241-332/+354
| | | | | | | | | | | | | No code changes, just reformat to kernel style BUG=none BRANCH=none TEST=make runtests Change-Id: I9b07af36b915ead519a8908b3dc5b93aedc5d4be Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/41895 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Add more recovery_reason codesBill Richardson2012-11-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are several places where the same recovery_reason was used to report slightly different points of failure. Let's create some new codes instead. Remember that recovery mode is handled by RO firmware, so if an updated RW firmware uses one of the new error codes, pressing TAB at the recovery screen will say "We have no idea what this means". That's not a bug. This CL deprecates the original codes, so the fact that the RO firmware doesn't recognize it just means it's a new code reported by a new RW BIOS. BUG=chromium-os:36562 TEST=manual BRANCH=parrot Run make && make runtests It should pass. You can test some of the error cases on actual hardware by using crossystem recovery_reason=86 reboot and pressing TAB at the recovery screen. For that example you should see the message recovery_reason: 0x56 TPM lock error in rewritable firmare Change-Id: I123c781e6c6f6fe0284c4fd49f5f5a855eece7df Reviewed-on: https://gerrit.chromium.org/gerrit/38652 Commit-Ready: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add VB_INIT_FLAG_SW_WP_ENABLED to VbInit() input flags.Bill Richardson2012-08-281-0/+6
| | | | | | | | | | | | | | | | | | We need to know not only whether the HW WP pin is asserted, but whether the flash chip has configured its software protection registers to actually protect anything. This flag can be used to indicate that. BUG=chrome-os-partner:13265 BRANCH=link TEST=none This just adds the flag. Nothing actually sets the flag yet, so there's nothing to test. Change-Id: Icba9945fb56eb3a4681486c630cbbdc9232485ef Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/31642 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add clear TPM owner requestRandall Spangler2012-08-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds two new flags to crossystem: clear_tpm_owner_request clear_tpm_owner_done The first one requests that the firmware clear the TPM owner on the next boot. When the firmware does this, it will set clear_tpm_owner_request=0, and set clear_tpm_owner_done=1. The OS can use the done-flag as a hint that trusted things guarded by the TPM are no longer trustable. BUG=chromium-os:31974 TEST=manual crossystem // both flags initially 0 crossystem clear_tpm_owner_request=1 crossystem clear_tpm_owner_done=1 // request=1, done=0; done can be cleared but not set by crossystem reboot tpmc getownership // owned=no crossystem // request=0, done=1 crossystem clear_tpm_owner_done=0 crossystem // both flags 0 again Signed-off-by: Randall Spangler <rspangler@chromium.org> Change-Id: I49f83f3c39c3efc3945116c51a241d255c2e42cd Reviewed-on: https://gerrit.chromium.org/gerrit/25646
* Fix broken tests left from commit dc6b642bBill Richardson2012-07-101-0/+4
| | | | | | | | | | | | BUG=chrome-os-partner:10947 TEST=manual make && make runtests Change-Id: Idd5e10fc0cfed059f035d127f06ca009f0cff03a Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/27124 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add GBB flags to enable dev mode by defaultRandall Spangler2012-06-141-1/+14
| | | | | | | | | | | | | | | | | | | | | | And enable dev_boot_usb by default. And disable rollback checks. The first flag is necessary for factory to build with keyboard controlled dev mode. The other flags are really handy for development on systems where you've defeated firmware WP and are installing custom firmware. BUG=chromium-os:31844 TEST=make && make runtests Signed-off-by: Randall Spangler <rspangler@chromium.org> Change-Id: I9d837fee676cb0186ea98f13005ad60a9ab86393 Reviewed-on: https://gerrit.chromium.org/gerrit/25265 Tested-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org> Commit-Ready: Randall Spangler <rspangler@chromium.org>
* Support virtual dev-switch (keyboard-based dev-mode)Bill Richardson2012-06-081-9/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BUG=chrome-os-partner:9706 TEST=manual Currently, Link is the only platform that enables this feature. To enter dev-mode: Boot into recovery mode using the magic key chord. At the Insert screen, press Ctrl-D. You'll be asked if you want to enter developer mode. If you then press ENTER, it will reboot with dev-mode enabled. If you press SPACE or ESC, it will return to the Insert screen. If you enter recovery mode through any other means, or if dev-mode is already enabled, pressing Ctrl-D at the Insert screen will have no effect. To return to normal mode: Reboot. At the Dev screen, press ENTER or SPACE. It will reboot to recovery mode and ask you if you want to return to normal mode. If you press ESC or power off, you'll still be in dev-mode. Press ENTER or SPACE, and it will reboot into normal mode (of course, if you've messed up your images while in dev-mode, you'll just come right back to recovery mode again). You can also request a direct return to normal mode by running crossystem disable_dev_request=1 and rebooting. Change-Id: I435905855a6c39932ee466cc046bdc4c4c860f98 Reviewed-on: https://gerrit.chromium.org/gerrit/24160 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Ready: Bill Richardson <wfrichar@chromium.org>
* Use virtual dev-mode switch when told to.factory-2338.BBill Richardson2012-05-181-3/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | If VbInit() is instructed to look at a virtual dev-mode switch, then it will use value contained in the TPM's firmware space instead of a hardware GPIO to determine if developer mode is enabled. This change just makes it look. It doesn't provide a way to actually set the value in the TPM. VbInit() isn't being told to look yet, either. Those changes are coming. BUG=chrome-os-partner:9706 TEST=none The usual sanity-check applies: make make runtests But to actually test that this stuff is working IRL requires special tweaks to other components and monitoring the serial debug output from both EC and CPU. We'll save the hands-on tests for when it's all done. Change-Id: Ie485ad2180224e192238bf2a5dbf95bbcb9130f9 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/23067 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Dev-mode allows booting self-signed kernels by default.Bill Richardson2011-11-181-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | When you enter dev-mode, Pressing Ctrl-U to boot from USB is DISABLED. Booting any self-signed kernel from the SSD is ENABLED. This replaces the "crossystem dev_boot_custom" argument with "crossystem dev_boot_signed_only", which has the opposite polarity. So if you want to dev-mode to only boot official kernels, you have to explictly set it that way. If you leave dev-mode and then come back, it will go back to the conditions shown above. BUG=chrome-os-partner:5954 TEST=manual Just run the factory flow. It was broken; this should fix it (except for any workarounds that were added while it was broken; those may need to be reverted). Change-Id: I13e0edbc0e77c5d6ea609dabf771085006cd1805 Reviewed-on: https://gerrit.chromium.org/gerrit/11853 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* Add flag to GBB to allow loading PCI Option ROMsBill Richardson2011-11-111-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As shipped, H2C only loads the option ROM for the built-in video, and that only when it needs display the BIOS warning screens. By setting a flag in the GBB, you can allow all option ROMs to be loaded: Note that we'll never enable this ourselves (and there's a factory test to ensure that*) because it executes non-verified code. But if a customer wants to void their warranty and set this flag in the read-only flash so they can install and use other PCI devices, they should be able to do so. BUG=chrome-os-partner:6148 TEST=none The only way to test this is to use a BIOS that was compiled with serial debugging enabled, so there's nothing for QA to do. If you have such a BIOS, you can see the difference like so: flashrom -r oldbios.bin gbb_utility -s --flags=2 oldbios.bin newbios.bin flashrom -w newbios.bin <reboot> When bit 1 of the GBB flags is 0, you'll see these lines in the serial output: LoadOpRomImage-->GetSystemConfigurationTable Status = Success LoadOpRomImage-->GetH2cBootMode Status = Success When bit 1 of the GBB flags is 1, you'll see these lines in the serial output: LoadOpRomImage-->GetSystemConfigurationTable Status = Success LoadOpRomImage-->GetH2cBootMode Status = Success LoadOpRomImage-->PCI OpRom on 1.0.0 is allowed!!! This happens in any boot mode (normal, developer, recovery). -- *The factory test for GBB zero flags is gft_clear_gbb_flags.sh, in src/platform/factory_test_tools Change-Id: I31a10cc9d562b4b83669ca8a114b60e87ae28b0a Reviewed-on: https://gerrit.chromium.org/gerrit/11505 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Gaurav Shah <gauravsh@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add unit tests for vboot_api_init.cRandall Spangler2011-09-061-0/+273
BUG=chromium-os:17564 TEST=make && make runtests Change-Id: Idca158e82d1ea102221ea3b51d445fadee9d2794 Reviewed-on: http://gerrit.chromium.org/gerrit/7183 Reviewed-by: Luigi Semenzato <semenzato@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
View Lorry Controller Status