summaryrefslogtreecommitdiff
path: root/src/security/vboot
AgeCommit message (Collapse)Author
2023-06-07mb/google/nissa/var/joxer: Remove VBOOT_GSC_BOARD_ID configReka Norman
Board IDs are now filled in as part of the signing process, so we don't need to set them in coreboot. BUG=b:240620735 TEST=Build and check VBOOT_GSC_BOARD_ID is set to ZZCR. Change-Id: I7dda8ad59046a1dd9a28595e037eda86e91c98df Signed-off-by: Reka Norman <rekanorman@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75641 Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-06vboot: Drop argument to select slot from `vb2ex_ec_protect()`Subrata Banik
vboot code changes have eliminated the redundant call to WP the EC-RO region as protecting RW flash implies protecting both RO and RW flash, so the call to protect RO is redundant. google/rex currently takes about 17 ms to lock down the EC. Along with vboot changes, this patch drops argument to choose between RO and RW slot to protect while calling into `vb2ex_ec_protect()`. It ensures vb2ex_ec_protect() is explicitly meant for protecting RW regions. w/o this patch: 517:waiting for EC to allow higher power draw 846,196 (17,297) w/ this patch: 517:waiting for EC to allow higher power draw 838,258 (9,719) Additionally, update vboot submodule to upstream main to avoid the compilation error. Updating from commit id 35f50c3154e5: Fix build error when compiling without -DNDEBUG to commit id 034907b279c9db: vboot_reference: eliminate redundant call to write protect EC-RO Change-Id: I2974f0cb43ba800c2aaeac4876ebaa052b5ee793 Signed-off-by: Subrata Banik <subratabanik@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75521 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com> Reviewed-by: Harsha B R <harsha.b.r@intel.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2023-04-10security/tpm: make usage of PCRs configurable via KconfigSergii Dmytruk
At this moment, only GBB flags are moved from PCR-0 to PCR-1 when vboot-compatibility is not enabled. Change-Id: Ib3a192d902072f6f8d415c2952a36522b5bf09f9 Ticket: https://ticket.coreboot.org/issues/424 Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68750 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
2023-04-06security/vboot: Don't add RO pagetables to RW_A/BArthur Heymans
Currently this is only used in bootblock and expects a fixed offset. Change-Id: I3c4db6fffe3343f12383fe9585620ffefb01cf81 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74218 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
2023-02-21vboot: Fix reboot loop in recovery with VBOOT_CBFS_INTEGRATIONJakub Czapiga
After first recovery request coreboot would get stuck in bootloop with VB2_RECOVERY_PREAMBLE as recovery reason due to not checking whether coreboot is alread in recovery mode, and calling failing code. Signed-off-by: Jakub Czapiga <jacz@semihalf.com> Change-Id: Idc947a1d150ff6487cf973b36bf4f0af41daa220 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73091 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-02-16vboot: Add VBOOT_ARMV8_CE_SHA256_ACCELERATION configYidi Lin
Add Kconfig option for VBOOT_ARMV8_CE_SHA256_ACCELERATION, which will use ARMv8 Crypto Extension for SHA256[1] instead of software implementation. This will speed up firmware verification in verstage. [1] https://crrev.com/c/4170144 BUG=b:263514393 BRANCH=corsola TEST='calculating body hash (SHA2)' get 13 msecs improvement on Tentacruel. Before: 509:finished calculating body hash (SHA2) 161,548 (14,490) After: 509:finished calculating body hash (SHA2) 155,101 (1,187) Change-Id: I02671338fd9e0deb5294dbb7c03528061edc18c4 Signed-off-by: Yidi Lin <yidilin@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72711 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-13security/vboot: Add store/validate methods for AMD VBIOS FMAP cacheMatt DeVillier
Add methods to store and retrieve the hash of the data stored in the VBIOS cache FMAP region. Add a dedicated index in TPM NVRAM to store the hash, and methods to calculate/read/write it. Modeled after mrc_cache_hash_tpm.{c,h} BUG=b:255812886 TEST=tested with rest of patch train Change-Id: I030017d3bf956b8593bc09073ad6545b80a5b52b Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72401 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-02-05security/vboot: Don't build with flashrom supportBrian Norris
We don't need flashrom support just for vboot payloads. The current default (USE_FLASHROM=1) is mostly harmless, especially if libflashrom is not present (the autodetection in vboot_reference just spits out a pkg-config error but doesn't actually fail the build), but it's better to be clear we don't need it. BUG=b:172225709 TEST=build Change-Id: I53bcc2d1e7666646ddad58ba3717cfdd321014e8 Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72716 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2023-01-13security/vboot: Check RW_NVRAM at buildtimeArthur Heymans
This avoids runtime failures of lacking a RW_NVRAM section in fmap or one having a size too small. Change-Id: I3415bd719428a23b21210eb2176dbe15fa44eb9c Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/71868 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2022-12-28src/security/vboot: Fix wrong CONFIG nameMaximilian Brune
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: I2af3bc9bf9eaf258b9180da5fc5494b21764f379 Reviewed-on: https://review.coreboot.org/c/coreboot/+/71518 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-12-21security/vboot: Drop assert call from vbnv_udc_enable_flag()Sridhar Siricilla
It's true that vbnv_udc_enable_flag() is called after vbnv_init() (that's why the assertion was added). However, the former is called in the ramstage, while the latter in verstage. This means that vbnv_initialized will be false in ramstage, which leads to the assertion failure: [EMERG] ASSERTION ERROR: file 'src/security/vboot/vbnv.c', line 88 Since the ctx->nvdata will be restored in ramstage (by vb2api_reinit()), simply remove the assertion. So, the patch drops assert call from vbnv_udc_enable_flag() function. TEST=Verify Rex system boots to OS without assert error. Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com> Change-Id: I49022155239febd5c5be5cf2c5eca2019ca61c12 Reviewed-on: https://review.coreboot.org/c/coreboot/+/71097 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2022-12-16security/vboot: Update vbnv_init signatureKarthikeyan Ramasubramanian
If the temporary nvdata storage inside the vboot context is already initialized then return immediately without reinitializing from the backup NV storage. This allows vbnv_init to be called more than once. Also the check to enable USB Device Controller (UDC) happens after NVdata is initialized. Hence the nvdata in vboot context can be used instead of reading from the backup storage again. BUG=b:242825052 TEST=Build Skyrim BIOS image and boot to OS in Skyrim. Change-Id: Id72709e2fc3fe6a12ee96df8df25e55cf11e50a7 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70380 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-12-07vboot: Force config file inclusion with CBFS integrationJulius Werner
CONFIG_VBOOT_CBFS_INTEGRATION images are signed differently than normal images. futility needs to be able to tell this difference, and it parses the `config` file included in CBFS to do this. This change codifies that dependency in Kconfig so that nobody can accidentally break this by turning off config file inclusion. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I2b2d245b850bc65abb4e72f20b4e360312c828f7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/70157 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Jakub Czapiga <jacz@semihalf.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-12-01vboot: Allow for comparison of hash without zero-paddingJakub Czapiga
Adjust asserts to allow to store and compare (at S3 resume) hashes without padding to maximum hash length / slot size. Signed-off-by: Jakub Czapiga <jacz@semihalf.com> Change-Id: If6d46e0b58dbca86af56221b7ff2606ab2d1799a Reviewed-on: https://review.coreboot.org/c/coreboot/+/69762 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2022-12-01vboot/vboot_common: Fix vboot_save_data() code exclusion guardJakub Czapiga
Compilers are not optimizing-out code correctly. This patch fixes incorrect behavior by splitting if statement and extracting code to another function, this allowing for better code size optimization and reduction of undefined references. Signed-off-by: Jakub Czapiga <jacz@semihalf.com> Change-Id: Ia5330efeeb4cfd7477cf8f7f64c6abed68281e30 Reviewed-on: https://review.coreboot.org/c/coreboot/+/69761 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-11-30/: Remove extra space after commaElyes Haouas
Change-Id: Ic64625bdaf8c4e9f8a5c1c22cece7f4070012da7 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69903 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-11-22security: Remove unnecessary space after castsElyes Haouas
Change-Id: Ibd41382d0e0ef58498ac925dc9e10b54a76a798a Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69800 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-11-12ec/google/chromeec: Deprecate dev_index from google_chromeec_rebootCaveh Jalali
This removes the dev_index argument from the google_chromeec_reboot API. It's always set to 0, so don't bother passing it. BUG=b:258126464 BRANCH=none TEST=none Change-Id: Iadc3d7c6c1e048e4b1ab8f8cec3cb8eb8db38e6a Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69373 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-11-08vboot: Add VBOOT_CBFS_INTEGRATION supportJakub Czapiga
This patch introduces support signing and verification of firmware slots using CBFS metadata hash verification method for faster initial verification. To have complete verification, CBFS_VERIFICATION should also be enabled, as metadata hash covers only files metadata, not their contents. This patch also adapts mainboards and SoCs to new vboot reset requirements. TEST=Google Volteer/Voxel boots with VBOOT_CBFS_INTEGRATION enabled Signed-off-by: Jakub Czapiga <jacz@semihalf.com> Change-Id: I40ae01c477c4e4f7a1c90e4026a8a868ae64b5ca Reviewed-on: https://review.coreboot.org/c/coreboot/+/66909 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-11-08vboot: Introduce handy vboot reboot functionsJakub Czapiga
This patch groups vboot context, recovery reason and subcode saving, and reboot calls into two handy functions: - vboot_save_and_reboot() - save context and reboot - vboot_fail_and_reboot() - store recovery reason and call function above Signed-off-by: Jakub Czapiga <jacz@semihalf.com> Change-Id: Ie29410e8985e7cf19bd8d4cccc393b050ca1f1c5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/69208 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2022-11-07security/vboot: Update build rules using x86 SHA extensionKarthikeyan Ramasubramanian
Currently build rules allow using x86 SHA extensions for all coreboot stages when enabled. On some SoCs where verstage can run in non-x86 environment, x86 SHA extension cannot be used. Update build rules accordingly such that x86 SHA extensions can be used in AMD SoCs. This is particularly useful when CBFS verificiation is enabled which verifies the hash of the CBFS file being loaded. BUG=b:227809919 TEST=Build and boot to OS in Skyrim. Observe that hardware acceleration is used when a CBFS file is loaded and observe an overall improvement of 10 ms. Change-Id: I4f388e963eb82990cda41d3880e66ad937334908 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68953 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kangheui Won <khwon@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2022-09-17security/vboot: Add rollback NVRAM space for TPM 2Miriam Polzer
Create an NVRAM space in TPM 2.0 that survives owner clear and can be read and written without authorization. This space allows to seal data with the TPM that can only be unsealed before the space was cleared. It will be used during ChromeOS enterprise rollback to securely carry data across a TPM clear. Public documentation on the rollback feature: https://source.chromium.org/chromium/chromiumos/platform2/+/main:oobe_config/README.md BUG=b/233746744 Signed-off-by: Miriam Polzer <mpolzer@google.com> Change-Id: I59ca0783b41a6f9ecd5b72f07de6fb403baf2820 Reviewed-on: https://review.coreboot.org/c/coreboot/+/66623 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-09-15src/security: Use "if (!ptr)" in preference to "if (ptr == NULL)"Elyes Haouas
Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: I3def65c016015d8213824e6b8561d8a67b6d5cf0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/67579 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2022-09-14timer: Change timer util functions to 64-bitRob Barnes
Since mono_time is now 64-bit, the utility functions interfacing with mono_time should also be 64-bit so precision isn't lost. Fixed build errors related to printing the now int64_t result of stopwatch_duration_[m|u]secs in various places. BUG=b:237082996 BRANCH=All TEST=Boot dewatt Change-Id: I169588f5e14285557f2d03270f58f4c07c0154d5 Signed-off-by: Rob Barnes <robbarnes@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66170 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2022-09-04security/vboot/tpm: Avoid duplicate vb2api_secdata_firmware_create callsYu-Ping Wu
For TPM2, vb2api_secdata_firmware_create() is already called from setup_firmware_space() from _factory_initialize_tpm(). Therefore move the duplicate call from factory_initialize_tpm() to TPM1's _factory_initialize_tpm(). Change-Id: I892df65c847e1aeeabef8a7578bec743b639a127 Signed-off-by: Yu-Ping Wu <yupingso@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67219 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aseda Aboagye <aaboagye@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-09-03soc/intel: Add SI_DESC region to GSCVD rangesJulius Werner
Intel platforms have soft straps stored in the SI_DESC FMAP section which can alter boot behavior and may open up a security risk if they can be modified by an attacker. This patch adds the SI_DESC region to the list of ranges covered by GSC verification (CONFIG_VBOOT_GSCVD). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I0f1b297e207d3c6152bf99ec5a5b0983f01b2d0b Reviewed-on: https://review.coreboot.org/c/coreboot/+/66346 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-09-02cbfs/vboot: Adapt to new vb2_digest APIJulius Werner
CL:3825558 changes all vb2_digest and vb2_hash functions to take a new hwcrypto_allowed argument, to potentially let them try to call the vb2ex_hwcrypto API for hash calculation. This change will open hardware crypto acceleration up to all hash calculations in coreboot (most notably CBFS verification). As part of this change, the vb2_digest_buffer() function has been removed, so replace existing instances in coreboot with the newer vb2_hash_calculate() API. Due to the circular dependency of these changes with vboot, this patch also needs to update the vboot submodule: Updating from commit id 18cb85b5: 2load_kernel.c: Expose load kernel as vb2_api to commit id b827ddb9: tests: Ensure auxfw sync runs after EC sync This brings in 15 new commits. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I287d8dac3c49ad7ea3e18a015874ce8d610ec67e Reviewed-on: https://review.coreboot.org/c/coreboot/+/66561 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
2022-08-22Add SBOM (Software Bill of Materials) GenerationMaximilian Brune
Firmware is typically delivered as one large binary image that gets flashed. Since this final image consists of binaries and data from a vast number of different people and companies, it's hard to determine what all the small parts included in it are. The goal of the software bill of materials (SBOM) is to take a firmware image and make it easy to find out what it consists of and where those pieces came from. Basically, this answers the question, who supplied the code that's running on my system right now? For example, buyers of a system can use an SBOM to perform an automated vulnerability check or license analysis, both of which can be used to evaluate risk in a product. Furthermore, one can quickly check to see if the firmware is subject to a new vulnerability included in one of the software parts (with the specified version) of the firmware. Further reference: https://web.archive.org/web/20220310104905/https://blogs.gnome.org/hughsie/2022/03/10/firmware-software-bill-of-materials/ - Add Makefile.inc to generate and build coswid tags - Add templates for most payloads, coreboot, intel-microcode, amd-microcode. intel FSP-S/M/T, EC, BIOS_ACM, SINIT_ACM, intel ME and compiler (gcc,clang,other) - Add Kconfig entries to optionally supply a path to CoSWID tags instead of using the default CoSWID tags - Add CBFS entry called SBOM to each build via Makefile.inc - Add goswid utility tool to generate SBOM data Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: Icb7481d4903f95d200eddbfed7728fbec51819d0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/63639 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2022-07-30security/vboot: Simplify image signingJakub Czapiga
futility now supports image truncation and signing of whole images with a single command invocation. Use it for vboot-enabled coreboot images. TEST=Build and run coreboot on google/volteer Signed-off-by: Jakub Czapiga <jacz@semihalf.com> Change-Id: I49eb7e977b635ccb9f6c1b76e53c36e82be1d795 Reviewed-on: https://review.coreboot.org/c/coreboot/+/66127 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2022-07-04treewide: Unify Google brandingJon Murphy
Branding changes to unify and update Chrome OS to ChromeOS (removing the space). This CL also includes changing Chromium OS to ChromiumOS as well. BUG=None TEST=N/A Change-Id: I39af9f1069b62747dbfeebdd62d85fabfa655dcd Signed-off-by: Jon Murphy <jpmurphy@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65479 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2022-06-22security/vboot: Deprecate VBOOT_VBNV_ECYu-Ping Wu
Boards using VBOOT_VBNV_EC (nyan, daisy, veyron, peach_pit) are all ChromeOS devices and they've reached the end of life since Feb 2022. Therefore, remove VBOOT_VBNV_EC for them, each with different replacement. - nyan (nyan, nyan_big, nyan_blaze): Add RW_NVRAM to their FMAP (by reducing the size of RW_VPD), and replace VBOOT_VBNV_EC with VBOOT_VBNV_FLASH. - veyron: Add RW_NVRAM to their FMAP (by reducing the size of SHARED_DATA), and replace VBOOT_VBNV_EC with VBOOT_VBNV_FLASH. Also enlarge the OVERLAP_VERSTAGE_ROMSTAGE section for rk3288 (by reducing the size of PRERAM_CBMEM_CONSOLE), so that verstage won't exceed its allotted size. - daisy: Because BOOT_DEVICE_SPI_FLASH is not set, which is required for VBOOT_VBNV_FLASH, disable MAINBOARD_HAS_CHROMEOS and VBOOT configs. - peach_pit: As VBOOT is not set, simply remove the unused VBOOT_VBNV_EC option. Remove the VBOOT_VBNV_EC Kconfig option as well as related code, leaving VBOOT_VBNV_FLASH and VBOOT_VBNV_CMOS as the only two backend options for vboot nvdata (VBNV). Also add a check in read_vbnv() and save_vbnv() for VBNV options. BUG=b:178689388 TEST=util/abuild/abuild -t GOOGLE_NYAN -x -a TEST=util/abuild/abuild -t GOOGLE_VEYRON_JAQ -x -a TEST=util/abuild/abuild -t GOOGLE_DAISY -a TEST=util/abuild/abuild -t GOOGLE_PEACH_PIT -a BRANCH=none Change-Id: Ic67d69e694cff3176dbee12d4c6311bc85295863 Signed-off-by: Yu-Ping Wu <yupingso@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65012 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-06-21security/vboot: Add support for GSCVD (Google "RO verification")Julius Werner
This patch adds a new CONFIG_VBOOT_GSCVD option that will be enabled by default for TPM_GOOGLE_TI50 devices. It makes the build system run the `futility gscvd` command to create a GSCVD (GSC verification data) which signs the CBFS trust anchor (bootblock and GBB). In order for this to work, boards will need to have an RO_GSCVD section in their FMAP, and production boards should override the CONFIG_VBOOT_GSC_BOARD_ID option with the correct ID for each variant. BUG=b:229015103 Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I1cf86e90b2687e81edadcefa5a8826b02fbc8b24 Reviewed-on: https://review.coreboot.org/c/coreboot/+/64707 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2022-05-20CBMEM: Change declarations for initialization hooksKyösti Mälkki
There are efforts to have bootflows that do not follow a traditional bootblock-romstage-postcar-ramstage model. As part of that CBMEM initialisation hooks will need to move from romstage to bootblock. The interface towards platforms and drivers will change to use one of CBMEM_CREATION_HOOK() or CBMEM_READY_HOOK(). Former will only be called in the first stage with CBMEM available. Change-Id: Ie24bf4e818ca69f539196c3a814f3c52d4103d7e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63375 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-05-12Makefile.inc: Generate master header and pointer as C structsArthur Heymans
The makefiles don't like cbfs file names with spaces in them so update the file name with '_' instead of spaces. To keep the master header at the top of cbfs, add a placeholder. This removes the need to handle the cbfs master header in cbfstool. This functionality will be dropped in a later CL. On x86 reserve some space in the linker script to add the pointer. On non-x86 generate a pointer inside a C struct file. As a bonus this would actually fix the master header pointer mechanism on Intel/APL as only the bootblock inside IFWI gets memory mapped. TESTED on thinkpad X201: SeaBIOS correctly finds the cbfs master header. Change-Id: I3ba01be7da1f09a8cac287751497c18cda97d293 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/59132 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-04-21tpm: Refactor TPM Kconfig dimensionsJes B. Klinke
Break TPM related Kconfig into the following dimensions: TPM transport support: config CRB_TPM config I2C_TPM config SPI_TPM config MEMORY_MAPPED_TPM (new) TPM brand, not defining any of these is valid, and result in "generic" support: config TPM_ATMEL (new) config TPM_GOOGLE (new) config TPM_GOOGLE_CR50 (new, implies TPM_GOOGLE) config TPM_GOOGLE_TI50 (new to be used later, implies TPM_GOOGLE) What protocol the TPM chip supports: config MAINBOARD_HAS_TPM1 config MAINBOARD_HAS_TPM2 What the user chooses to compile (restricted by the above): config NO_TPM config TPM1 config TPM2 The following Kconfigs will be replaced as indicated: config TPM_CR50 -> TPM_GOOGLE config MAINBOARD_HAS_CRB_TPM -> CRB_TPM config MAINBOARD_HAS_I2C_TPM_ATMEL -> I2C_TPM && TPM_ATMEL config MAINBOARD_HAS_I2C_TPM_CR50 -> I2C_TPM && TPM_GOOGLE config MAINBOARD_HAS_I2C_TPM_GENERIC -> I2C_TPM && !TPM_GOOGLE && !TPM_ATMEL config MAINBOARD_HAS_LPC_TPM -> MEMORY_MAPPED_TPM config MAINBOARD_HAS_SPI_TPM -> SPI_TPM && !TPM_GOOGLE && !TPM_ATMEL config MAINBOARD_HAS_SPI_TPM_CR50 -> SPI_TPM && TPM_GOOGLE Signed-off-by: Jes B. Klinke <jbk@chromium.org> Change-Id: I4656b2b90363b8dfd008dc281ad591862fe2cc9e Reviewed-on: https://review.coreboot.org/c/coreboot/+/63424 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-03-09commonlib/bsd: Remove cb_err_tJulius Werner
cb_err_t was meant to be used in place of `enum cb_err` in all situations, but the choice to use a typedef here seems to be controversial. We should not be arbitrarily using two different identifiers for the same thing across the codebase, so since there are no use cases for serializing enum cb_err at the moment (which would be the primary reason to typedef a fixed-width integer instead), remove cb_err_t again for now. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Iaec36210d129db26d51f0a105d3de070c03b686b Reviewed-on: https://review.coreboot.org/c/coreboot/+/62600 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2022-03-08timestamps: Rename timestamps to make names more consistentJakub Czapiga
This patch aims to make timestamps more consistent in naming, to follow one pattern. Until now there were many naming patterns: - TS_START_*/TS_END_* - TS_BEFORE_*/TS_AFTER_* - TS_*_START/TS_*_END This change also aims to indicate, that these timestamps can be used to create time-ranges, e.g. from TS_BOOTBLOCK_START to TS_BOOTBLOCK_END. Signed-off-by: Jakub Czapiga <jacz@semihalf.com> Change-Id: I533e32392224d9b67c37e6a67987b09bf1cf51c6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62019 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-01-13console/cbmem_console: Rename cbmem_dump_consoleRaul E Rangel
This function actually dumps cbmem to the UART. This change renames the function to make that clear. BUG=b:213828947 TEST=Build guybrush Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Icc314c530125e5303a06b92aab48c1e1122fd18c Reviewed-on: https://review.coreboot.org/c/coreboot/+/61010 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-12-16Revert "security/vboot: Add NVRAM counter for TPM 2.0"Tim Wawrzynczak
This reverts commit 7dce19080889955576f8fd197658077aced96a96. Reason for revert: Unable to boot in factory mode Change-Id: I1b51010080164c6e28d77a932f77c10006fd4153 Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60030 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2021-12-06cbfs: Remove deprecated APIsJulius Werner
This patch removes all remaining pieces of the old CBFS API, now that the last straggling use cases of it have been ported to the new one (meaning cbfs_map()/cbfs_load()/etc... see CB:39304 and CB:38421). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I1cec0ca2d9d311626a087318d1d78163243bfc3c Reviewed-on: https://review.coreboot.org/c/coreboot/+/59682 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2021-12-03src/security/vboot: Set up secure counter space in TPM NVRAMKarthikeyan Ramasubramanian
High Definition (HD) protected content playback requires secure counters that are updated at regular interval while the protected content is playing. To support similar use-cases, define space for secure counters in TPM NVRAM and initialize them. These counters are defined once during the factory initialization stage. Also add VBOOT_DEFINE_WIDEVINE_COUNTERS config item to enable these secure counters only on the mainboard where they are required/used. BUG=b:205261728 TEST=Build and boot to OS in guybrush. Ensure that the secure counters are defined successfully in TPM NVRAM space. tlcl_define_space: response is 0 tlcl_define_space: response is 0 tlcl_define_space: response is 0 tlcl_define_space: response is 0 On reboot if forced to redefine the space, it is identified as already defined. tlcl_define_space: response is 14c define_space():219: define_space: Secure Counter space already exists tlcl_define_space: response is 14c define_space():219: define_space: Secure Counter space already exists tlcl_define_space: response is 14c define_space():219: define_space: Secure Counter space already exists tlcl_define_space: response is 14c define_space():219: define_space: Secure Counter space already exists Change-Id: I915fbdada60e242d911b748ad5dc28028de9b657 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/59476 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-11-19security/vboot: Add NVRAM counter for TPM 2.0Miriam Polzer
Create an NVRAM counter in TPM 2.0 that survives owner clear and can be read and written without authorization. This counter allows to seal data with the TPM that can only be unsealed before the counter was incremented. It will be used during Chrome OS rollback to securely carry data across a TPM clear. Signed-off-by: Miriam Polzer <mpolzer@google.com> Change-Id: I511dba3b3461713ce20fb2bda9fced0fee6517e1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/59097 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-11-17security/vboot: Use default kernel secdata sizeTim Wawrzynczak
When fetching antirollback information for the kernel, it is not always known ahead of time what the current size of the kernel secdata area is. If the incorrect size is passed, the TPM will return back the correct size, but at the cost of an extra transaction; when using cr50 over I2C, this can be as much as 20ms. Currently, the first attempt uses the minimium size (aka version 0 or 0.2), and if another size is used (which is the case for all modern cr50-based boards, version 1 or 1.0), then a transaction is wasted on every boot. Therefore, change the default size sent to the TPM to be the default one used in the VB2 API instead of the minimum one. BUG=b:201304784 TEST=verify TPM initialization time drops by ~20ms. Also the Kernel NV Index is read correctly in the BIOS logs. src/security/tpm/tss/tcg-2.0/tss.c:231 index 0x1007 return code 0 src/security/tpm/tss/tcg-2.0/tss.c:231 index 0x1008 return code 0 504:finished TPM initialization 99,953 (65,606) Change-Id: I22d9c0079bb1175f24ff7317d116e79aa5ba08ed Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58669 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-11-15Reland "vboot_logic: Set VB2_CONTEXT_EC_TRUSTED in verstage_main"Hsuan-ting Chen
This reverts commit adb393bdd6cd6734fa2672bd174aca4588a68016. This relands commit 6260bf712a836762b18d80082505e981e040f4bc. Reason for revert: The original CL did not handle some devices correctly. With the fixes: * commit 36721a4 (mb/google/brya: Add GPIO_IN_RW to all variants' early GPIO tables) * commit 3bfe46c (mb/google/guybrush: Add GPIO EC in RW to early GPIO tables) * commit 3a30cf9 (mb/google/guybrush: Build chromeos.c in verstage This CL also fix the following platforms: * Change to always trusted: cyan. * Add to early GPIO table: dedede, eve, fizz, glados, hatch, octopus, poppy, reef, volteer. * Add to both Makefile and early GPIO table: zork. For mb/intel: * adlrvp: Add support for get_ec_is_trusted(). * glkrvp: Add support for get_ec_is_trusted() with always trusted. * kblrvp: Add support for get_ec_is_trusted() with always trusted. * kunimitsu: Add support for get_ec_is_trusted() and initialize it as early GPIO. * shadowmountain: Add support for get_ec_is_trusted() and initialize it as early GPIO. * tglrvp: Add support for get_ec_is_trusted() with always trusted. For qemu-q35: Add support for get_ec_is_trusted() with always trusted. We could attempt another land. Change-Id: I66b8b99d6e6bf259b18573f9f6010f9254357bf9 Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58253 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2021-10-15Revert "vboot_logic: Set VB2_CONTEXT_EC_TRUSTED in verstage_main"Hsuan-ting Chen
This reverts commit 6260bf712a836762b18d80082505e981e040f4bc. Reason for revert: This CL did not handle Intel GPIO correctly. We need to add GPIO_EC_IN_RW into early_gpio_table for platforms using Intel SoC. Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org> Change-Id: Iaeb1bf598047160f01e33ad0d9d004cad59e3f75 Reviewed-on: https://review.coreboot.org/c/coreboot/+/57951 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-10-07security/vboot: Remove vb2ex_hwcrypto stubsYu-Ping Wu
Now that the vb2ex_hwcrypto_* stub functions are included in vboot fwlib (CL:2353775), we can remove the same stubs from coreboot. BUG=none TEST=emerge-brya coreboot TEST=emerge-cherry coreboot BRANCH=none Change-Id: I62bdc647eb3e34c581cc1b8d15e7f271211e6156 Signed-off-by: Yu-Ping Wu <yupingso@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58095 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2021-09-16vboot_logic: Set VB2_CONTEXT_EC_TRUSTED in verstage_mainHsuan Ting Chen
vboot_reference is introducing a new field (ctx) to store the current boot mode in crrev/c/2944250 (ctx->bootmode), which will be leveraged in both vboot flow and elog_add_boot_reason in coreboot. In current steps of deciding bootmode, a function vb2ex_ec_trusted is required. This function checks gpio EC_IN_RW pin and will return 'trusted' only if EC is not in RW. Therefore, we need to implement similar utilities in coreboot. We will deprecate vb2ex_ec_trusted and use the flag, VB2_CONTEXT_EC_TRUSTED, in vboot, vb2api_fw_phase1 and set that flag in coreboot, verstage_main. Also add a help function get_ec_is_trusted which needed to be implemented per mainboard. BUG=b:177196147, b:181931817 BRANCH=none TEST=Test on trogdor if manual recovery works Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org> Change-Id: I479c8f80e45cc524ba87db4293d19b29bdfa2192 Reviewed-on: https://review.coreboot.org/c/coreboot/+/57048 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-09-15vboot: Call check_boot_mode before vb2api_fw_phase1Daisuke Nojiri
Currently, check_boot_mode is called after vb2api_fw_phase1, which makes verstage_main exit before reaching check_boot_mode if recovery mode is manually requested. Thus, recovery mode isn't able to test whether VB2_CONTEXT_EC_TRUSTED is set or not. This patch makes verstage_main call check_boot_mode before vb2api_fw_phase1 to fix the issue. BUG=b:180927027, b:187871195 BRANCH=none TEST=build Change-Id: If8524d1513b13fd79320a116a83f6729a820f61f Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57623 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-07-26vboot/secdata_tpm: Add WRITE_STCLEAR attr to RW ARB spacesAseda Aboagye
It can be nice to update the TPM firmware without having to clear the TPM owner. However, in order to do so would require platformHierarchy to be enabled which would leave the kernel antirollback space a bit vulnerable. To protect the kernel antirollback space from being written to by the OS, we can use the WriteLock command. In order to do so we need to add the WRITE_STCLEAR TPM attribute. This commit adds the WRITE_STCLEAR TPM attribute to the rw antirollback spaces. This includes the kernel antirollback space along with the MRC space. When an STCLEAR attribute is set, this indicates that the TPM object will need to be reloaded after any TPM Startup (CLEAR). BUG=b:186029006 BRANCH=None TEST=Build and flash a chromebook with no kernel antirollback space set up, boot to Chrome OS, run `tpm_manager_client get_space_info --index=0x1007` and verify that the WRITE_STCLEAR attribute is present. Signed-off-by: Aseda Aboagye <aaboagye@google.com> Change-Id: I3181b4c18acd908e924ad858b677e891312423fe Reviewed-on: https://review.coreboot.org/c/coreboot/+/56358 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-07-01vboot: add VBOOT_X86_SHA256_ACCELERATION configSubrata Banik
Add Kconfig option for VBOOT_X86_SHA256_ACCELERATION, which will use x86-sha extension for SHA256 instead of software implementation. TEST=Able to call vb2ex_hwcrypto_digest_init() and perform SHA using HW crypto engine. Change-Id: Idc8be8711c69f4ebc489cd37cc3749c0b257c610 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55611 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-06-14security/vboot: Add timestamps when loading verstageRaul E Rangel
We are not currently tracking how long it takes to load verstage. The enum values already exist, they just weren't used. BUG=b:179092979 TEST=Dump timestamps 501:starting to load verstage 2,280,656 (1) 502:finished loading verstage 2,340,845 (60,189) Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I2cde58cb8aa796829a4e054e6925e2394973484b Reviewed-on: https://review.coreboot.org/c/coreboot/+/55370 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-06-10security/vboot: Add support for ZTE spacesAseda Aboagye
This commit adds support for the Chrome OS Zero-Touch Enrollment related spaces. For TPM 2.0 devices which don't use Cr50, coreboot will define the RMA+SN Bits, Board ID, and RMA Bytes counter spaces. The RMA+SN Bits space is 16 bytes initialized to all 0xFFs. The Board ID space is 12 bytes initialized to all 0xFFs. The RMA Bytes counter space is 8 bytes intialized to 0. BUG=b:184676425 BRANCH=None TEST=Build and flash lalala, verify that the ZTE spaces are created successfully by undefining the firmware antirollback space in the TPM such that the TPM undergoes factory initialization in coreboot. Reboot the DUT. Boot to CrOS and run `tpm_manager_client list_spaces` and verify that the ZTE spaces are listed. Run `tpm_manager_client read_space` with the various indices and verify that the sizes and initial values of the spaces are correct. TEST=Attempt to undefine the ZTE spaces and verify that it fails due to the unsatisfiable policy. Signed-off-by: Aseda Aboagye <aaboagye@google.com> Change-Id: I97e3ae7e18fc9ee9a02afadbbafeb226b41af0eb Reviewed-on: https://review.coreboot.org/c/coreboot/+/55242 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-06-10vboot: Assign 2 to EC_EFS_BOOT_MODE_TRUSTED_RODaisuke Nojiri
This patch assings 2 to EC_EFS_BOOT_MODE_TRUSTED_RO to make coreboot set VB2_CONTEXT_EC_TRUSTED when the GSC reports TRUSTED_RO. Old GSC doesn't use 2. So, the new BIOS won't mistakenly set VB2_CONTEXT_EC_TRUSTED. BUG=b:180927027, b:187871195 BRANCH=none TEST=build Change-Id: I11a09d0035a4bd59f80018c647ca17e3318be81e Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55373 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-06-04vboot: Add VB2_CONTEXT_EC_TRUSTEDDaisuke Nojiri
This patch makes coreboot set VB2_CONTEXT_EC_TRUSTED based on the EC"s boot mode. Vboot will check VB2_CONTEXT_EC_TRUSTED to determine whether it can enter recovery mode or not. BUG=b:180927027, b:187871195 BRANCH=none TEST=build Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Change-Id: I9fa09dd7ae5baa1efb4e1ed4f0fe9a6803167c93 Reviewed-on: https://review.coreboot.org/c/coreboot/+/54099 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-05-30Apply more uses for Kconfig TPMKyösti Mälkki
Change-Id: I54b296563940cd46fe9da9fe789b746f2fc1987d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55016 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2021-05-26Add Kconfig TPMKyösti Mälkki
Defined as TPM1 || TPM2. Change-Id: I18c26d6991c2ccf782a515a8e90a3eb82b53b0e6 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/54853 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2021-05-18vboot/secdata_mock: Make v0 kernel secdata contextAseda Aboagye
The new kernel secdata v1 stores the last read EC hash, and reboots the device during EC software sync when that hash didn't match the currently active hash on the EC (this is used with TPM_CR50 to support EC-EFS2 and pretty much a no-op for other devices). Generally, of course the whole point of secdata is always that it persists across reboots, but with MOCK_SECDATA we can't do that. Previously we always happened to somewhat get away with presenting freshly-reinitialized data for MOCK_SECDATA on every boot, but with the EC hash feature in secdata v1, that would cause a reboot loop. The simplest solution is to just pretend we're a secdata v0 device when using MOCK_SECDATA. This was encountered on using a firmware built with MOCK_SECDATA but had EC software sync enabled. BUG=b:187843114 BRANCH=None TEST=`USE=mocktpm cros build-ap -b keeby`; Flash keeby device, verify that DUT does not continuously reboot with EC software sync enabled. Signed-off-by: Aseda Aboagye <aaboagye@google.com> Change-Id: Id8e81afcddadf27d9eec274f7f85ff1520315aaa Reviewed-on: https://review.coreboot.org/c/coreboot/+/54304 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-05-16vboot/secdata_tpm: Create FWMP space in corebootAseda Aboagye
This commit has coreboot create the Chrome OS Firmware Management Parameters (FWMP) space in the TPM. The space will be defined and the contents initialized to the defaults. BUG=b:184677625 BRANCH=None TEST=emerge-keeby coreboot Signed-off-by: Aseda Aboagye <aaboagye@google.com> Change-Id: I1f566e00f11046ff9a9891c65660af50fbb83675 Reviewed-on: https://review.coreboot.org/c/coreboot/+/52919 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Andrey Pronin <apronin@chromium.org>
2021-05-16vboot/secdata_tpm: Rename set_space()Aseda Aboagye
The name `set_space()` seems to imply that it's writing to a TPM space when actually, the function can create a space and write to it. This commit attempts to make that a bit more clear. Additionally, in order to use the correct sizes when creating the space, this commit also refactors the functions slightly to incorporate the vboot context object such that the correct sizes are used. The various vboot APIs will return the size of the created object that we can then create the space with. BUG=b:184677625 BRANCH=None TEST=`emerge-keeby coreboot` Signed-off-by: Aseda Aboagye <aaboagye@google.com> Change-Id: I80a8342c51d7bfaa0cb2eb3fd37240425d5901be Reviewed-on: https://review.coreboot.org/c/coreboot/+/54308 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-05-14cbfs: Increase mcache size defaultsJulius Werner
The CBFS mcache size default was eyeballed to what should be "hopefully enough" for most users, but some recent Chrome OS devices have already hit the limit. Since most current (and probably all future) x86 chipsets likely have the CAR space to spare, let's just double the size default for all supporting chipsets right now so that we hopefully won't run into these issues again any time soon. The CBFS_MCACHE_RW_PERCENTAGE default for CHROMEOS was set to 25 under the assumption that Chrome OS images have historically always had a lot more files in their RO CBFS than the RW (because l10n assets were only in RO). Unfortunately, this has recently changed with the introduction of updateable assets. While hopefully not that many boards will need these, the whole idea is that you won't know whether you need them yet at the time the RO image is frozen, and mcache layout parameters cannot be changed in an RW update. So better to use the normal 50/50 split on Chrome OS devices going forward so we are prepared for the eventuality of needing RW assets again. The RW percentage should really also be menuconfig-controllable, because this is something the user may want to change on the fly depending on their payload requirements. Move the option to the vboot Kconfigs because it also kinda belongs there anyway and this makes it fit in better in menuconfig. (I haven't made the mcache size menuconfig-controllable because if anyone needs to increase this, they can just override the default in the chipset Kconfig for everyone using that chipset, under the assumption that all boards of that chipset have the same amount of available CAR space and there's no reason not to use up the available space. This seems more in line with how this would work on non-x86 platforms that define this directly in their memlayout.ld.) Also add explicit warnings to both options that they mustn't be changed in an RW update to an older RO image. BUG=b:187561710 Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I046ae18c9db9a5d682384edde303c07e0be9d790 Reviewed-on: https://review.coreboot.org/c/coreboot/+/54146 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2021-05-04security/vboot: Include fspt.bin in the RO region onlyArthur Heymans
fspt.bin is run before verstage so it is of no use in RW_A/B. Change-Id: I6fe29793fa638312c8b275b6fa8662df78b3b2bd Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/52853 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2021-04-14vboot: ec_sync: Switch to new CBFS APIJulius Werner
This patch changes the vboot EC sync code to use the new CBFS API. As a consequence, we have to map the whole EC image file at once (because the new API doesn't support partial mapping). This should be fine on the only platform that uses this code (Google_Volteer/_Dedede family) because they are x86 devices that support direct mapping from flash, but the code was originally written to more carefully map the file in smaller steps to be theoretically able to support Arm devices. EC sync in romstage for devices without memory-mapped flash would be hard to combine with CBFS verification because there's not enough SRAM to ever hold the whole file in memory at once, but we can't validate the file hash until we have loaded the whole file and for performance (or TOCTOU-safety, if applicable) reasons we wouldn't want to load anything more than once. The "good" solution for this would be to introduce a CBFS streaming API can slowly feed chunks of the file into a callback but in the end still return a "hash valid/invalid" result to the caller. If use cases like this become pressing in the future, we may have to implement such an API. However, for now this code is the only part of coreboot with constraints like that, it was only ever used on platforms that do support memory-mapped flash, and due to the new EC-EFS2 model used on more recent Chrome OS devices we don't currently anticipate this to ever be needed again. Therefore this patch goes the easier way of just papering over the problem and punting the work of implementing a more generic solution until we actually have a real need for it. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I7e263272aef3463f3b2924887d96de9b2607f5e5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/52280 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-04-06verstage: Add debug print when returning from verstageJulius Werner
RETURN_FROM_VERSTAGE is a somewhat tricky construct that we don't normally do otherwise in coreboot. While it works remarkably well in general, new development can lead to unintentional interactions with confusing results. This patch adds a debug print to the verstage right before returning to the bootblock so that it's obvious this happens, because otherwise in some cases the last printout in the verstage is about some TPM commands which can be misleading when execution hangs after that point. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I9ca68a32d7a50c95d9a6948d35816fee583611bc Reviewed-on: https://review.coreboot.org/c/coreboot/+/52086 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-03-30security: vboot: Clarify PCR extension algorithms/sizesJulius Werner
The PCR algorithms used for vboot are frequently causing confusion (e.g. see CB:35645) because depending on the circumstances sometimes a (zero-extended) SHA1 value is interpreted as a SHA256, and sometimes a SHA256 is interpreted as a SHA1. We can't really "fix" anything here because the resulting digests are hardcoded in many generations of Chromebooks, but we can document and isolate it better to reduce confusion. This patch adds an explanatory comment and fixes both algorithms and size passed into the lower-level TPM APIs to their actual values (whereas it previously still relied on the TPM 1.2 TSS not checking the algorithm type, and the TPM 2.0 TSS only using the size value for the TCPA log and not the actual TPM operation). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ib0b6ecb8c7e9a405ae966f1049158f1d3820f7e2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/51720 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Andrey Pronin <apronin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2021-03-19cpu/intel/fit: Add the FIT table as a separate CBFS fileArthur Heymans
With CBnT a digest needs to be made of the IBB, Initial BootBlock, in this case the bootblock. After that a pointer to the BPM, Boot Policy Manifest, containing the IBB digest needs to be added to the FIT table. If the fit table is inside the IBB, updating it with a pointer to the BPM, would make the digest invalid. The proper solution is to move the FIT table out of the bootblock. The FIT table itself does not need to be covered by the digest as it just contains pointers to structures that can by verified by the hardware itself, such as microcode and ACMs (Authenticated Code Modules). Change-Id: I352e11d5f7717147a877be16a87e9ae35ae14856 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50926 Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Christian Walter <christian.walter@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-03-16cbfs: Remove prog_locate() for stages and rmodulesJulius Werner
This patch removes the prog_locate() step for stages and rmodules. Instead, the stage and rmodule loading functions will now perform the locate step directly together with the actual loading. The long-term goal of this is to eliminate prog_locate() (and the rdev member in struct prog that it fills) completely in order to make CBFS verification code safer and its security guarantees easier to follow. prog_locate() is the main remaining use case where a raw rdev of CBFS file data "leaks" out of cbfs.c into other code, and that other code needs to manually make sure that the contents of the rdev get verified during loading. By eliminating this step and moving all code that directly deals with file data into cbfs.c, we can concentrate the code that needs to worry about file data hashing (and needs access to cbfs_private.h APIs) into one file, making it easier to keep track of and reason about. This patch is the first step of this move, later patches will do the same for SELFs and other program types. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ia600e55f77c2549a00e2606f09befc1f92594a3a Reviewed-on: https://review.coreboot.org/c/coreboot/+/49335 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-27vboot: update GBB flags to use altfw terminologyJoel Kitching
As per CL:2641346, update GBB flag names: GBB_FLAG_FORCE_DEV_BOOT_LEGACY -> GBB_FLAG_FORCE_DEV_BOOT_ALTFW GBB_FLAG_DEFAULT_DEV_BOOT_LEGACY -> GBB_FLAG_DEFAULT_DEV_BOOT_ALTFW BUG=b:179458327 TEST=make clean && make test-abuild BRANCH=none Signed-off-by: Joel Kitching <kitching@google.com> Change-Id: I0ac5c9fde5a175f8844e9006bb18f792923f4f6d Reviewed-on: https://review.coreboot.org/c/coreboot/+/50906 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-02-15src/security: Remove unused <console/console.h>Elyes HAOUAS
Change-Id: I2b81a57ded80ef9c5cbdff06d8ca9d6b4f599777 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50526 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-09security/vboot/bootmode: Add weak fill_lb_gpiosRaul E Rangel
This change allows VBOOT to build when the mainboard hasn't implemented any of the VBOOT functions yet. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I42ca8f0dba9fd4a868bc7b636e4ed04cbf8dfab0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/50341 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-09src: Add missing <cbmem.h>Elyes HAOUAS
Change-Id: I75a816c594b326df8a4aa5458bb055fca35e1741 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50379 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-02-04coreboot_table: Move VBOOT_VBNV supportKyösti Mälkki
The guard changes from (CHROMEOS && PC80_SYSTEM) to VBOOT_VBNV_CMOS here. Change-Id: I653285c04e864aa6a3494ba1400787fa184ba187 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50250 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-02-03src: Remove unused <cbmem.h>Elyes HAOUAS
Change-Id: I2279e2d7e6255a88953b2485c1f1a3b51a72c65e Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50182 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2021-02-01security/vboot: Add config for GBB_FLAG_ENABLE_UDCEric Lai
This change adds the missing `GBB_FLAG_ENABLE_UDC` as a config in vboot/Kconfig (just like the other GBB flags) and uses its value to configure GBB_FLAGS Makefile variable. This is done to allow the mainboard to configure GBB flags by selecting appropriate configs in Kconfig. Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com> Change-Id: I6b397713d643cf9461294e6928596dc847ace6bd Reviewed-on: https://review.coreboot.org/c/coreboot/+/50110 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-01-18security/vboot/secdata_tpm.c: Remove repeated wordElyes HAOUAS
Change-Id: Idc17a4305398defd19e7f6ba2fc00bf69af34c4b Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49526 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
2020-12-03cbfs: Add verification for RO CBFS metadata hashJulius Werner
This patch adds the first stage of the new CONFIG_CBFS_VERIFICATION feature. It's not useful to end-users in this stage so it cannot be selected in menuconfig (and should not be used other than for development) yet. With this patch coreboot can verify the metadata hash of the RO CBFS when it starts booting, but it does not verify individual files yet. Likewise, verifying RW CBFSes with vboot is not yet supported. Verification is bootstrapped from a "metadata hash anchor" structure that is embedded in the bootblock code and marked by a unique magic number. This anchor contains both the CBFS metadata hash and a separate hash for the FMAP which is required to find the primary CBFS. Both are verified on first use in the bootblock (and halt the system on failure). The CONFIG_TOCTOU_SAFETY option is also added for illustrative purposes to show some paths that need to be different when full protection against TOCTOU (time-of-check vs. time-of-use) attacks is desired. For normal verification it is sufficient to check the FMAP and the CBFS metadata hash only once in the bootblock -- for TOCTOU verification we do the same, but we need to be extra careful that we do not re-read the FMAP or any CBFS metadata in later stages. This is mostly achieved by depending on the CBFS metadata cache and FMAP cache features, but we allow for one edge case in case the RW CBFS metadata cache overflows (which may happen during an RW update and could otherwise no longer be fixed because mcache size is defined by RO code). This code is added to demonstrate design intent but won't really matter until RW CBFS verification can be supported. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I8930434de55eb938b042fdada9aa90218c0b5a34 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41120 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2020-12-02cbfs: Simplify load/map API names, remove type argumentsJulius Werner
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file() to cbfs_map() and cbfs_load() respectively. This is supposed to be the start of a new, better organized CBFS API where the most common operations have the most simple and straight-forward names. Less commonly used variants of these operations (e.g. cbfs_ro_load() or cbfs_region_load()) can be introduced later. It seems unnecessary to keep carrying around "boot" in the names of most CBFS APIs if the vast majority of accesses go to the boot CBFS (instead, more unusual operations should have longer names that describe how they diverge from the common ones). cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly reap mappings when desired. A few new cbfs_unmap() calls are added to generic code where it makes sense, but it seems unnecessary to introduce this everywhere in platform or architecture specific code where the boot medium is known to be memory-mapped anyway. In fact, even for non-memory-mapped platforms, sometimes leaking a mapping to the CBFS cache is a much cleaner solution than jumping through hoops to provide some other storage for some long-lived file object, and it shouldn't be outright forbidden when it makes sense. Additionally, remove the type arguments from these function signatures. The goal is to eventually remove type arguments for lookup from the whole CBFS API. Filenames already uniquely identify CBFS files. The type field is just informational, and there should be APIs to allow callers to check it when desired, but it's not clear what we gain from forcing this as a parameter into every single CBFS access when the vast majority of the time it provides no additional value and is just clutter. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com> Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-11-21cbfs: Add metadata cacheJulius Werner
This patch adds a new CBFS "mcache" (metadata cache) -- a memory buffer that stores the headers of all CBFS files. Similar to the existing FMAP cache, this cache should reduce the amount of SPI accesses we need to do every boot: rather than having to re-read all CBFS headers from SPI flash every time we're looking for a file, we can just walk the same list in this in-memory copy and finally use it to directly access the flash at the right position for the file data. This patch adds the code to support the cache but doesn't enable it on any platform. The next one will turn it on by default. Change-Id: I5b1084bfdad1c6ab0ee1b143ed8dd796827f4c65 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38423 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-11-18vboot: stop implementing VbExDisplayScreenJoel Kitching
This function is no longer required to be implemented since EC/AUXFW sync was decoupled from vboot UI. (See CL:2087016.) BUG=b:172343019 TEST=Compile locally BRANCH=none Signed-off-by: Joel Kitching <kitching@google.com> Change-Id: I43e8160a4766a38c4fa14bcf4495fc719fbcd6c2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/47233 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2020-11-17src: Add missing 'include <console/console.h>'Elyes HAOUAS
"printk()" needs <console/console.h>. Change-Id: Iac6b7000bcd8b1335fa3a0ba462a63aed2dc85b8 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45539 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2020-11-06security/vboot: Add Kconfig symbol to set hashing block sizeMartin Roth
Generally, this size probably doesn't matter very much, but in the case of picasso's psp_verstage, the hash is being calculated by hardware using relatively expensive system calls. By increasing the block size, we can save roughly 140ms of boot and resume time. TEST=Build & boot see that boot time has decreased. BRANCH=Zork BUG=b:169217270 - Zork: SHA calculation in vboot takes too long Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I68eecbbdfadcbf14288dc6e849397724fb66e0b2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/46901 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Kangheui Won <khwon@chromium.org>
2020-10-28security/vboot: fix policy digest for nvmem spacesAndrey Pronin
This CL fixes the policy digest that restricts deleting the nvmem spaces to specific PCR0 states. BRANCH=none BUG=b:140958855 TEST=verified that nvmem spaces created with this digest can be deleted in the intended states, and cannot be deleted in other states (test details for ChromeOS - in BUG comments). Change-Id: I3cb7d644fdebda71cec3ae36de1dc76387e61ea7 Signed-off-by: Andrey Pronin <apronin@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46772 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-10-26vboot: Disable vboot functions in SMMJulius Werner
SMM does not have access to CBMEM and therefore cannot access any persistent state like the vboot context. This makes it impossible to query vboot state like the developer mode switch or the currently active RW CBFS. However some code (namely the PC80 option table) does CBFS accesses in SMM. This is currently worked around by directly using cbfs_locate_file_in_region() with the COREBOOT region. By disabling vboot functions explicitly in SMM, we can get rid of that and use normal CBFS APIs in this code. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I4b1baa73681fc138771ad8384d12c0a04b605377 Reviewed-on: https://review.coreboot.org/c/coreboot/+/46645 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-10-22security/vboot: Remove all tpm 1.2 functions for mrc hash in the tpmShelley Chen
Since MRC_SAVE_HASH_IN_TPM depends on TPM2, we can now remove the tpm 1.2 versions of functions that deal with mrc hash in the tpm as it will not be used by tpm 1.2 boards. Also move all antirollback functions that deal with mrc hash in the tpm under CONFIG(TPM2). BUG=b:150502246 BRANCH=None TEST=make sure boards are still compiling on coreboot Jenkins Change-Id: I446dde36ce2233fc40687892da1fb515ce35b82b Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46615 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-10-20mrc_cache: Add tpm_hash_index field to cache_region structShelley Chen
Pull selection of tpm hash index logic into cache_region struct. This CL also enables the storing of the MRC hash into the TPM NVRAM space for both recovery and non-recovery cases. This will affect all platforms with TPM2 enabled and use the MRC_CACHE driver. BUG=b:150502246 BRANCH=None TEST=make sure memory training still works on nami and lazor Change-Id: I1a744d6f40f062ca3aab6157b3747e6c1f6977f9 Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46514 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-10-20security/vboot: Add new TPM NVRAM index MRC_RW_HASH_NV_INDEXShelley Chen
Add new index for MRC_CACHE data in RW. Also update antirollback functions to handle this new index where necessary. BUG=b:150502246 BRANCH=None TEST=make sure memory training still works on nami Change-Id: I2de3c23aa56d3b576ca54dbd85c75e5b80199560 Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46511 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-10-20security/vboot: Make mrc_cache hash functions genericShelley Chen
We need to extend the functionality of the mrc_cache hash functions to work for both recovery and normal mrc_cache data. Updating the API of these functions to pass in an index to identify the hash indices for recovery and normal mode. BUG=b:150502246 BRANCH=None TEST=make sure memory training still works on nami Change-Id: I9c0bb25eafc731ca9c7a95113ab940f55997fc0f Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46432 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-10-20mrc_cache: Move mrc_cache_*_hash functions into mrc_cache driverShelley Chen
This CL would remove these calls from fsp 2.0. Platforms that select MRC_STASH_TO_CBMEM, updating the TPM NVRAM space is moved from romstage (when data stashed to CBMEM) to ramstage (when data is written back to SPI flash. BUG=b:150502246 BRANCH=None TEST=make sure memory training still works on nami Change-Id: I3088ca6927c7dbc65386c13e868afa0462086937 Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46510 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2020-10-20mrc_cache: Add config MRC_SAVE_HASH_IN_TPMShelley Chen
Use this config to specify whether we want to save a hash of the MRC_CACHE in the TPM NVRAM space. Replace all uses of FSP2_0_USES_TPM_MRC_HASH with MRC_SAVE_HASH_IN_TPM and remove the FSP2_0_USES_TPM_MRC_HASH config. Note that TPM1 platforms will not select MRC_SAVE_HASH_IN_TPM as none of them use FSP2.0 and have recovery MRC_CACHE. BUG=b:150502246 BRANCH=None TEST=emerge-nami coreboot chromeos-bootimage Change-Id: Ic5ffcdba27cb1f09c39c3835029c8d9cc3453af1 Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46509 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-10-19security/vboot: Rename mem_init.h to mrc_cache_hash_tpm.hShelley Chen
As ongoing work for generalizing mrc_cache to be used by all platforms, we are pulling it out from fsp 2.0 and renaming it as mrc_cache_hash_tpm.h in security/vboot. BUG=b:150502246 BRANCH=None TEST=emerge-nami coreboot chromeos-bootimage Change-Id: I5a204bc3342a3462f177c3ed6b8443e31816091c Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46508 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-09-21src/security: Drop unneeded empty linesElyes HAOUAS
Change-Id: Icb6057ac73fcc038981ef95a648420ac00b3c106 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44808 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
2020-08-18src: Remove unused 'include <boot_device.h>'Elyes HAOUAS
Change-Id: I5589fdeade7f69995adf1c983ced13773472be74 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42349 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-08-13security/vboot/Makefile.inc: Update regions-for-file functionSridhar Siricilla
This patch updates regions-for-file function in the security/vboot/Makefile.inc to support adding a CBFS file into required FMAP REGIONs in a flexible manner. The file that needs to be added to specific REGIONs, those regions list should be specified in the regions-for-file-{CBFS_FILE_TO_BE_ADDED} variable. For example, if a file foo.bin needs to be added in FW_MAIN_B and COREBOOT, then below code needs to be added in a Makefile.inc. regions-for-file-foo := FW_MAIN_B,COREBOOT cbfs-file-y := foo foo-file := foo.bin foo-type := raw TEST=Verified on hatch Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com> Change-Id: I1f5c22b3d9558ee3c5daa2781a115964f8d2d83b Reviewed-on: https://review.coreboot.org/c/coreboot/+/43766 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-07-26src: Change BOOL CONFIG_ to CONFIG() in comments & stringsMartin Roth
The Kconfig lint tool checks for cases of the code using BOOL type Kconfig options directly instead of with CONFIG() and will print out warnings about it. It gets confused by these references in comments and strings. To fix it so that it can find the real issues, just update these as we would with real issues. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I5c37f0ee103721c97483d07a368c0b813e3f25c0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/43824 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-07-26src: Remove unused 'include <cbmem.h>'Elyes HAOUAS
Change-Id: Ib41341b42904dc3050a97b70966dde7e46057d6b Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43362 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-07-15security/vboot: ensure that NVMEM is saved on every kernel space writeJett Rink
If the AP actually needs to write to the TPM, then it is important and the TPM should commit those changes to NVMEM immediately in case there is an unexpected power loss (e.g. from a USB-C port partner reset upon cold reboot request). BRANCH=none BUG=b:160913048 TEST=Verify that puff will no longer reboot loop when coreboot writes a new Hmir (Hash mirror) in the TPM Change-Id: I9597a55891d11bdf040d70f38b4c5a59c7888b8a Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43414 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-14src: Remove unused 'include <stdint.h>Elyes HAOUAS
Found using: diff <(git grep -l '#include <stdint.h>' -- src/) <(git grep -l 'int8_t\|int16_t\|int32_t\|int64_t\|intptr_t\|intmax_t\|s8\|u8\|s16\|u16\|s32\|u32\|s64\|u64\|INT8_MIN\|INT8_MAX\|INT16_MIN\|INT16_MAX\|INT32_MIN\|INT32_MAX\|INT64_MIN\|INT64_MAX\|INTMAX_MIN\|INTMAX_MAX' -- src/) |grep -v vendorcode |grep '<' Change-Id: I5e14bf4887c7d2644a64f4d58c6d8763eb74d2ed Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41827 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-09security/vboot/secdata_tpm.c: Drop dead codeAngel Pons
This code is not even being build-tested. Drop it before it grows moss. Change-Id: Ie01d65f80caf32a8318d5109ad48321661c5a87b Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43213 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Michael Niewöhner Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-08security/vboot: Allow files to go into only RW-A or RW-B regionMartin Roth
The AMD firmware package created by amdfwtool contains pointers to the various binaries and settings. This means that we need different copies of the package in each region. This change allows for the different files in each of the 3 vboot regions. BUG=b:158124527 TEST=Build trembyle; see the correct versions of the files getting built into the RW-A & RW-B regions. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I45ff69dbc2266a67e05597bbe721fbf95cf41777 Reviewed-on: https://review.coreboot.org/c/coreboot/+/42822 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-06-19Kconfig: Escape variable to accommodate new Kconfig versionsPatrick Georgi
Kconfig 4.17 started using the $(..) syntax for environment variable expansion while we want to keep expansion to the build system. Older Kconfig versions (like ours) simply drop the escapes, not changing the behavior. While we could let Kconfig expand some of the variables, that only splits the handling in two places, making debugging harder and potentially messing with reproducible builds (e.g. when paths end up in configs), so escape them all. Change-Id: Ibc4087fdd76089352bd8dd0edb1351ec79ea4faa Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42481 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
2020-06-15security/vboot: Add option to run verstage before bootblockMartin Roth
For AMD's family 17h, verstage can run as a userspace app in the PSP before the X86 is released. The flags for this have been made generic to support any other future systems that might run verstage before the main processor starts. Although an attempt has been made to make things somewhat generic, since this is the first and currently only chip to support verstage before bootblock, there are a number of options which might ultimately be needed which have currently been left out for simplicity. Examples of this are: - PCI is not currently supported - this is currently just a given instead of making a separate Kconfig option for it. - The PSP uses an ARM v7 processor, so that's the only processor that is getting updated for the verstage-before-bootblock option. BUG=b:158124527 TEST=Build with following patches Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I4849777cb7ba9f90fe8428b82c21884d1e662b96 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41814 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-16 15:23:34 +0000