summaryrefslogtreecommitdiff
path: root/src/lib/fmap.c
AgeCommit message (Collapse)Author
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-09-14lib/fmap: add ENV_SMM check to setup_preram_cacheJosie Nordrum
Add check in setup_preram_cache to return if ENV_SMM is true. This avoids false warning that post-RAM FMAP is accessed too early caused by ENV_ROMSTAGE_OR_BEFORE evaluation in SMI handler. BUG=b:167321319 BRANCH=None TEST=None Signed-off-by: Josie Nordrum <josienordrum@google.com> Change-Id: I3a4c199c42ee556187d6c4277e8793a36e4d493b Reviewed-on: https://review.coreboot.org/c/coreboot/+/45274 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-08-21lib: Update fmap cache error for psp_verstageMartin Roth
The assumption was that the fmap cache would be initialized in bootblock, otherwise an error is shown. This error is showing up in psp_verstage when the fmap cache is initialized there, so create a new ENV value for ENV_INITIAL_STAGE. BUG=None TEST=Boot, see that error message is gone from psp_verstage Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I142f2092ade7b4327780d423d121728bfbdab247 Reviewed-on: https://review.coreboot.org/c/coreboot/+/43488 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-11treewide: Remove "this file is part of" linesPatrick Georgi
Stefan thinks they don't add value. Command used: sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool) The exceptions are for: - crossgcc (patch file) - gcov (imported from gcc) - elf.h (imported from GNU's libc) - nvramtool (more complicated header) The removed lines are: - fmt.Fprintln(f, "/* This file is part of the coreboot project. */") -# This file is part of a set of unofficial pre-commit hooks available -/* This file is part of coreboot */ -# This file is part of msrtool. -/* This file is part of msrtool. */ - * This file is part of ncurses, designed to be appended after curses.h.in -/* This file is part of pgtblgen. */ - * This file is part of the coreboot project. - /* This file is part of the coreboot project. */ -# This file is part of the coreboot project. -# This file is part of the coreboot project. -## This file is part of the coreboot project. --- This file is part of the coreboot project. -/* This file is part of the coreboot project */ -/* This file is part of the coreboot project. */ -;## This file is part of the coreboot project. -# This file is part of the coreboot project. It originated in the - * This file is part of the coreinfo project. -## This file is part of the coreinfo project. - * This file is part of the depthcharge project. -/* This file is part of the depthcharge project. */ -/* This file is part of the ectool project. */ - * This file is part of the GNU C Library. - * This file is part of the libpayload project. -## This file is part of the libpayload project. -/* This file is part of the Linux kernel. */ -## This file is part of the superiotool project. -/* This file is part of the superiotool project */ -/* This file is part of uio_usbdebug */ Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-04src/lib: Use SPDX for GPL-2.0-only filesAngel Pons
Done with sed and God Lines. Only done for C-like code for now. Change-Id: Id3a0b63272ebda3dad13803700bcff36d36f4815 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40054 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2020-03-17src (minus soc and mainboard): Remove copyright noticesPatrick Georgi
They're listed in AUTHORS and often incorrect anyway, for example: - What's a "Copyright $year-present"? - Which incarnation of Google (Inc, LLC, ...) is the current copyright holder? - People sometimes have their editor auto-add themselves to files even though they only deleted stuff - Or they let the editor automatically update the copyright year, because why not? - Who is the copyright holder "The coreboot project Authors"? - Or "Generated Code"? Sidestep all these issues by simply not putting these notices in individual files, let's list all copyright holders in AUTHORS instead and use the git history to deal with the rest. Change-Id: I89b10076e0f4a4b3acd59160fb7abe349b228321 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39611 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
2019-12-11fmap: Make FMAP_CACHE mandatory if it is configured inJulius Werner
Now that we have a CONFIG_NO_FMAP_CACHE to completely configure out the pre-RAM FMAP cache code, there's no point in allowing the region to be optional anymore. This patch makes the section required by the linker. If a board doesn't want to provide it, it has to select NO_FMAP_CACHE. Adding FMAP_CACHE regions to a couple more targets that I think can use them but I don't know anything about... please yell if one of these is a bad idea and I should mark them NO_FMAP_CACHE instead. Change-Id: Ic7d47772ab3abfa7e3a66815c3739d0af071abc2 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37497 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2019-11-29lib/fmap.c: Drop CAR_GLOBAL_MIGRATION supportArthur Heymans
Change-Id: Ibf80d3e37f702c75c30394a14ce0a91af84a6b93 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37033 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-11-19lib/fmap: Disable pre-RAM cache for FSP 1.0Julius Werner
Due to the way CAR teardown is handled in FSP 1.0, the results of car_get_var_ptr() aren't always reliable, which can break things when running with FMAP cache. It might be possible to fix this but would make the code rather complicated, so let's just disable the feature on these platforms and hope they die out soon. Also allow this option to be used by platforms that don't have space for the cache and want to save a little more code. Change-Id: I7ffb1b8b08a7ca3fe8d53dc827e2c8521da064c7 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36937 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-11-14lib/fmap: Add optional pre-RAM cacheJulius Werner
This patch adds an optional pre-RAM cache for the FMAP which most platforms should be able to use, complementing the recently added post-RAM FMAP cache in CBMEM. vboot systems currently read the FMAP about half a dozen times from flash in verstage, which will all be coalesced into a single read with this patch. It will also help future vboot improvements since when FMAP reads become "free" vboot doesn't need to keep track of so much information separately. In order to make sure we have a single, well-defined point where the new cache is first initialized, eliminate the build-time hardcoding of the CBFS section offsets, so that all CBFS accesses explicitly read the FMAP. Add FMAP_CACHEs to all platforms that can afford it (other than the RISC-V things where I have no idea how they work), trying to take the space from things that look like they were oversized anyway (pre-RAM consoles and CBFS caches). Change-Id: I2820436776ef620bdc4481b5cd4b6957764248ea Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36657 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Joel Kitching <kitching@google.com>
2019-11-11region: add rdev_chain_full()Aaron Durbin
Instead of open coding an offset of 0 and querying the size of a region device provide a rdev_chain_full() helper function that does that for the caller. For the existing users that match this pattern convert them to using rdev_chain_full(). Change-Id: Ie316790a8a5b16a7f7e22f86f58bd2e633c19450 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36683 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-09-27fmap: Add get_fmap_flash_offset()Furquan Shaikh
CB:35377 changed the behavior of find_fmap_directory() to return pointer to CBMEM_ID_FMAP if fmap is cached in cbmem. lb_boot_media_params() calls find_fmap_directory to add offset of fmap in flash to coreboot table. However, because of the change in behavior of find_fmap_directory(), it ended up adding 0 as the offset. This change adds a new function get_fmap_flash_offset() which returns the offset of fmap in flash. Ideally, all payloads should move to using the FMAP from CBMEM. However, in order to maintain compatibility with payloads which are not updated, ensure that fmap_offset is updated correctly. Since find_fmap_directory() is no longer used outside fmap.c, this change also removes it from fmap.h and limits scope to fmap.c. In a follow up patch, we need to push a change to libpayload to expose the fmap cache pointer to lib_sysinfo. BUG=b:141723751 Change-Id: I7ff6e8199143d1a992a83d7de1e3b44813b733f4 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35639 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Shelley Chen <shchen@google.com>
2019-09-23lib/fmap: Cache FMAP in cbmemPatrick Rudolph
For platform independend exposure of FMAP through a kernel module cache the FMAP in CBMEM. In addition add a pointer in coreboot tables pointing to the introduced CBMEM area. To not waste the allocated DRAM, use the cached CBMEM in RAM enabled stages if possible. Tested on qemu using https://github.com/9elements/linux/commits/google_firmware_fmap2 Tested on QEMU and Supermicro X11SSH-TF. Change-Id: I4e01c573c3edfa34dbba5fe7604d4f6e18b584d5 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35377 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-04-23lib/fmap: Add area read/write functionsT Michael Turney
Change-Id: I7669b8dc07b1aa5f00e7d8d0b1305b3de6c5949c Signed-off-by: T Michael Turney <mturney@codeaurora.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32287 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2016-08-19lib/fmap: provide RW region device supportAaron Durbin
Explicitly provide a RW view of an FMAP region. This is required for platforms which have separate implementations of a RO boot device and a RW boot device. BUG=chrome-os-partner:56151 Change-Id: Ibafa3dc534f53a3d90487f3190c0f8a2e82858c2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16203 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-05-11lib: remove FLASHMAP_OFFSET config variableAaron Durbin
The FLASHMAP_OFFSET config variable is used in lib/fmap.c, however the fmdtool creates a fmap_config.h with a FMAP_OFFSET #define. Those 2 values are not consistent. Therefore, remove the Kconfig variable and defer to the #define generated by fmdtool. Change-Id: Ib4ecbc429e142b3e250106eea59fea1caa222917 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14765 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
2016-02-13FMAP: Clean up debug outputDuncan Laurie
Reduce the debug output from FMAP lookups. When we had one or two FMAP lookups in a boot this was not a big deal, but now that we do many lookups it is a lot of unnecessary output duplication. This change reduces these 3 lines: FMAP: area VBLOCK_A found FMAP: offset: 200000 FMAP: size: 65536 bytes To just one line: FMAP: area VBLOCK_A found @ 200000 (65536 bytes) And makes the header output only print once: FMAP: Found "FMAP" version 1.0 at c10000. FMAP: base = 0 size = 1000000 #areas = 29 BUG=chrome-os-partner:40635 BRANCH=glados TEST=boot on chell and enjoy non-truncated memconsole Change-Id: Ib5862b8bfad113a700faae89089557094aa6d499 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 6890f36536d4ae6fc4988fc8191b0cff4e33e2e6 Original-Change-Id: Ifefee1ab26e6ee406de552880fbbd5b7916fcadd Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/326887 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13695 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-09-22coreboot: introduce commonlibAaron Durbin
Instead of reaching into src/include and re-writing code allow for cleaner code sharing within coreboot and its utilities. The additional thing needed at this point is for the utilities to provide a printk() declaration within a <console/console.h> file. That way code which uses printk() can than be mapped properly to verbosity of utility parameters. Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11592 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-07-14fmap: publish find_fmap_directory()Patrick Georgi
The fmap directory can be useful to pass to the payload. For that, we need to be able to get it. Change-Id: Ibe0be73bb4fe28afb16d4d215b979eb0be369645 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10866 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-14fmap: Introduce new function to derive fmap name from offset/sizePatrick Georgi
vboot passes around the offset and size of the region to use in later stages. To assign more meaning to this pair, provide a function that returns the fmap area name if there's a precise match (and an error otherwise). Change-Id: I5724b860271025c8cb8b390ecbd33352ea779660 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10865 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-05-26fmap: new API using region_deviceAaron Durbin
Instead of being pointer based use the region infrastrucutre. Additionally, this removes the need for arch-specific compilation paths. The users of the new API can use the region APIs to memory map or read the region provided by the new fmap API. Change-Id: Ie36e9ff9cb554234ec394b921f029eeed6845aee Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9170 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>