GNUBoot/coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
coreboot-kgpe-d16/src/include/cbfs.h

87 lines
4.1 KiB
C
Raw Normal View History

src/include: Use SPDX for GPL-2.0-only files Done with sed and God Lines. Only done for C-like code for now. Change-Id: I2fa3bad88bb5b068baa1cfc6bbcddaabb09da1c5 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40053 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2020-04-02 23:48:27 +02:00
/* SPDX-License-Identifier: GPL-2.0-only */
v2/src romfs->cbfs rename This also has the config tool changes in v2/util. Rename romfs.[ch]->cbfs.[ch] and sed romfs->cbfs romtool->cbfstool ROMFS->CBFS Signed-off-by: Peter Stuge <peter@stuge.se> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4113 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-04-14 09:40:01 +02:00
#ifndef _CBFS_H_
#define _CBFS_H_
cbfs: Add metadata cache 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>
2019-12-12 02:09:39 +01:00
#include <cbmem.h>
commonlib: Add common cbfs parsing logic to coreboot and cbfstool. To continue sharing more code between the tools and coreboot proper provide cbfs parsing logic in commonlib. A cbfs_for_each_file() function was added to allow one to act on each file found within a cbfs. cbfs_locate() was updated to use that logic. BUG=chrome-os-partner:48412 BUG=chromium:445938 BRANCH=None TEST=Utilized and booted on glados. Change-Id: I1f23841583e78dc3686f106de9eafe1adbef8c9f Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12783 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-12-15 20:33:51 +01:00
#include <commonlib/cbfs.h>
cbfs: new API and better program loading A new CBFS API is introduced to allow making CBFS access easier for providing multiple CBFS sources. That is achieved by decoupling the cbfs source from a CBFS file. A CBFS source is described by a descriptor. It contains the necessary properties for walking a CBFS to locate a file. The CBFS file is then decoupled from the CBFS descriptor in that it's no longer needed to access the contents of the file. All of this is accomplished using the regions infrastructure by repsenting CBFS sources and files as region_devices. Because region_devices can be chained together forming subregions this allows one to decouple a CBFS source from a file. This also allows one to provide CBFS files that came from other sources for payload and/or stage loading. The program loading takes advantage of those very properties by allowing multiple sources for locating a program. Because of this we can reduce the overhead of loading programs because it's all done in the common code paths. Only locating the program is per source. Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9134 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-16 06:39:23 +02:00
#include <program_loading.h>
cbfs: Add metadata cache 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>
2019-12-12 02:09:39 +01:00
#include <types.h>
cbfs: Add verification for RO CBFS metadata hash 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-05-07 02:06:35 +02:00
#include <vb2_sha.h>
v2/src romfs->cbfs rename This also has the config tool changes in v2/util. Rename romfs.[ch]->cbfs.[ch] and sed romfs->cbfs romtool->cbfstool ROMFS->CBFS Signed-off-by: Peter Stuge <peter@stuge.se> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4113 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-04-14 09:40:01 +02:00
cbfs: new API and better program loading A new CBFS API is introduced to allow making CBFS access easier for providing multiple CBFS sources. That is achieved by decoupling the cbfs source from a CBFS file. A CBFS source is described by a descriptor. It contains the necessary properties for walking a CBFS to locate a file. The CBFS file is then decoupled from the CBFS descriptor in that it's no longer needed to access the contents of the file. All of this is accomplished using the regions infrastructure by repsenting CBFS sources and files as region_devices. Because region_devices can be chained together forming subregions this allows one to decouple a CBFS source from a file. This also allows one to provide CBFS files that came from other sources for payload and/or stage loading. The program loading takes advantage of those very properties by allowing multiple sources for locating a program. Because of this we can reduce the overhead of loading programs because it's all done in the common code paths. Only locating the program is per source. Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9134 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-16 06:39:23 +02:00
/***********************************************
* Perform CBFS operations on the boot device. *
***********************************************/
Extend CBFS to support arbitrary ROM source media. Summary: Isolate CBFS underlying I/O to board/arch-specific implementations as "media stream", to allow loading and booting romstage on non-x86. CBFS functions now all take a new "media source" parameter; use CBFS_DEFAULT_MEDIA if you simply want to load from main firmware. API Changes: cbfs_find => cbfs_get_file. cbfs_find_file => cbfs_get_file_content. cbfs_get_file => cbfs_get_file_content with correct type. CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM, the ROM may come from USB, UART, or SPI -- any serial devices and not available for memory mapping. To support these devices (and allowing CBFS to read from multiple source at the same time), CBFS operations are now virtual-ized into "cbfs_media". To simplify porting existing code, every media source must support both "reading into pre-allocated memory (read)" and "read and return an allocated buffer (map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*" provides simple memory mapping simulation. Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA is defined for CBFS functions to automatically initialize a per-board default media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS function names relying on memory mapped backend (ex, "cbfs_find" => actually loads files). Now we only have two getters: struct cbfs_file *entry = cbfs_get_file(media, name); void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type); Test results: - Verified to work on x86/qemu. - Compiles on ARM, and follow up commit will provide working SPI driver. Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2182 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-22 11:57:56 +01:00
src/include: Capitalize CPU, RAM and ROM Change-Id: Id40c1bf868820c77ea20146d19c6d552c2f970c4 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/15942 Tested-by: build bot (Jenkins) Reviewed-by: Omar Pakker Reviewed-by: Martin Roth <martinroth@google.com>
2016-07-28 21:25:21 +02:00
/* Return mapping of option ROM found in boot device. NULL on error. */
cbfs: new API and better program loading A new CBFS API is introduced to allow making CBFS access easier for providing multiple CBFS sources. That is achieved by decoupling the cbfs source from a CBFS file. A CBFS source is described by a descriptor. It contains the necessary properties for walking a CBFS to locate a file. The CBFS file is then decoupled from the CBFS descriptor in that it's no longer needed to access the contents of the file. All of this is accomplished using the regions infrastructure by repsenting CBFS sources and files as region_devices. Because region_devices can be chained together forming subregions this allows one to decouple a CBFS source from a file. This also allows one to provide CBFS files that came from other sources for payload and/or stage loading. The program loading takes advantage of those very properties by allowing multiple sources for locating a program. Because of this we can reduce the overhead of loading programs because it's all done in the common code paths. Only locating the program is per source. Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9134 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-16 06:39:23 +02:00
void *cbfs_boot_map_optionrom(uint16_t vendor, uint16_t device);
src/device: Add option to look at revision in option roms AMD's Family 17h SOCs have the same vendor and device IDs for their graphics blocks, but need different video BIOSes. The only difference is the revision number. Add a Kconfig option that allows us to add the revision number of the graphics device to the PCI option rom saved in CBFS. Because searching CBFS takes a non-trivial amount of time, only enable the option if it's needed. If it's not used, or if nothing matches, the check will fall through and search for an option rom with no version. BUG=b:145817712 TEST=With surrounding patches, loads dali vbios Change-Id: Icb610a2abe7fcd0f4dc3716382b9853551240a7a Signed-off-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/2013181 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39792 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-01-21 17:28:40 +01:00
/* Return mapping of option ROM with revision number. Returns NULL on error. */
void *cbfs_boot_map_optionrom_revision(uint16_t vendor, uint16_t device, uint8_t rev);
cbfs: Reflow cbfs.c and cbfs.h to 96-character line lengths Doing this all in one go keeps the files consistent and should make future refactoring easier. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I4a701d24fc9ccd68dce8789aab15fd21964a55f9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49330 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-30 02:33:30 +01:00
cbfs: new API and better program loading A new CBFS API is introduced to allow making CBFS access easier for providing multiple CBFS sources. That is achieved by decoupling the cbfs source from a CBFS file. A CBFS source is described by a descriptor. It contains the necessary properties for walking a CBFS to locate a file. The CBFS file is then decoupled from the CBFS descriptor in that it's no longer needed to access the contents of the file. All of this is accomplished using the regions infrastructure by repsenting CBFS sources and files as region_devices. Because region_devices can be chained together forming subregions this allows one to decouple a CBFS source from a file. This also allows one to provide CBFS files that came from other sources for payload and/or stage loading. The program loading takes advantage of those very properties by allowing multiple sources for locating a program. Because of this we can reduce the overhead of loading programs because it's all done in the common code paths. Only locating the program is per source. Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9134 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-16 06:39:23 +02:00
/* Locate file by name and optional type. Return 0 on success. < 0 on error. */
cbfs: add struct cbfsf Now that cbfs is adding more metadata in the cbfs file header one needs to access that metadata. Therefore, add struct cbfsf which tracks the metadata and data of the file separately. Note that stage and payload metadata specific to itself is still contained within the 'data' portion of a cbfs file. Update the cbfs API to use struct cbfsf. Additionally, remove struct cbfsd as there's nothing else associated with a cbfs region aside from offset and size which tracked by a region_device (thanks, CBFS_ALIGNMENT!). BUG=None BRANCH=None TEST=Built and booted through end of ramstage on qemu armv7. Built and booted glados using Chrome OS. Change-Id: I05486c6cf6cfcafa5c64b36324833b2374f763c2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11679 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-17 23:09:30 +02:00
int cbfs_boot_locate(struct cbfsf *fh, const char *name, uint32_t *type);
cbfs: Add API to locate a file from specific region This patch adds an API to find file by name from any specific region of fmap. Change-Id: Iabe785a6434937be6a57c7009882a0d68f6c8ad4 Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com> Reviewed-on: https://review.coreboot.org/17664 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-12-01 02:29:10 +01:00
/* Locate file in a specific region of fmap. Return 0 on success. < 0 on error*/
int cbfs_locate_file_in_region(struct cbfsf *fh, const char *region_name,
const char *name, uint32_t *type);
cbfs: Reflow cbfs.c and cbfs.h to 96-character line lengths Doing this all in one go keeps the files consistent and should make future refactoring easier. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I4a701d24fc9ccd68dce8789aab15fd21964a55f9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49330 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-30 02:33:30 +01:00
/* Map file into memory, returning a pointer to the mapping or NULL on error. If |size_out| is
not NULL, it will pass out the size of the mapped file.
NOTE: Since this may return a direct pointer to memory-mapped hardware, compressed files are
NOT transparently decompressed (unlike cbfs_load()). */
void *cbfs_map(const char *name, size_t *size_out);
/* Like cbfs_map(), except that it will always read from the read-only CBFS (the "COREBOOT" FMAP
region), even when CONFIG(VBOOT) is enabled. */
void *cbfs_ro_map(const char *name, size_t *size_out);
/* Removes a previously allocated CBFS mapping. Should try to unmap mappings in strict LIFO
order where possible, since mapping backends often don't support more complicated cases. */
int cbfs_unmap(void *mapping);
/* Load a file from CBFS into a buffer. Returns amount of loaded bytes on success or 0 on error.
File will get decompressed as necessary. */
cbfs: Simplify load/map API names, remove type arguments 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-03-05 01:52:08 +01:00
size_t cbfs_load(const char *name, void *buf, size_t buf_size);
cbfs: Reflow cbfs.c and cbfs.h to 96-character line lengths Doing this all in one go keeps the files consistent and should make future refactoring easier. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I4a701d24fc9ccd68dce8789aab15fd21964a55f9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49330 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-30 02:33:30 +01:00
/* Like cbfs_load(), except that it will always read from the read-only CBFS (the "COREBOOT"
FMAP region), even when CONFIG(VBOOT) is enabled. */
cbfs: Introduce cbfs_ro_map() and cbfs_ro_load() This patch introduces two new CBFS API functions which are equivalent to cbfs_map() and cbfs_load(), respectively, with the difference that they always operate on the read-only CBFS region ("COREBOOT" FMAP section). Use it to replace some of the simple cases that needed to use cbfs_locate_file_in_region(). Change-Id: I9c55b022b6502a333a9805ab0e4891dd7b97ef7f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39306 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-01-23 03:00:18 +01:00
size_t cbfs_ro_load(const char *name, void *buf, size_t buf_size);
cbfs: Reflow cbfs.c and cbfs.h to 96-character line lengths Doing this all in one go keeps the files consistent and should make future refactoring easier. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I4a701d24fc9ccd68dce8789aab15fd21964a55f9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49330 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-30 02:33:30 +01:00
/* Load |in_size| bytes from |rdev| at |offset| to the |buffer_size| bytes large |buffer|,
decompressing it according to |compression| in the process. Returns the decompressed file
size, or 0 on error. LZMA files will be mapped for decompression. LZ4 files will be
decompressed in-place with the buffer size requirements outlined in compression.h. */
cbfs: Add LZ4 in-place decompression support for pre-RAM stages This patch ports the LZ4 decompression code that debuted in libpayload last year to coreboot for use in CBFS stages (upgrading the base algorithm to LZ4's dev branch to access the new in-place decompression checks). This is especially useful for pre-RAM stages in constrained SRAM-based systems, which previously could not be compressed due to the size requirements of the LZMA scratchpad and bounce buffer. The LZ4 algorithm offers a very lean decompressor function and in-place decompression support to achieve roughly the same boot speed gains (trading compression ratio for decompression time) with nearly no memory overhead. For now we only activate it for the stages that had previously not been compressed at all on non-XIP (read: non-x86) boards. In the future we may also consider replacing LZMA completely for certain boards, since which algorithm wins out on boot speed depends on board-specific parameters (architecture, processor speed, SPI transfer rate, etc.). BRANCH=None BUG=None TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on Oak to be about ~20ms faster (cutting load times for affected stages almost in half). Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13638 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-29 22:51:35 +02:00
size_t cbfs_load_and_decompress(const struct region_device *rdev, size_t offset,
size_t in_size, void *buffer, size_t buffer_size, uint32_t compression);
cbfs: new API and better program loading A new CBFS API is introduced to allow making CBFS access easier for providing multiple CBFS sources. That is achieved by decoupling the cbfs source from a CBFS file. A CBFS source is described by a descriptor. It contains the necessary properties for walking a CBFS to locate a file. The CBFS file is then decoupled from the CBFS descriptor in that it's no longer needed to access the contents of the file. All of this is accomplished using the regions infrastructure by repsenting CBFS sources and files as region_devices. Because region_devices can be chained together forming subregions this allows one to decouple a CBFS source from a file. This also allows one to provide CBFS files that came from other sources for payload and/or stage loading. The program loading takes advantage of those very properties by allowing multiple sources for locating a program. Because of this we can reduce the overhead of loading programs because it's all done in the common code paths. Only locating the program is per source. Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9134 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-16 06:39:23 +02:00
/* Load stage into memory filling in prog. Return 0 on success. < 0 on error. */
int cbfs_prog_stage_load(struct prog *prog);
exynos: return correct value when init_default_cbfs_media fails BUG=none BRANCH=ToT TEST=Built daisy. Change-Id: I64033f8e7beb247b2b8bd66e58de6c5e263ee634 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 1ff51e887a07a0f2426e5111df683ce2a9d4097d Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: Id6e006be1db08933dc97b5e797a85f3cbf9f6486 Original-Reviewed-on: https://chromium-review.googlesource.com/232513 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9735 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-02 00:30:01 +01:00
cbfs: Move more stuff into cbfs_boot_lookup() cbfs_boot_locate() is supposed to be deprecated eventually, after slowly migrating all APIs to bypass it. That means common features (like RO-fallback or measurement) need to be moved to the new cbfs_boot_lookup(). Also export the function externally. Since it is a low-level API and most code should use the higher-level loading or mapping functions instead, put it into a new <cbfs_private.h> to raise the mental barrier for using this API (this will make more sense once cbfs_boot_locate() is removed from <cbfs.h>). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I4bc9b7cbc42a4211d806a3e3389abab7f589a25a Reviewed-on: https://review.coreboot.org/c/coreboot/+/39327 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-03-05 21:51:08 +01:00
/*
cbfs: Reflow cbfs.c and cbfs.h to 96-character line lengths Doing this all in one go keeps the files consistent and should make future refactoring easier. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I4a701d24fc9ccd68dce8789aab15fd21964a55f9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49330 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-30 02:33:30 +01:00
* Data structure that represents "a" CBFS boot device, with optional metadata cache. Generally
* we only have one of these, or two (RO and RW) when CONFIG(VBOOT) is set. The region device
* stored here must always be a subregion of boot_device_ro().
cbfs: Move more stuff into cbfs_boot_lookup() cbfs_boot_locate() is supposed to be deprecated eventually, after slowly migrating all APIs to bypass it. That means common features (like RO-fallback or measurement) need to be moved to the new cbfs_boot_lookup(). Also export the function externally. Since it is a low-level API and most code should use the higher-level loading or mapping functions instead, put it into a new <cbfs_private.h> to raise the mental barrier for using this API (this will make more sense once cbfs_boot_locate() is removed from <cbfs.h>). Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I4bc9b7cbc42a4211d806a3e3389abab7f589a25a Reviewed-on: https://review.coreboot.org/c/coreboot/+/39327 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-03-05 21:51:08 +01:00
*/
cbfs: Add metadata cache 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>
2019-12-12 02:09:39 +01:00
struct cbfs_boot_device {
struct region_device rdev;
void *mcache;
size_t mcache_size;
};
/* Helper to fill out |mcache| and |mcache_size| in a cbfs_boot_device. */
void cbfs_boot_device_find_mcache(struct cbfs_boot_device *cbd, uint32_t id);
/*
cbfs: Reflow cbfs.c and cbfs.h to 96-character line lengths Doing this all in one go keeps the files consistent and should make future refactoring easier. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I4a701d24fc9ccd68dce8789aab15fd21964a55f9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49330 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-30 02:33:30 +01:00
* Retrieves the currently active CBFS boot device. If |force_ro| is set, will always return the
* read-only CBFS instead (this only makes a difference when CONFIG(VBOOT) is enabled). May
* perform certain CBFS initialization tasks. Returns NULL on error (e.g. boot device IO error).
cbfs: Add metadata cache 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>
2019-12-12 02:09:39 +01:00
*/
const struct cbfs_boot_device *cbfs_get_boot_device(bool force_ro);
Extend CBFS to support arbitrary ROM source media. Summary: Isolate CBFS underlying I/O to board/arch-specific implementations as "media stream", to allow loading and booting romstage on non-x86. CBFS functions now all take a new "media source" parameter; use CBFS_DEFAULT_MEDIA if you simply want to load from main firmware. API Changes: cbfs_find => cbfs_get_file. cbfs_find_file => cbfs_get_file_content. cbfs_get_file => cbfs_get_file_content with correct type. CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM, the ROM may come from USB, UART, or SPI -- any serial devices and not available for memory mapping. To support these devices (and allowing CBFS to read from multiple source at the same time), CBFS operations are now virtual-ized into "cbfs_media". To simplify porting existing code, every media source must support both "reading into pre-allocated memory (read)" and "read and return an allocated buffer (map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*" provides simple memory mapping simulation. Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA is defined for CBFS functions to automatically initialize a per-board default media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS function names relying on memory mapped backend (ex, "cbfs_find" => actually loads files). Now we only have two getters: struct cbfs_file *entry = cbfs_get_file(media, name); void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type); Test results: - Verified to work on x86/qemu. - Compiles on ARM, and follow up commit will provide working SPI driver. Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2182 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-22 11:57:56 +01:00
cbfs: Add verification for RO CBFS metadata hash 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-05-07 02:06:35 +02:00
/*
cbfs: Reflow cbfs.c and cbfs.h to 96-character line lengths Doing this all in one go keeps the files consistent and should make future refactoring easier. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I4a701d24fc9ccd68dce8789aab15fd21964a55f9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49330 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-30 02:33:30 +01:00
* Builds the mcache (if |cbd->mcache| is set) and verifies |metadata_hash| (if it is not NULL).
* If CB_CBFS_CACHE_FULL is returned, the mcache is incomplete but still valid and the metadata
* hash was still verified. Should be called once per *boot* (not once per stage) before the
* first CBFS access.
cbfs: Add verification for RO CBFS metadata hash 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-05-07 02:06:35 +02:00
*/
cb_err_t cbfs_init_boot_device(const struct cbfs_boot_device *cbd,
struct vb2_hash *metadata_hash);
v2/src romfs->cbfs rename This also has the config tool changes in v2/util. Rename romfs.[ch]->cbfs.[ch] and sed romfs->cbfs romtool->cbfstool ROMFS->CBFS Signed-off-by: Peter Stuge <peter@stuge.se> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4113 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-04-14 09:40:01 +02:00
#endif
Reference in a new issue Copy permalink