summaryrefslogtreecommitdiff
path: root/src/commonlib/bsd
AgeCommit message (Collapse)Author
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-17commonlib/clamp.h: Relicense file to be BSD-compatibleAngel Pons
I added this header in commit a6c8b4becbd12fe6043557ca1e398c1a7c691007 (nb/intel/sandybridge: Rewrite get_FRQ). Relicense it as "BSD-3-Clause OR GPL-2.0-or-later" and move it into the BSD-licensed commonlib part. Change-Id: I89ebdcdf8d06e78e624e37a443696981b3b17b7d Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66711 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-08-06util/elogtool: Mark redundant boot mode event type as `deprecated`Subrata Banik
This patch adds `_DEPRECATED_` tag to ChromeOS boot mode related event logging types as below: * ELOG_TYPE_CROS_RECOVERY_MODE <---- to record recovery boot reason while booting into recovery mode * ELOG_TYPE_CROS_DEVELOPER_MODE <--- if the platform is booted into developer mode. * ELOG_TYPE_CROS_DIAGNOSTICS <---- if the platform is booted into diagnostic mode. Drop static structure `cros_deprecated_recovery_reasons` as it has been replaced by vb2_get_recovery_reason_string() function. ELOG_TYPE_FW_BOOT_INFO event type is now used to record all those related fw boot info along with ChromeOS boot mode/reason etc. BUG=b:215615970 TEST=Build and boot google/kano to ChromeOS. Signed-off-by: Subrata Banik <subratabanik@google.com> Change-Id: I932952ce32337e2d54473667ce17582a90882da8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/65802 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-08-02vc/google/elog: Record vboot FW boot information into elogSubrata Banik
This patch calls into vboot API (vb2api_get_fw_boot_info) to retrieve FW slot boot information like (tries count, current boot slot, previous boot slot, previous boot status and boot mode). Upon retrieval of the vboot information, elog callback from ramstage records the info into the eventlog. Additionally, this patch refactors the existing event logging mechanism to add newer APIs to record vboot firmware boot related information. BUG=b:215615970 TEST=Build and boot google/kano to ChromeOS and run below command to check the cbmem log: Scenario 1: localhost ~ # cbmem -c | grep VB2 [INFO ] VB2:vb2_check_recovery() Recovery reason from previous boot: 0x0 / 0x0 [INFO ] VB2:vb2api_fill_boot_config() boot_mode=`Developer boot` VB2:vb2api_get_fw_boot_info() fw_tried=`A` fw_try_count=0 fw_prev_tried=`A` fw_prev_result=`Success`. .... Scenario 2: localhost ~ # crossystem recovery_request=1 localhost ~ # cbmem -c | grep VB2 [INFO ] VB2:vb2api_fill_boot_config() boot_mode=`Manual recovery boot` VB2:vb2api_fill_boot_config() recovery_reason=0x13 / 0x00 VB2:vb2api_get_fw_boot_info() fw_tried=`A` fw_try_count=0 fw_prev_tried=`A` fw_prev_result=`Unknown`. Signed-off-by: Subrata Banik <subratabanik@google.com> Change-Id: I6882cd1c4dbe5e24f6460388cd1af4e4a05fc4da Reviewed-on: https://review.coreboot.org/c/coreboot/+/65561 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-07-28commonlib: compiler.h: Use non-concise comment stylePaul Menzel
The concise multi-line comment style is for inside function bodies to save space. Outside of it, use non-concise style. Change-Id: I34d9ec6984b598a37c438fa3c395b5478207e31d Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65885 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2022-07-17commonlib: compiler.h: Improve wording in commentPaul Menzel
It probably was supposed to be *making these names conistent …*, but short that a little, and add a missing article. Change-Id: If88ff6d7b0a61aa83d5822b5e1c0b5b4c9d3bb3c Fixes: ac136250b26d ("commonlib: Substitude macro "__unused" in compiler.h") Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65884 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-07-14commonlib: Substitude macro "__unused" in compiler.hBill XIE
Since there are many identifiers whose name contain "__unused" in headers of musl libc, introducing a macro which expands "__unused" to the source of a util may have disastrous effect during its compiling under a musl-based platform. However, it is hard to detect musl at build time as musl is notorious for having explicitly been refusing to add a macro like "__MUSL__" to announce its own presence. Using __always_unused and __maybe_unused for everything may be a good idea. This is how it works in the Linux kernel, so that would at least make us match some other standard rather than doing our own thing (especially since the other compiler.h shorthand macros are also inspired by Linux). Signed-off-by: Bill XIE <persmule@hardenedlinux.org> Change-Id: I547ae3371d7568f5aed732ceefe0130a339716a9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/65717 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <felixsinger@posteo.net> Reviewed-by: Julius Werner <jwerner@chromium.org>
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-30commonlib: Add CBMEM tag id for CSE FW UpdateKrishna Prasad Bhat
cbfs_unverified_area_cbmem_alloc() expects a tag id to allocate space to decompress ME_RW blobs within the CBMEM area, add a tag id for it. BRANCH=firmware-brya-14505.B Change-Id: I32f44496d389e3a7e4f2573ee4e46a145f7cd927 Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65365 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2022-06-07commonlib: Clean up compiler.hJulius Werner
This patch contains several minor cleanups related to compiler.h: - Replace __always_unused() (which is a Linux-specific concept that doesn't make sense without also having __maybe_unused(), and had zero uses in the codebase) with __unused() which moves here from helpers.h - Add __underscores__ to the names of all attributes in the compiler attribute shorthand macros. This is necessary to make them work in files where the same name was already used for an identifier (e.g. cbfstool/cbfs.h's `unused` array of file types). - Remove libpayload's own copy of compiler.h and make it directly pull in the commonlib/bsd copy. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I9644da594bb69133843c6b7f12ce50b2e45fd24b Reviewed-on: https://review.coreboot.org/c/coreboot/+/64737 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2022-06-06drivers/amd/agesa: Don't save regular boot MTRR to flashArthur Heymans
Save the regular boot MTRRs that are restored on the S3 path during the CPU init in cbmem instead of storing them to the SPI flash. This was probably done because historically this code run with late cbmem init (in ramstage). TESTED on pcengines/apu1 and lenovo/g505s: S3 resume works fine. Change-Id: Ia58e7cd1afb785ba0c379ba75ef6090b56cb9dc6 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44294 Reviewed-by: Mike Banon <mikebdp2@gmail.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
2022-06-01cbfs: Add CBFS_TYPE_INTEL_FIT and exclude it from CBFS verificationJulius Werner
The Intel Firmware Interface Table (FIT) is a bit of an annoying outlier among CBFS files because it gets manipulated by a separate utility (ifittool) after cbfstool has already added it to the image. This will break file hashes created for CBFS verification. This is not actually a problem when booting, since coreboot never actually loads the FIT from CBFS -- instead, it's only in the image for use by platform-specific mechanisms that run before coreboot's bootblock. But having an invalid file hash in the CBFS image is confusing when you want to verify that the image is correctly built for verification. This patch adds a new CBFS file type "intel_fit" which is only used for the intel_fit (and intel_fit_ts, if applicable) file containing the FIT. cbfstool will avoid generating and verifying file hashes for this type, like it already does for the "bootblock" and "cbfs header" types. (Note that this means that any attempt to use the CBFS API to actually access this file from coreboot will result in a verification error when CBFS verification is enabled.) Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I1c1bb6dab0c9ccc6e78529758a42ad3194cd130c Reviewed-on: https://review.coreboot.org/c/coreboot/+/64736 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2022-06-01cbfs: Rename TYPE_FIT to TYPE_FIT_PAYLOADJulius Werner
There are too many "FIT" in firmware land. In order to reduce possible confusion of CBFS_TYPE_FIT with the Intel Firmware Interface Table, this patch renames it to CBFS_TYPE_FIT_PAYLOAD (including the cbfstool argument, so calling scripts will now need to replace `-t fit` with `-t fit_payload`). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I826cefce54ade06c6612c8a7bb53e02092e7b11a Reviewed-on: https://review.coreboot.org/c/coreboot/+/64735 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2022-05-19coreboot_tables: Add PCIe info to coreboot tableJianjun Wang
Add 'lb_fill_pcie' function to pass PCIe information from coreboot to libpayload, and add CB_ERR_NOT_IMPLEMENTED to the cb_err enum for the __weak function. ARM platform usually does not have common address for PCIe to access the configuration space of devices. Therefore, new API is added to pass the base address of PCIe controller for payloads to access PCIe devices. TEST=Build pass and boot up to kernel successfully via SSD on Dojo board, here is the SSD information in boot log: == NVME IDENTIFY CONTROLLER DATA == PCI VID : 0x15b7 PCI SSVID : 0x15b7 SN : 21517J440114 MN : WDC PC SN530 SDBPTPZ-256G-1006 RAB : 0x4 AERL : 0x7 SQES : 0x66 CQES : 0x44 NN : 0x1 Identified NVMe model WDC PC SN530 SDBPTPZ-256G-1006 BUG=b:178565024 BRANCH=cherry Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com> Change-Id: I6cdce21efc66aa441ec077e6fc1d5d1c6a9aafb0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/63251 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Shelley Chen <shchen@google.com>
2022-05-03commonlib/mem_chip_info: Add clarifying documentation commentsJulius Werner
This patch just adds some comments to the recently merged mem_chip_info struct for communicating memory type information to the payload/OS, to clarify the expected format in which values are to be written into the fields. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I2c28b3bdcdb13b7f270fb87a8f06e2cf448cddec Reviewed-on: https://review.coreboot.org/c/coreboot/+/63944 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Shelley Chen <shchen@google.com>
2022-04-28commonlib/bsd/elog: Include <stdint.h> instead of <inttypes.h>Hsuan Ting Chen
The header file <inttypes.h> includes <stdint.h> and defines some additional PRI* macros. Since elog.h and elog.c do not use any of the PRI* macro, we should include <stdint.h> directly. Change-Id: Iac1f4f53e43f171ecef95533cd6a3bf5dff64ec4 Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63113 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2022-04-13commonlib/bsd: Add mem_chip_info_size() functionRavi Kumar Bokka
Add a helper function mem_chip_info_size() as the size of mem_chip_info structure is used in multiple places. BUG=b:182963902,b:177917361 TEST=Validated on qualcomm sc7280 development board Signed-off-by: Ravi Kumar Bokka <rbokka@codeaurora.org> Change-Id: Iaada45d63b82c28495166024a9655d871ba65b20 Reviewed-on: https://review.coreboot.org/c/coreboot/+/63407 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-03-30commonlib/bsd/helpers: Remove redundancy with libpayload definesJakub Czapiga
Move STRINGIFY() from coreboot string.h to commonlib/bsd/helpers.h Remove redundant defines from libpayload.h and libpayloads' standard headers. Signed-off-by: Jakub Czapiga <jacz@semihalf.com> Change-Id: I3263b2aa7657759207bf6ffda750d839e741f99c Reviewed-on: https://review.coreboot.org/c/coreboot/+/62921 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-03-18commonlib/bsd: Add struct name "mem_chip_channel" for external accessXi Chen
struct mem_chip_info { ... struct { --> If no struct name, can't access the channel structure ... } channel[0]; }; BUG=b:182963902,b:177917361 TEST=Build pass on Kingler Signed-off-by: Xi Chen <xixi.chen@mediatek.corp-partner.google.com> Change-Id: I8dcd3b52f33f80afb7885ffdcad826d86b54b543 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62850 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2022-03-16libpayload: Parse DDR Information using coreboot tablesRavi Kumar Bokka
BUG=b:182963902,b:177917361 TEST=Validated on qualcomm sc7280 development board Signed-off-by: Ravi Kumar Bokka <rbokka@codeaurora.org> Change-Id: Ieca7e9fc0e1a018fcb2e9315aebee088edac858e Reviewed-on: https://review.coreboot.org/c/coreboot/+/59193 Reviewed-by: Shelley Chen <shchen@google.com> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.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-02-16compiler.h: Define a __fallthrough statementArthur Heymans
Change-Id: I0487698290992162fac6bb74b5082901415e917e Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51497 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2022-02-09src/lib: Add CBMEM tag id to parse ddr informationRavi Kumar Bokka
BUG=b:182963902,b:177917361 TEST=Validated on qualcomm sc7280 development board Signed-off-by: Ravi Kumar Bokka <rbokka@codeaurora.org> Change-Id: I594bd9266a6379e3a85de507eaf4c56619b17a6f Reviewed-on: https://review.coreboot.org/c/coreboot/+/59194 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Shelley Chen <shchen@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-01-04commonlib: Add endian definitions for macOSAlex James
macOS has never defined the usual endian(3)/byteorder(9) byte-swapping functions. This change implements these byte-swapping functions using the OSSwap functions, which provide identical functionality. This was tested on macOS 10.15.7. Change-Id: I44d59869a4420030f3ce26118175304c680d57a1 Signed-off-by: Alex James <theracermaster@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60219 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-11-30commonlib: Move commonlib/cbmem_id.h to commonlib/bsd/Jakub Czapiga
Libpayload requires cbmem_id.h file to support extracting values from CBMEM IMD entries of coreboot tables. Libpayload use BSD-3-Clause license, and all of its files used to compile a static library have to use it too. Change-Id: I97c080e34ebdbcdf14fe3a3c9515b1dea8ede179 Signed-off-by: Jakub Czapiga <jacz@semihalf.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/59696 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <patrick@coreboot.org>
2021-11-22eventlog: Add a log type for Chrome OS diagnosticsHsuan Ting Chen
Add events for Chrome OS diagnostics in eventlog tool: * ELOG_TYPE_CROS_DIAGNOSTICS(0xb6): diagnostics-related events * ELOG_CROS_LAUNCH_DIAGNOSTICS(0x01): sub-type for diagnostics boot These events are not added anywhere currently. They will be added in another separate commit. Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org> Change-Id: I1b67fdb46f64db33f581cfb5635103c9f5bbb302 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58795 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2021-10-05src/acpi to src/lib: Fix spelling errorsMartin Roth
These issues were found and fixed by codespell, a useful tool for finding spelling errors. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I5b8ecdfe75d99028fee820a2034466a8ad1c5e63 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58080 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-09-23elog: calculate year correctly in timestampRicardo Quesada
This CL uses a 16-bit value (instead of an 8-bit value) for the year. This is needed because the function internally does a "year % 100", so the year should not be truncated to 8-bit before applying the modulo. This fixes a regression introduced in commit e929a75. BUG=b:200538760 TEST=deployed coreboot. Manually verified that year is correct using "elogtool list" TEST=test_that -b $BOARD $DUT firmware_EventLog Change-Id: I17578ff99af5b31b216ac53c22e53b1b70df5084 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57816 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-09-15commonlib/cbfs: Fix minor parser edge casesJulius Werner
This patch fixes a few minor CBFS parsing edge cases that could lead to unintended behavior: the CBFS attribute parser could have run into an infinite loop if an attribute's length was (accidentally or maliciously) invalid. A length of 0 would have caused it to read the same attribute over and over again without making forward progress, while a very large length could have caused an overflow that makes it go backwards to find the next attribute. Also, the filename was not guaranteed to be null-terminated which could have resulted in out-of-bounds reads on a few error messages. Finally, clarify the validity guarantees for CBFS header fields offered by cbfs_walk() in the comment explaining cbfs_mdata. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ie569786e5bec355b522f6580f53bdd8b16a4d726 Reviewed-on: https://review.coreboot.org/c/coreboot/+/57569 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
2021-09-13cbfs: Prevent overflow and infinite loop in cbfs_walkJakub Czapiga
CBFS file with lenth of (UINT32_MAX - cbfs_file.offset + 1) causes overflow, making cbfs_walk() being stuck in an infinite loop, and checking the same file. This patch makes cbfs_walk() skip file headers with incorrect data_offset or data_length. Signed-off-by: Jakub Czapiga <jacz@semihalf.com> Change-Id: I70020e347087cbd8134a1a60177fa9eef63fb7bd Reviewed-on: https://review.coreboot.org/c/coreboot/+/57525 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-09-10elog: move MAX_EVENT_SIZE to commonlib/bsd/includeRicardo Quesada
Moves MAX_EVENT_SIZE to commonlib/bsd/include, and renames it ELOG_MAX_EVENT_SIZE to give it an "scoped" name. The moving is needed because this defined will be used from util/cbfstool (see next CL in the chain). BUG=b:172210863 TEST=compiles Ok Change-Id: I86b06d257dda5b325a8478a044045b2a63fb1a84 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57394 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-09-01cbfs: Make sure all cases of single file header corruption are isolatedJulius Werner
The new CBFS stack was written to try to isolate cases of single file corruption as far as possible and still make other files avaialble (at least as long as verification is disabled and they can still be found at all). For most cases of header corruption, it will just continue trying to parse the next file. However, in cases where parts of the file extend beyond the end of the rdev, we have been relying on the range checking of the rdev API rather than doing it explicitly. This is fine in general, but it causes the problem that these errors cannot be distinguished from I/O errors, and I/O errors always make the whole cbfs_walk() fail. That means we will not return a successful result from cbfs_mcache_build(), and leads to an odd discrepancy in how certain kinds of corrupted CBFSes are treated with and without mcache. This patch adds an explicit range check to make the behavior consistent. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ice2b6960284bd0c19be35b0607e5e32791e7a64c Reviewed-on: https://review.coreboot.org/c/coreboot/+/57271 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
2021-08-26elog: Define constant for RW region nameRicardo Quesada
This CL indroduces the ELOG_RW_REGION_NAME. This constant replaced the hardcoded "RW_ELOG" value. This constant will be used also by elogtool (see CL in the commit chain). BUG=b:172210863 Change-Id: Ie8d31204e65fd67d52b0f8ced7b8c1ffdcf5b539 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56986 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-08-26elog: move functionality to commonlib/bsdRicardo Quesada
This commit moves some drivers/elog/ functionality to commonlib/bsd since they will be called from util/cbfstool/. In particular: * elog_fill_timestamp(), elog_update_checksum(), elog_checksum_event() were moved to commonlib/bsd/elog * elog_fill_timestamp() receives the time parameters and updates the event based on the "time" arguments. The original elog_*() functions were written by Duncan Laurie (see CB:1311) and he gave permission to re-license the code to BSD. BUG=b:172210863 Change-Id: I67d5ad6e7c4d486b3d4ebb25be77998173cee5a9 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56985 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-08-23include/bcd: move bcd code to commonlib/bsd/includeRicardo Quesada
Move bcd2bin() / bin2bcd() functions to commonlib/bsd/include/ Also, the license is changed from GPL to BSD. This is because it is needed from "utils" (see CL in the chain). For reference bin2bcd() & bcd2bin() are very simple functions. There are already BSD implementations, like these ones (just to name a few): https://chromium.googlesource.com/chromiumos/platform/mosys/+/refs/heads/main/include/lib/math.h#67 http://web.mit.edu/freebsd/head/sys/contrib/octeon-sdk/cvmx-cn3010-evb-hs5.c BUG=b:172210863 TEST=make (everything compiled Ok). Change-Id: If2eba82da35838799bcbcf38303de6bd53f7eb72 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56904 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-08-05util/elogtool: add tool to print elog eventsRicardo Quesada
Add a new tool that that prints elog events. The tool, as input, accepts either a file with the RW_ELOG contents, or if the file is not provided it reads the contents of RW_ELOG by calling the "flashrom" tool. The tool is based on "mosys eventlog list"[1]. For the moment it only supports "list", but future commits will add additional functionality. This commit also adds missing ELOG defines needed for the tool. These defines are added with the rest of the ELOG defines, in include/commonlib/bsd/elog.h The tool is placed inside util/cbfstool. The rationale behind the decision, is that this tool shares a lot in common with the other tools located in cbfstool: vboot dependency, shared files like common.o and valstr.o, and in spirit is similar to some of the tools located in cbfstool/. As an example, you call the tool like the following: $ elogtool list -f rw_elog_dump.bin [1]: https://chromium.googlesource.com/chromiumos/platform/mosys/+/refs/heads/main/lib/eventlog/elog.c BUG=b:172210863 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Change-Id: Ia1fe1c9ed3c4c6bda846055d4b10943b54463935 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56406 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
2021-08-05Move ELOG defines/struct to commonib/bsd/elog.hRicardo Quesada
Move ELOG defines and structs from include/elog.h to include/comonlib/bsd/elog.h. This is needed because the will be used from util/ (in a future commit). It also replaces uNN types with uintNN_t types, for the reason described above. BUG=b:172210863 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Change-Id: I4f307f599a311810df2367b7c888f650cff1214a Reviewed-on: https://review.coreboot.org/c/coreboot/+/56405 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-08-04Move elog_internal.h to commonlib/bsd/includeRicardo Quesada
Move elog_internal.h to commonlib/bsd/include/bsd/. And rename it from elog_internal.h to elog.h. Since this file will be included from util/ it also converts the "uNN" types into "uintNN_t" types. The two defines that are not used by util/ are moved to drivers/elog/elog.c, the only file that includes them. Move also the function elog_verify_header() from drivers/elog/, to commonlib/bsd/elog.c since this function will be called from util/ as well. The rationale behind moving elog's defines & structs to commonlib/bsd/include is to make them available to util/ tools and/or payloads (should it be needed in the future). The files that are being relicensed to BSD were coded by Duncan Laurie, and he is Ok with the relicense. BUG=b:172210863 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Change-Id: Ia1aefea705ddd417a1d9e978bb18ab6d9a60cad6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56404 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-08-02helpers: Add GENMASK macroYu-Ping Wu
The GENMASK is defined in multiple files (with various names such as MASKBIT), which sets certain consecutive bits to 1 and leaves the others to 0. To avoid duplicate macros, add GENMASK macro to helpers.h. GENMASK(high, low) sets bits from `high` to `low` (inclusive) to 1. For example, GENMASK(39, 21) gives us the 64-bit vector 0x000000ffffe00000. Remove duplicate macro definitions. Also utilize GENMASK for _BF_MASK in mmio.h. BUG=none TEST=make tests/commonlib/bsd/helpers-test TEST=emerge-cherry coreboot BRANCH=none Change-Id: If2e7c4827d8a7d27688534593b556a72f16f0c2b Signed-off-by: Yu-Ping Wu <yupingso@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56543 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-06-26helpers: Introduce retry macroYu-Ping Wu
Introduce a macro retry(attempts, condition, expr) for retrying a condition, which is extensively used in coreboot. Example usage: if (!retry(3, read32(REG) == 0, mdelay(1)) printk(BIOS_ERR, "Error waiting for REG to be 0\n"); BUG=none TEST=make tests/commonlib/bsd/helpers-test TEST=emerge-cherry coreboot BRANCH=none Change-Id: I421e4dcab949616bd68b3a14231da744b9f74eeb Signed-off-by: Yu-Ping Wu <yupingso@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55778 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-06-11commonlib/lz4_wrapper.c: do not use bitfieldsKrystian Hebel
Order of bits in bitfields is implementation-defined. This makes them non-portable, especially across systems using different endianness. This change removes bitfields and uses masking and shifting instead. Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com> Change-Id: Ief7d87ddb25c9baa931f27dbd54a4ca730b6ece7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/55040 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-04-10cbfs: mcache: Fix size calculation for perfectly full cacheJulius Werner
cbfs_mcache_real_size() has a subtle flaw: when the cache is perfectly full to the end (so that the termination token sits exactly at the end of the available space), the loop counting the size ends prematurely. This means that when migrating the cache to CBMEM the terminating token is not copied, which isn't actually noticeable unless you're looking for a file that's not in the cache (because it doesn't exist or because not all files fit when building). This patch fixes the problem and slightly changes the error message for when a cache isn't terminated (to make it more clear that this is a different condition from a "normal" cache overflow that can happen when building if there's not enough room to fit all files). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I8d89e7dadc958f97b173b3a2352f2010c8a3d1d5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/52200 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2021-04-06cbfs: Add file data hashing for CONFIG_CBFS_VERIFICATIONJulius Werner
This patch adds file data hashing for CONFIG_CBFS_VERIFICATION. With this, all CBFS accesses using the new CBFS APIs (cbfs_load/_map/_alloc and variants) will be fully verified when verification is enabled. (Note that some use of legacy APIs remains and thus the CBFS_VERIFICATION feature is not fully finished.) Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ic9fff279f69cf3b7c38a0dc2ff3c970eaa756aa8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/52084 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2021-03-17cbfs: Move stage header into a CBFS attributeJulius Werner
The CBFS stage header is part of the file data (not the header) from CBFS's point of view, which is problematic for verification: in pre-RAM environments, there's usually not enough scratch space in CBFS_CACHE to load the full stage into memory, so it must be directly loaded into its final destination. However, that destination is decided from reading the stage header. There's no way we can verify the stage header without loading the whole file and we can't load the file without trusting the information in the stage header. To solve this problem, this patch changes the CBFS stage format to move the stage header out of the file contents and into a separate CBFS attribute. Attributes are part of the metadata, so they have already been verified before the file is loaded. Since CBFS stages are generally only meant to be used by coreboot itself and the coreboot build system builds cbfstool and all stages together in one go, maintaining backwards-compatibility should not be necessary. An older version of coreboot will build the old version of cbfstool and a newer version of coreboot will build the new version of cbfstool before using it to add stages to the final image, thus cbfstool and coreboot's stage loader should stay in sync. This only causes problems when someone stashes away a copy of cbfstool somewhere and later uses it to try to extract stages from a coreboot image built from a different revision... a debugging use-case that is hopefully rare enough that affected users can manually deal with finding a matching version of cbfstool. The SELF (payload) format, on the other hand, is designed to be used for binaries outside of coreboot that may use independent build systems and are more likely to be added with a potentially stale copy of cbfstool, so it would be more problematic to make a similar change for SELFs. It is not necessary for verification either, since they're usually only used in post-RAM environments and selfload() already maps SELFs to CBFS_CACHE before loading them to their final destination anyway (so they can be hashed at that time). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I8471ad7494b07599e24e82b81e507fcafbad808a Reviewed-on: https://review.coreboot.org/c/coreboot/+/46484 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2021-03-08cbfs: Add cbfs_alloc() primitive and combine cbfs_load() and cbfs_map()Julius Werner
This patchs adds a new CBFS primitive that allows callers to pass in an allocator function that will be called once the size of the file to load is known, to decide on its final location. This can be useful for loading a CBFS file straight into CBMEM, for example. The new primitive is combined with cbfs_map() and cbfs_load() into a single underlying function that can handle all operations, to reduce the amount of code that needs to be duplicated (especially later when file verification is added). Also add a new variation that allows restraining or querying the CBFS type of a file as it is being loaded, and reorganize the documentation/definition of all these accessors and variations in the header file a little. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I5fe0645387c0e9053ad5c15744437940fc904392 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49334 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2021-02-18commonlib/bsd: Fix direct inclusion of <endian.h>Julius Werner
<endian.h> should never be included directly in commonlib files and should instead be chain-included via <commonlib/bsd/sysincludes.h>. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ibc67ea97da36ec58738236ef22f961d9bbaf8574 Reviewed-on: https://review.coreboot.org/c/coreboot/+/50630 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2021-02-18cbfs: Fix attribute tag printing in cbfs_find_attr()Julius Werner
Attribute tags are defined as hexadecimal constants, not decimal, so it makes more sense to print them like that in error messages as well. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I3a5a6a8c9b8d24e57633595fc47221a483d8593a Reviewed-on: https://review.coreboot.org/c/coreboot/+/48836 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2021-02-18cbfstool: Replace FILENAME_ALIGN 16 with ATTRIBUTE_ALIGN 4Julius Werner
cbfstool has always had a CBFS_FILENAME_ALIGN that forces the filename field to be aligned upwards to the next 16-byte boundary. This was presumably done to align the file contents (which used to come immediately after the filename field). However, this hasn't really worked right ever since we introduced CBFS attributes. Attributes come between the filename and the contents, so what this code currently does is fill up the filename field with extra NUL-bytes to the boundary, and then just put the attributes behind it with whatever size they may be. The file contents don't end up with any alignment guarantee and the filename field is just wasting space. This patch removes the old FILENAME_ALIGN, and instead adds a new alignment of 4 for the attributes. 4 seems like a reasonable alignment to enforce since all existing attributes (with the exception of weird edge cases with the padding attribute) already use sizes divisible by 4 anyway, and the common attribute header fields have a natural alignment of 4. This means file contents will also have a minimum alignment guarantee of 4 -- files requiring a larger guarantee can still be added with the --alignment flag as usual. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I43f3906977094df87fdc283221d8971a6df01b53 Reviewed-on: https://review.coreboot.org/c/coreboot/+/47827 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-12-03cbfs: mcache: Fix end-of-cache checkJulius Werner
After the mcache is copied into CBMEM, it has *just* the right size to fit the final tag with no room to spare. That means the test to check if we walked over the end must be `current + sizeof(tag) <= end`, not `current + sizeof(tag) < end`. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I25a0d774fb3294bb4d15f31f432940bfccc84af0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/48277 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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-03cbfstool: Use cbfs_serialized.h and standard vboot helpersJulius Werner
This patch reduces some code duplication in cbfstool by switching it to use the CBFS data structure definitions in commonlib rather than its own private copy. In addition, replace a few custom helpers related to hash algorithms with the official vboot APIs of the same purpose. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I22eae1bcd76d85fff17749617cfe4f1de55603f4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41117 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
2020-12-02cbfs: Port cbfs_load() and cbfs_map() to new APIJulius Werner
This patch adapts cbfs_load() and cbfs_map() to use the new CBFS API directly, rather than through cbfs_boot_locate(). For cbfs_load() this means that attribute metadata does not need to be read twice. Change-Id: I754cc34b1c1471129e15475aa0f1891e02439a02 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39305 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.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-10-30commonlib/bsd: Add new CBFS core implementationJulius Werner
This patch adds a new CBFS implementation that is intended to replace the existing commonlib/cbfs.c. The new implementation is designed to meet a bunch of current and future goals that in aggregate make it easier to start from scratch than to adapt the exisiting implementation: 1. Be BSD-licensed so it can evetually be shared with libpayload. 2. Allow generating/verifying a metadata hash for future CBFS per-file verification (see [1][2]). 3. Be very careful about reading (not mmaping) all data only once, to be suitable for eventual TOCTOU-safe verification. 4. Make it possible to efficiently implement all current and future firmware use cases (both with and without verification). The main primitive is the cbfs_walk() function which will traverse a CBFS and call a callback for every file. cbfs_lookup() uses this to implement the most common use case of finding a file so that it can be read. A host application using this code (e.g. coreboot, libpayload, cbfstool) will need to provide a <cbfs_glue.h> header to provide the glue to access the respective CBFS storage backend implementation. This patch merely adds the code, the next patch will integrate it into coreboot. [1]: https://www.youtube.com/watch?v=Hs_EhewBgtM [2]: https://osfc.io/uploads/talk/paper/47/The_future_of_firmware_verification_in_coreboot.pdf (Note: In early discussions the metadata hash was called "master hash".) Change-Id: Ica64c1751fa37686814c0247460c399261d5814c Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38421 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-09-21src/commonlib: Drop unneeded empty linesElyes HAOUAS
Change-Id: Ib3db132aa649b6895f41290df049f87a9f36dc52 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44606 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
2020-09-14util/cbfstool: extend includes in commonlibIdwer Vollering
Certain non-Linux OSes require an include file in different places. Build tested on Linux, FreeBSD. Change-Id: Icd81c2a96c608589ce2ec8f4b883fd4e584776b1 Signed-off-by: Idwer Vollering <vidwer@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38648 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-02commonlib: Add CBFS_TYPE_BOOTBLOCKWim Vervoorn
Add CBFS_TYPE_BOOTBLOCK to allow accessing the bootblock as a CBFS file. BUG=N/A TEST=build Change-Id: Ibb03ac3a6cd8711e0402e47335bb8e110c6ef61a Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41824 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-03-30helpers: Add a helper macro for calculating power of 2Furquan Shaikh
This change adds a helper macro POWER_OF_2 that is useful for calculating the requested power of 2. Change-Id: Ie70f93b6ac175699c11cae7d8f023a52cce01e88 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39881 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-03-02lz4: Fix out-of-bounds readsAlex Rebert
Fix two out-of-bounds reads in lz4 decompression: 1) LZ4_decompress_generic could read one byte past the input buffer when decoding variable length literals due to a missing bounds check. This issue was resolved in libpayload, commonlib and cbfstool 2) ulz4fn could read up to 4 bytes past the input buffer when reading a lz4_block_header due to a missing bounds check. This issue was resolved in libpayload and commonlib. Change-Id: I5afdf7e1d43ecdb06c7b288be46813c1017569fc Signed-off-by: Alex Rebert <alexandre.rebert@gmail.com> Found-by: Mayhem Reviewed-on: https://review.coreboot.org/c/coreboot/+/39174 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2020-01-28commonlib: Add commonlib/bsdJulius Werner
This patch creates a new commonlib/bsd subdirectory with a similar purpose to the existing commonlib, with the difference that all files under this subdirectory shall be licensed under the BSD-3-Clause license (or compatible permissive license). The goal is to allow more code to be shared with libpayload in the future. Initially, I'm going to move a few files there that have already been BSD-licensed in the existing commonlib. I am also exracting most contents of the often-needed <commonlib/helpers.h> as long as they have either been written by me (and are hereby relicensed) or have an existing equivalent in BSD-licensed libpayload code. I am also relicensing <commonlib/compression.h> (written by me) and <commonlib/compiler.h> (same stuff exists in libpayload). Finally, I am extracting the cb_err error code definitions from <types.h> into a new BSD-licensed header so that future commonlib/bsd code can build upon a common set of error values. I am making the assumption here that the enum constants and the half-sentence fragments of documentation next to them by themselves do not meet the threshold of copyrightability. Change-Id: I316cea70930f131e8e93d4218542ddb5ae4b63a2 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38420 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-21 09:49:57 +0000