Add buffer_end() function to common.h. This function returns a
pointer to the end of the buffer (exclusive).
This is needed by elogtool util. (See the next CL in the chain).
BUG=b:172210863
Change-Id: I380eecbc89c13f5fe5ab4c31d7a4fef97690a791
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56987
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add the binary output of the new elogtool to the .gitignore, so that
running "make -C util/cbfstool" keeps the tree clean.
Signed-off-by: Jack Rosenthal <jrosenth@chromium.org>
Change-Id: I806338a4b33abbc3d55e4edef2736c19d56fa005
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56864
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
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>
The -a flag was already implemented, it just wasn't exposed for the
add-payload command.
Setting the alignment of the payload will enable using the SPI DMA
controller to read the payload on AMD devices.
BUG=b:179699789
TEST=cbfstool foo.bin add-payload -a 64 ...
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I9f4aea5f0cbeaa8e761212041099b37f4718ac39
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55973
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
The dereferced parameter is never updated so passing a copy would work
too.
Change-Id: Ie36f64f55d4fc7034780116c28aaed65aa304d5e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55792
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Vboot's Makefile is controlled by a ${DEBUG} environment variable.
As the name is very generic, it may be set by accident without any
intention to change the build. Having it set would break reproduci-
bility at least but it also turns out that the hostlib build would
be incomplete so that linking cbfstool fails due to internal calls
to vb2api_fail() which is not built in.
Change-Id: I2a9eb9a645c70451a320c455b8f24bfed197117c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The null-termination of `filetypes` was added after the code was
written, obviously resulting in NULL dereferences. As some more
code has grown around the termination, it's hard to revert the
regression, so let's update the code that still used the array
length.
This fixes commit 7f5f9331d1 (util/cbfstool: fix buffer over-read)
which actually did fix something, but only one path while it broke
two others. We should be careful with fixes, they can always break
something else. Especially when a dumb tool triggered the patching
it seems likely that fewer people looked into related code.
Change-Id: If2ece1f5ad62952ed2e57769702e318ba5468f0c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55763
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This fixes a hard to debug hang that could occur in any stage, but in
the end it follows simple rules and is easy to fix.
In long mode the 32bit displacement addressing used on 'mov' and 'lea'
instructions is sign-extended. Those instructions can be found using
readelf on the stage and searching for relocation type R_X86_64_32S.
The sign extension is no issue when either running in protected mode or
the code module and thus the address is below 2GiB. If the address is
greater than 2GiB, as usually the case for code in TSEG, the higher
address bits [64:32] are all set to 1 and the effective address is
pointing to memory not paged. Accessing this memory will cause a page
fault, which isn't handled either.
To prevent such problems
- disable R_AMD64_32S relocations in rmodtool
- add comment explaining why it's not allowed
- use the pseudo op movabs, which doesn't use 32bit displacement addressing
- Print a useful error message if such a reloc is present in the code
Fixes a crash in TSEG and when in long mode seen on Intel Sandybridge.
Change-Id: Ia5f5a9cde7c325f67b12e3a8e9a76283cc3870a3
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55448
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The e820 type don't fully match the LB_TAG_MEMORY types, so change all
unknown types to e820 to '2', reserved memory.
TESTED with Linuxboot: e820 now shows the CBMEM region as reserved.
Change-Id: Ie0e41c66e002919e41590327afe0f543e0037369
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55074
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Rocky Phagura
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is a function to fetch the fit table at both the regular address
and the TS address. So reuse that function instead of attempting to
find the TS fit using some pointer aritmetics that is incorrect.
Change-Id: I9114f5439202ede7e01cd0fcbb1e3c4cdb8698b0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54680
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-by: Meera Ravindranath <meera.ravindranath@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fixes compilation on FreeBSD CURRENT, and possibly other releases.
The compiler, clang, complained about:
util/cbfstool/cbfstool.c:181:40: error: implicit declaration of function 'memmem' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
util/cbfstool/cbfstool.c:181:31: error: incompatible integer to pointer conversion initializing 'struct metadata_hash_anchor *' with an expression of type 'int' [-Werror,-Wint-conversion]
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Change-Id: I45c02a21709160df44fc8da329f6c4a9bad24478
Reviewed-on: https://review.coreboot.org/c/coreboot/+/53996
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The purpose of this is to eventually move the FIT table out of the
bootblock, generate it separately as a cbfs file and then have the FIT
pointer point to that cbfs file.
TESTED: extracted a FIT table using dd, added it as a cbfs file and see
that the FIT pointer correctly points to it. Also test that trying to
add a non valid FIT cbfs file results in an error.
Change-Id: I6e38b7df31e6b30f75b0ae57a5332f386e00f16b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50925
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
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>
The --alignment flag is currently only handled by cbfstool add, but
there seems little reason to not handle it for all file-adding commands
(the help text actually mentions it for add-stage as well but it doesn't
currently work there). This patch moves the related code (and the
related baseaddress handling) into cbfs_add_component(). As a nice side
effect this allows us to rearrange cbfs_add_component() such that we can
conclusively determine whether we need a hash attribute before trying to
align the file, allowing that code to correctly infer the final header
size even when a hash attribute was implicitly added (for an image built
with CBFS verification enabled).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Idc6d68b2c7f30e5d136433adb3aec5a87053f992
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47823
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The 'x' option is not set up in the getopt options.
Change-Id: Ib4aa10b0ea2a3f97e8d2439152b708613bcf43db
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50923
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
To support the new CONFIG_CBFS_VERIFICATION feature, cbfstool needs to
update the metadata hash embedded in the bootblock code every time it
adds or removes a CBFS file. This can lead to problems on certain
platforms where the bootblock needs to be specially wrapped in some
platform-specific data structure so that the platform's masked ROM can
recognize it. If that data structure contains any form of hash or
signature of the bootblock code that is checked on every boot, it will
no longer match if cbfstool modifies it after the fact.
In general, we should always try to disable these kinds of features
where possible (they're not super useful anyway). But for platforms
where the hardware simply doesn't allow that, this patch introduces the
concept of "platform fixups" to cbfstool. Whenever cbfstool finds a
metadata hash anchor in a CBFS image, it will run all built-in "fixup
probe" functions on that bootblock to check if it can recognize it as
the wrapper format for a platform known to have such an issue. If so, it
will register a corresponding fixup function that will run whenever it
tries to write back modified data to that bootblock. The function can
then modify any platform-specific headers as necessary.
As first supported platform, this patch adds a fixup for Qualcomm
platforms (specifically the header format used by sc7180), which
recalculates the bootblock body hash originally added by
util/qualcomm/createxbl.py.
(Note that this feature is not intended to support platform-specific
signature schemes like BootGuard directly in cbfstool. For anything that
requires an actual secret key, it should be okay if the user needs to
run a platform-specific signing tool on the final CBFS image before
flashing. This feature is intended for the normal unsigned case (which
on some platforms may be implemented as signing with a well-known key)
so that on a board that is not "locked down" in any way the normal use
case of manipulating an image with cbfstool and then directly flashing
the output file stays working with CONFIG_CBFS_VERIFICATION.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I02a83a40f1d0009e6f9561ae5d2d9f37a510549a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41122
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds support for the new CONFIG_CBFS_VERIFICATION feature to
cbfstool. When CBFS verification is enabled, cbfstool must automatically
add a hash attribute to every CBFS file it adds (with a handful of
exceptions like bootblock and "header" pseudofiles that are never read
by coreboot code itself). It must also automatically update the metadata
hash that is embedded in the bootblock code. It will automatically find
the metadata hash by scanning the bootblock for its magic number and use
its presence to auto-detect whether CBFS verification is enabled for an
image (and which hash algorithm to use).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I61a84add8654f60c683ef213b844a11b145a5cb7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41121
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
In a rare placement edge case when adding a file with alignment
requirements, cbfstool may need to generate a CBFS header that's
slightly larger than it needs to be. The way we do this is by just
increasing the data offset field in the CBFS header until the data falls
to the desired value.
This approach works but it may confuse parsing code in the presence of
CBFS attributes. Normally, the whole area between the attribute offset
and the data offset is filled with valid attributes written back to
back, but when this header expansion occurs the attributes are followed
by some garbage data (usually 0xff). Parsers are resilient against this
but may show unexpected error messages.
This patch solves the problem by moving the attribute offset forwards
together with the data offset, so that the total area used for
attributes doesn't change. Instead, the filename field becomes the
expanded area, which is a closer match to how this worked when it was
originally implemented (before attributes existed) and is less confusing
for parsers since filenames are zero-terminated anyway.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I3dd503dd5c9e6c4be437f694a7f8993a57168c2b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47824
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The *location argument to parse_elf_to_stage() is a relic from code all
the way back to 2009 where this function was still used to parse XIP
stages. Nowadays we have a separate parse_elf_to_xip_stage() for that,
so there is no need to heed XIP concerns here. Having a pointer to
represent the location in flash is absolutely irrelevant to a non-XIP
stage, and it is used incorrectly -- we just get lucky that no code path
in cbfstool can currently lead to that value being anything other than
0, otherwise the adjustment of data_start to be no lower than *location
could easily screw things up. This patch removes it.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia7f850c0edd7536ed3bef643efaae7271599313d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49369
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Memlayout is a mechanism to define memory areas outside the normal
program segment constructed by the linker. Therefore, it generally
doesn't make sense to relocate memlayout symbols when the program is
relocated. They tend to refer to things that are always in one specific
spot, independent of where the program is loaded.
This hasn't really hurt us in the past because the use case we have for
rmodules (ramstage on x86) just happens to not really need to refer to
any memlayout-defined areas at the moment. But that use case may come up
in the future so it's still worth fixing.
This patch declares all memlayout-defined symbols as ABSOLUTE() in the
linker, which is then reflected in the symbol table of the generated
ELF. We can then use that distinction to have rmodtool skip them when
generating the relocation table for an rmodule. (Also rearrange rmodtool
a little to make the primary string table more easily accessible to the
rest of the code, so we can refer to symbol names in debug output.)
A similar problem can come up with userspace unit tests, but we cannot
modify the userspace relocation toolchain (and for unfortunate
historical reasons, it tries to relocate even absolute symbols). We'll
just disable PIC and make those binaries fully static to avoid that
issue.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ic51d9add3dc463495282b365c1b6d4a9bf11dbf2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50629
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix regression from commit 0dcc0662f3 util/cbfstool: Introduce
concept of mmap_window.
Use of region_end() wraps around at 4 GiB, if utility is run in
32bit userspace. The build completes with an invalid coreboot.rom,
while one can find error message in stdout or make.log:
E: Host address(ffc002e4) not in any mmap window!
Change-Id: Ib9b6b60c7b5031122901aabad7b3aa8d59f1bc68
Signed-off-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50618
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Compilation has been broken in commit I022468f6957415ae68a7a7e70428ae6f82d23b06
Adding a missing define solved this. See https://cgit.freebsd.org/src/tree/sys/sys/fcntl.h#n319
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Change-Id: I3433e4c9269880d3202dd494e5b2e962757a6b87
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49314
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Trying to do multiple operations on the same CBFS image at the same time
likely leads to data corruption. For this reason, add BSD advisory file
locking (flock()) to cbfstool (and ifittool which is using the same file
I/O library), so that only one process will operate on the same file at
the same time and the others will wait in line. This should help resolve
parallel build issues with the INTERMEDIATE target on certain platforms.
Unfortunately, some platforms use the INTERMEDIATE target to do a direct
dd into the CBFS image. This should generally be discouraged and future
platforms should aim to clearly deliminate regions that need to be
written directly by platform scripts with custom FMAP sections, so that
they can be written with `cbfstool write`. For the time being, update
the legacy platforms that do this with explicit calls to the `flock`
utility.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I022468f6957415ae68a7a7e70428ae6f82d23b06
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Currently, use of the VPD driver to read VPD tables from flash
requires the use of a custom FMAP with one or more VPD regions.
Extend this funtionality to boards using the default FMAP by
creating a dedicated VPD region when the driver is selected.
Test: build qemu target with CONFIG_VPD selected, verify entry
added to build/fmap.fmd.
Change-Id: Ie9e3c7cf11a6337a43223a6037632a4d9c84d988
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49049
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Currently, the option to cache DIMM SPD data in an FMAP region
is closely coupled to a single board (google/hatch) and requires
a custom FMAP to utilize.
Loosen this coupling by introducing a Kconfig option which adds
a correctly sized and aligned RW_SPD_CACHE region to the default FMAP.
Add a Kconfig option for the region name, replacing the existing hard-
coded instance in spd_cache.h. Change the inclusion of spd_cache.c to
use this new Kconfig, rather than the board-specific one currently used.
Lastly, have google/hatch select the new Kconfig when appropriate to
ensure no change in current functionality.
Test: build/boot WYVERN google/hatch variant with default FMAP, verify
FMAP contains RW_SPD_CACHE, verify SPD cache used via cbmem log.
Also tested on an out-of-tree Purism board.
Change-Id: Iee0e7acb01e238d7ed354e3dbab1207903e3a4fc
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48520
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds support in fmaptool to generate a macro in C header
file that provides a list of section names that do not have any
subsections. This is useful for performing build time tests on these
sections.
BUG=b:171534504
Change-Id: Ie32bb8af4a722d329f9d4729722b131ca352d47a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
All x86 platforms until now have memory mapped up to a maximum of
16MiB of SPI flash just below 4G boundary in host address space. For
newer platforms, cbfstool needs to be able to accommodate additional
windows in the host address space for mapping SPI flash size greater
than 16MiB.
This change adds two input parameters to cbfstool ext-win-base and
ext-win-size which a platform can use to provide the details of the
extended window in host address space. The extended window does not
necessarily have to be contiguous with the standard decode window
below 4G. But, it is left upto the platform to ensure that the fmap
sections are defined such that they do not cross the window boundary.
create_mmap_windows() uses the input parameters from the platform for
the extended window and the flash size to determine if extended mmap
window is used. If the entire window in host address space is not
covered by the SPI flash region below the top 16MiB, then mapping is
assumed to be done at the top of the extended window in host space.
BUG=b:171534504
Change-Id: Ie8f95993e9c690e34b0e8e792f9881c81459c6b6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47882
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds the concept of mmap_window to describe how the SPI
flash address space is mapped to host address space on x86
platforms. It gets rid of the assumption that the SPI flash address
space is mapped only below the 4G boundary in host space. This is
required in follow up changes to be able to add more decode windows
for the SPI flash into the host address space.
Currently, a single mmap window is added i.e. the default x86 decode
window of maximum 16MiB size living just below the 4G boundary. If the
window is smaller than 16MiB, then it is mapped at the top of the host
window.
BUG=b:171534504
TEST=Verified using abuild with timeless option for all coreboot
boards that there is no change in the resultant coreboot.rom file.
Change-Id: I8dd3d1c922cc834c1e67f279ffce8fa438d8209c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47831
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This change renames the macro `IS_TOP_ALIGNED_ADDRESS` to
`IS_HOST_SPACE_ADDRESS` to make it clear that the macro checks if
given address is an address in the host space as opposed to the SPI
flash space.
BUG=b:171534504
Change-Id: I84bb505df62ac41f1d364a662be145603c0bd5fa
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47830
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cbfstool overloads baseaddress to represent multiple things:
1. Address in SPI flash space
2. Address in host space (for x86 platforms)
3. Offset from end of region (accepted as negative number)
This was done so that the different functions that use these
addresses/offsets don't need to be aware of what the value represents
and can use the helper functions convert_to_from* to get the required
values.
Thus, even if the user provides a negative value to represent offset
from end of region, it was stored as an unsigned integer. There are
special checks in convert_to_from_top_aligned which guesses if the
value provided is really an offset from the end of region and converts
it to an offset from start of region.
This has worked okay until now for x86 platforms because there is a
single fixed decode window mapping the SPI flash to host address
space. However, going forward new platforms might need to support more
decode windows that are not contiguous in the host space. Thus, it is
important to distinguish between offsets from end of region and
addresses in host/SPI flash space and treat them separately.
As a first step towards supporting this requirement for multiple
decode windows on new platforms, this change handles the negative
offset provided as input in dispatch_command before the requested cbfs
operation is performed.
This change adds baseaddress_input, headeroffset_input and
cbfsoffset_input to struct param and converts them to offsets from
start of region before storing into baseaddress, headeroffset and
cbfsoffset if the inputs are negative.
In follow up changes, cbfstool will be extended to add support
for multiple decode windows.
BUG=b:171534504
TEST=Verified using abuild with timeless option for all coreboot
boards that there is no change in the resultant coreboot.rom file.
Change-Id: Ib74a7e6ed9e88fbc5489640d73bedac14872953f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47829
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
With the upcoming introduction of CBFS verification, a lot more CBFS
files will have hashes. The current cbfstool default of always printing
hash attributes when they exist will make cbfstool print very messy.
Therefore, hide hash attribute output unless the user passed -v.
It would also be useful to be able to get file attributes like hashes in
machine parseable output. Unfortunately, our machine parseable format
(-k) doesn't really seem designed to be extensible. To avoid breaking
older parsers, this patch adds new attribute output behind -v (which
hopefully no current users pass since it doesn't change anything for -k
at the moment). With this patch cbfstool print -k -v may print an
arbitrary amount of extra tokens behind the predefined ones on a file
line. Tokens always begin with an identifying string (e.g. 'hash'),
followed by extra fields that should be separated by colons. Multiple
tokens are separated by the normal separator character (tab).
cbfstool print -k -v may also print additional information that applies
to the whole CBFS on separate lines. These lines will always begin with
a '[' (which hopefully nobody would use as a CBFS filename character
although we technically have no restrictions at the moment).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I9e16cda393fa0bc1d8734d4b699e30e2ae99a36d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41119
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This function name clashes with cbfs_walk() in the new commonlib CBFS
stack, so rename it to cbfs_legacy_walk(). While we could replace it
with the new commonlib implementation, it still has support for certain
features in the deprecated pre-FMAP CBFSes (such as non-standard header
alignment), which are needed to handle old files but probably not
something we'd want to burden the commonlib implementation with. So
until we decide to deprecate support for those files from cbfstool as
well, it seems easier to just keep the existing implementation here.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I37c7e7aa9a206372817d8d0b8f66d72bafb4f346
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41118
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
Our current cbfstool has always added a compression attribute to the
CBFS file header for all files that used the cbfstool_convert_raw()
function (basically anything other than a stage or payload), even if the
compression type was NONE. This was likely some sort of oversight, since
coreboot CBFS reading code has always accepted the absence of a
compression attribute to mean "no compression". This patch fixes the
behavior to avoid adding the attribute in these cases.
Change-Id: Ic4a41152db9df66376fa26096d6f3a53baea51de
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The compress and uncompress options don't have arguments and shouldn't
consume the next token. So replace required_argument with no_argument
for the two options.
Change-Id: Ib9b190f2cf606109f82a65d00327871d6ffb7082
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47573
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Both the help and the maxsize option had the same short option character
assigned. Change the short option for maxsize to m to fix this and to
make it consistent with the rest of the code.
Change-Id: Icac1a7d4906345c37a5c7bed2b4995fea25f860e
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47574
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
These were originally ignored only inside util/ but these files
shouldn't be tracked anywhere.
Change-Id: Ie0846bd8bdd6e52f420f9dd2e72a8a922102ff90
Signed-off-by: Patrick Georgi <patrick@georgi.software>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47012
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
There's no need for the global list of files to ignore, so use git's
ability to work with more local configuration.
Change-Id: I50882e6756cbc0fdfd899353cc23962544690fb3
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46879
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These sources are built but not used by cbfstool. The only .c file in
commonlib/ it really needs is fsp_relocate.c. Get rid of the others.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I6ebbb4161874f6279b6dbaffe7c3144226a6f9b9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46253
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add defines for the start and size of the FMAP sections to the
optionally generated header file. For the defines the name of the
corresponding FMAP section is used without the full path, since every
section name should be unique anyway as documented here:
Documentation/lib/flashmap.md
BUG=b:157068645
TEST=Generated header file contains expected defines.
BRANCH=zork
Change-Id: Ie31161cfd304b69a3cb4bb366bf365d979e77c64
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45594
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
One bit wide bitfields should always be unsigned, since they can only be
either 0 or -1, but never 1 which is assigned to that bit field in some
cases. Making this unsigned allows it to have the values 0 or 1 which is
what we want there.
BUG=b:157068645
BRANCH=zork
Change-Id: I99c236df583528848b455ef424504e6c2a33c5d6
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45593
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Ricardo Quesada