summaryrefslogtreecommitdiff
path: root/tests/vboot_api_kernel5_tests.c
Commit message (Collapse)AuthorAgeFilesLines
* vboot: rewrite GBB functions and APIJoel Kitching2019-06-071-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Old vboot1-style GBB accessor functions were awkwardly located within region-init.c. Rewrite GBB accessor functions for vboot2, and formally expose HWID retrieval function via vboot2 API. workbuf is used for key retrieval functions, while a buffer provided by the caller is used for HWID retrieval function. Reintroduce vboot_display_tests to `make runtests` test suite. Move GBB tests from vboot_display_tests to vb2_gbb_tests. Properly propagate vb2_workbuf objects within the function call stack (vb2_load_partition). BUG=b:124141368, chromium:954774 TEST=Build and flash to eve, check that Chrome OS boots TEST=Build with CL:1627469 applied, check HWID TEST=make clean && make runtests BRANCH=none Change-Id: I398d1329f0b092de35aac73d98dfd9aee6e4e7de Signed-off-by: Joel Kitching <kitching@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/vboot_reference/+/1584488 Tested-by: Joel Kitching <kitching@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Commit-Queue: Jason Clinton <jclinton@chromium.org>
* vboot: do not use cparams for VBSDJoel Kitching2019-05-281-18/+13
| | | | | | | | | | | | | | | | | | | | | Pass VbSharedDataHeader struct directly as an argument for the functions VbVerifyMemoryBootImage and VbSelectAndLoadKernel, instead of retrieving from cparams. After any remaining references are removed from depthcharge, the VbCommonParams struct may be deprecated and removed. BUG=b:124141368 TEST=make clean && make runtests BRANCH=none Change-Id: I4dceb539516b62b5817987359705bb8e27ddb6f3 Signed-off-by: Joel Kitching <kitching@google.com> Cq-Depend: chromium:1585505 Reviewed-on: https://chromium-review.googlesource.com/1584489 Commit-Ready: Joel Kitching <kitching@chromium.org> Tested-by: Joel Kitching <kitching@chromium.org> Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Joel Kitching <kitching@chromium.org>
* vboot: save GBB header in workbuf during firmware verificationJoel Kitching2019-05-281-13/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since GBB header will be needed for subsequent GBB reads later on (in kernel verification stage), and since GBB header is relatively small (128 bytes), save the full GBB header onto workbuf during firmware verification stage, and store an offset pointer to it in vb2_shared_data. vb2_gbb_header object may be accessed via the vb2_get_gbb function. Additionally, update functions in firmware/lib/region-init.c to read GBB data from flash, rather than using cparams passed in by depthcharge, which is slated for deprecation. BUG=b:124141368, chromium:954774 TEST=make clean && make runtests BRANCH=none Change-Id: I6e6218231299ce3a5b383663bc3480b20f929840 Signed-off-by: Joel Kitching <kitching@google.com> Cq-Depend: chromium:1585500 Reviewed-on: https://chromium-review.googlesource.com/1627430 Commit-Ready: Joel Kitching <kitching@chromium.org> Tested-by: Joel Kitching <kitching@chromium.org> Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Joel Kitching <kitching@chromium.org>
* vboot: deprecate v1 GoogleBinaryBlockHeader structJoel Kitching2019-05-171-7/+7
| | | | | | | | | | | | | | | | | Deprecate internal usage of GoogleBinaryBlockHeader struct in favour of vb2_gbb_header struct. Keep the v1 struct around until we remove references in other repos. BUG=b:124141368, chromium:954774 TEST=make clean && make runtests BRANCH=none Change-Id: I396d2e624bd5dcac9c461cc86e8175e8f7692d26 Signed-off-by: Joel Kitching <kitching@google.com> Reviewed-on: https://chromium-review.googlesource.com/1583826 Commit-Ready: Joel Kitching <kitching@chromium.org> Tested-by: Joel Kitching <kitching@chromium.org> Reviewed-by: Joel Kitching <kitching@chromium.org>
* vboot: remove workbuf alloc and free codeJoel Kitching2019-04-171-2/+5
| | | | | | | | | | | | | | | | Workbuf should be allocated and free'd by vboot caller. BUG=b:124141368, chromium:951692 TEST=make clean && make runtests CQ-DEPEND=CL:1563872 BRANCH=none Change-Id: Ibaa70f62c660d46cc083a5e55a73b961eb813649 Signed-off-by: Joel Kitching <kitching@google.com> Reviewed-on: https://chromium-review.googlesource.com/1560716 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Joel Kitching <kitching@chromium.org> Reviewed-by: Joel Kitching <kitching@chromium.org>
* vboot: fix vboot_api_kernel_tests after ctx changeJoel Kitching2019-04-131-10/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | CL:1517061 pulled vb2_context storage up to a higher level in the call stack. It also changed vboot_api_kernel{4,5}_tests to use the same context object as that used for VbExNvStorageRead and VbExNvStorageWrite calls. These tests were already initializing the vb2_context workbuf. Since VbSelectAndLoadKernel and VbVerifyMemoryBootImage both initialize the context object internally, ctx.workbuf was being overwritten as part of the call, causing issues later on when calling free(). (See chromium:946970 for more details.) Separate these two context objects to clarify which one is being used as an NVRAM backend, and which one is the classical "context" object passed around in vboot flow. Also remove the NVRAM context's workbuf, since it is not used. BUG=b:124141368, chromium:946970 TEST=make clean && make runtests BRANCH=none Change-Id: Ic1da92ce754e61d4102ca8a6eb9587cd8d9eca10 Signed-off-by: Joel Kitching <kitching@google.com> Reviewed-on: https://chromium-review.googlesource.com/1547711 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Joel Kitching <kitching@chromium.org> Reviewed-by: Joel Kitching <kitching@chromium.org>
* vboot: pull vb2_context up to higher level in call stackJoel Kitching2019-03-261-13/+14
| | | | | | | | | | | | | | | | | | | | | The original purpose of vb2_context is to provide one shared state object through the entirety of one particular application. Pull the creation of vb2_context up to a higher level in order to work towards this goal. BUG=b:124141368 TEST=/work/vboot/src/repohooks/pre-upload.py TEST=make clean && make runtests TEST=make clean && COV=1 make coverage && make coverage_html CQ-DEPEND=CL:1517179 BRANCH=none Change-Id: I7c454afddb2b525895d9945b081b14b29100892c Signed-off-by: Joel Kitching <kitching@google.com> Reviewed-on: https://chromium-review.googlesource.com/1517061 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Joel Kitching <kitching@chromium.org> Reviewed-by: Joel Kitching <kitching@chromium.org>
* 2lib: Add support for 64-byte nvstorage recordRandall Spangler2018-03-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The calling firmware can set ctx->flags VB2_CONTEXT_NVDATA_V2 to tell vboot that nvdata is a 64-byte record instead of a 16-byte record, or equivalently, set the VBSD_NVDATA_V2 flag if calling the old vboot1 API. If calling firmware does not (which is the current coreboot and depthcharge default), then the 16-byte record is used, and V2 fields return explicit default values. Added the fw_max_rollforward V2 field, which defaults to 0xfffffffe on V1. This will be used by a subsequent CL. Added unit tests to verify all that. Added crossystem support, though it will only work with the current 16-byte records until firmware sets the VBSD flag and mosys supports larger records. (Note that because coreboot/depthcharge do not yet set the new context flag, this CL should not change ToT firmware behavior.) See go/vboot-nvstorage for design doc. BUG=chromium:789276 BRANCH=none TEST=make runtests Change-Id: I43072ef153dfa016c051f560892af1fbb3508e3a Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/942031
* firmware: Prune down old region APIRandall Spangler2018-01-091-10/+13
| | | | | | | | | | | | | | | | | | | | | | | | The region API was a way for firmware and kernel verification to get at various blocks of caller-provided data. In practice, we only used it internally as a way to get at parts of the GBB. Prune it down to access only the bits of GBB we still need, from the buffer we already know we have. In the long run we should use the same vb2ex_read_resource() API that vb2 firmware verification does, but that should be done in a follow-up CL since it'll need to be coordinated with support in depthcharge. No change in functionality. BUG=chromium:611535 BRANCH=none TEST=make -j runtests; build bob firmware and boot it Change-Id: I5715cb8d88274164a1a73ed4a56bbd93af46f9bf Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/852798 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* firmware: Include vb1 shared data in vb2 structRandall Spangler2018-01-091-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, firmware verification uses entirely vb2 structs, including vb2_shared_data. This goes through an ugly translation to the old vb1 VbSharedData to pass it to depthcharge. The vboot kernel verification maintains an equally ugly translation back to the vb2 struct internally. Eventually, we want to get rid of all that and use vb2 all the way down to what crossystem picks up from the OS. But before we can do that, we need to finish translating kernel verification code to use the new vb2 structs. This is a step on that path, using vb2_shared_data equivalents where present and hiding the old vb1 shared data struct as a member of vb2_shared_data so at least the vboot functions don't need to pass around cparams to get at it. This will be followed by more CLs which convert more vboot internals to use vb2 structs directly, and eventually coreboot/depthcharge CLs which pass the vb2 structs from firmware verification directly to kernel verification. No change in functionality. BUG=chromium:611535 BRANCH=none TEST=make -j runtests; build bob firmware and boot it Change-Id: I5df8ce81ba3c3ac3f2cb4229db5461757cd89d8d Reviewed-on: https://chromium-review.googlesource.com/852856 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* vboot: Use 2nvstorage instead of vboot_nvstorageRandall Spangler2017-12-111-8/+7
| | | | | | | | | | | | | | | | | | Remove the old vboot1 vboot_nvstorage library (VbNv*() functions) and use the vboot2 library (vb2_nv_*()) instead. This is needed in preparation for moving to 64-byte records; no sense in implementing that change twice... Should be (better be) no change in system behavior. BUG=chromium:789276 BRANCH=none TEST=make runtests compare output of crossystem before/after change (should be identical) Change-Id: I10f9975b0824263064b9a74a3c6daadcecc085d3 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/794732
* vboot: Add vb2_unpack_key_bufferRandall Spangler2016-11-061-1/+1
| | | | | | | | | | | | | | | | | 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-3/+0
| | | | | | | | | | | | | | | | 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
* vboot: use vb2 verification functions for kernel verificationRandall Spangler2016-10-291-30/+45
| | | | | | | | | | | | | 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 standard memcmp, memcpy, memsetRandall Spangler2016-10-231-4/+4
| | | | | | | | | | | | | | 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>
* VbVerifyMemoryBootImage: Allow integrity-only check in dev mode withFurquan Shaikh2015-10-281-0/+17
| | | | | | | | | | | | | | | | | | | 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>
* fastboot: Add routine for verifying kernel image loaded in memoryFurquan Shaikh2015-05-271-0/+281
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>
View Lorry Controller Status