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>
Vboot determines openssl through pkgconfig, so pointing its build
system to /bin/true makes the build not break unless it needs to use
valid information about openssl.
Vboot's use of openssl is only for some special features, mostly around
PKCS key format parsing and not needed by cbfstool. While cbfstool
can link vboot, it can't link with openssl because openssl's license
is deliberately incompatible with the GPL.
Change-Id: Ia3825f9625a1964d7cefc47ab3c3a8250ceefafb
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
For add-stage command, --pow2page is equivalent of passing
-P log2ceil(sizeof stage). The sizeof stage can be hard to
determine in Makefile to be passed on the commandline.
Change-Id: If4b5329c1df5afe49d27ab10220095d747024ad6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41832
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This change drops the check for IS_TOP_ALIGNED_ADDRESS() before
setting offset to 0 in cbfstool_convert_fsp(). If the user provides a
baseaddress to relocate the FSP to, then the offset should be set to 0
since there is no requirement on where the file ends up in cbfs. This
allows the user to relocate the FSP to an address in lower DRAM.
BUG=b:155322763
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ibeadbf06881f7659b2ac7d62d2152636c853fb9f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42263
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix unterminated array.
When looking for a type not specified in filetypes (cbfs.h:204), the
loop in lookup_name_by_type (cbfs_image.c:60) will run into a buffer
over-read.
Found-by: AFL++ 2.64d rev 1317433
Signed-off-by: Philipp Bartsch <phil@grmr.de>
Change-Id: Ib82bb92e82b09fa1e26b9ca34529ec7b98e8f7b1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41421
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
We have the git history which is a more reliable librarian.
Change-Id: Idbcc5ceeb33804204e56d62491cb58146f7c9f37
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41175
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: ron minnich <rminnich@gmail.com>
This replaces GPLv2-or-later and GPLv2-only long form text with the
short SPDX identifiers.
Commands used:
perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*as.*published.*by.*the.*Free.*Software.*Foundation[;,].*version.*2.*of.*the.*License.*or.*(at.*your.*option).*any.*later.*version.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-or-later */|s' $(cat filelist)
perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*as.*published.*by.*the.*Free.*Software.*Foundation[;,].*version.*2.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist)
perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*version.*2.*as.*published.*by.*the.*Free.*Software.*Foundation[.;,].+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist)
perl -i -p0e 's|/\*[*\n\t ]*This software is licensed under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*version.*2.*as.*published.*by.*the.*Free.*Software.*Foundation,.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist)
Change-Id: I7a746088a35633c11fc7ebe86006e96458a1abf8
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41066
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Also split "this is part of" line from copyright notices.
Change-Id: Ibc2446410bcb3104ead458b40a9ce7819c61a8eb
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
That makes it easier to identify "license only" headers (because they
are now license only)
Script line used for that:
perl -i -p0e 's|/\*.*\n.*This file is part of the coreboot project.*\n.*\*|/* This file is part of the coreboot project. */\n/*|' # ...filelist...
Change-Id: I2280b19972e37c36d8c67a67e0320296567fa4f6
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41065
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
CB:29744 ("util/cbfstool: Add optional argument ibb") added support
for non-ASCII characters for long_options. However, there is a check
later on which errors out since this character is not one of the
commands[i].optstring.
This change adds a function valid_opt() which does the following
things:
1. Checks if the returned optchar is among the list of optstring
supported by the command.
2. Checks if the returned optchar is a valid non-ASCII
option. Currently, we do not maintain a list of non-ASCII options
supported by each command. So, this function returns true if the
optchar returned by getopt_long falls within the allowed range.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I27a4f9af9850e4c892573202904fa9e5fbb64df6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40375
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Currently cbfstool cherry-picks a few files from vboot and hopes these
files will work standalone without any dependencies. This is pretty
brittle (for example, CL:2084062 will break it), and could be improved
by building the whole vboot library and then linking against it.
Therefore, this patch creates a new target $(VBOOT_HOSTLIB) and includes
it as a dependency for cbfstool and ifittool.
To prevent building the vboot lib twice (one for cbfstool and the other
for futility) when building coreboot tools together, add the variable
'VBOOT_BUILD' in Makefile to define a shared build path among different
tools so that vboot files don't need to be recompiled.
Also ignore *.o.d and *.a for vboot library.
BRANCH=none
BUG=none
TEST=make -C util/cbfstool
TEST=make -C util/futility
TEST=Run 'make tools' and make sure common files such as 2sha1.c are
compiled only once
TEST=emerge-nami coreboot-utils
Change-Id: Ifc826896d895f53d69ea559a88f75672c2ec3146
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39390
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Fix two out-of-bounds reads in lz4 decompression:
1) LZ4_decompress_generic could read one byte past the input buffer when
decoding variable length literals due to a missing bounds check. This
issue was resolved in libpayload, commonlib and cbfstool
2) ulz4fn could read up to 4 bytes past the input buffer when reading a
lz4_block_header due to a missing bounds check. This issue was resolved
in libpayload and commonlib.
Change-Id: I5afdf7e1d43ecdb06c7b288be46813c1017569fc
Signed-off-by: Alex Rebert <alexandre.rebert@gmail.com>
Found-by: Mayhem
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Newest clang compilers warn about "misleading indentation", and because
warnings-are-errors in our builds, that breaks the build.
The lzma code base is vendored in, so we might just have to update it,
but that's a bigger effort than just removing a couple of spaces (the
coding style of the file is horrible, but I will only change it as much
as the compilers ask for).
BUG=chromium:1039526
Change-Id: I6b9d7a760380081af996ea5412d7e3e688048bfd
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38637
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
In glibc feature control macros, _DEFAULT_SOURCE is the shorthand to
tell glibc to enable "all the default stuff", meaning POSIX, BSD and
System V interfaces. However, this macro is somewhat recent and older
glibc versions (e.g. 2.12) are still occasionally in use that don't
recognize it yet. For the benefits of users with these versions, let's
also enable the deprecated _BSD_SOURCE and _SVID_SOURCE macros which
essentially achieve the same thing. We must continue to define
_DEFAULT_SOURCE so that newer glibc versions don't throw a deprecation
warning.
This patch should make BSD-style byteswap macros like le32toh()
available on these older glibc versions.
Change-Id: I019bbcf738a1bcdccd7b299bdde29cd4d4ded134
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38638
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
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>
The ApolloLake SoC allows two Logical Boot Partitions. This patch
introduces a '-s' optional parameter to select the second Logical
Boot Partition.
Change-Id: If32ec11fc7291d52b821bf95c1e186690d06ba11
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37660
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If the compiler fails to inline all the FORCE_INLINE functions, it will
complain.
Change-Id: I7b8349c9a3d53c47ac189f02b296600abac8a0cf
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37734
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cbfstool depends on vboot headers, and vboot expects to be able to use
modern C features like _Static_assert(). It just so happens that it
doesn't do that in any headers included from cbfstool right now, but
that may change. Let's switch cbfstool to a newer version to prevent
that from becoming a problem.
Change-Id: I884e1bdf4ec21487ddb1bca57ef5dc2104cf8e0e
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37666
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The MIPS architecture port has been added 5+ years ago in order to
support a Chrome OS project that ended up going nowhere. No other board
has used it since and nobody is still willing or has the expertise and
hardware to maintain it. We have decided that it has become too much of
a mainenance burden and the chance of anyone ever reviving it seems too
slim at this point. This patch eliminates all MIPS code and
MIPS-specific hacks.
Change-Id: I5e49451cd055bbab0a15dcae5f53e0172e6e2ebe
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34919
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
* Mark files in CBFS as IBB (Initial BootBlock)
* Will be used to identify the IBB by any TEE
Change-Id: Idb4857c894b9ee1edc464c0a1216cdda29937bbd
Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29744
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This variable is overwritten on one branch of the next if statement, and
the other branch returns, so this assignment does nothing.
Change-Id: I63737929d47c882bbcf637182bc8bf73c19daa9f
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: scan-build 8.0.0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34644
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Considering the following integer multiplication:
u64 = u16 * u16
What on earth, one might wonder, is the problem with this? Well, due to
C's unfortunately abstruse integer semantics, both u16's are implicitly
converted to int before the multiplication, which cannot hold
all possible values of a u16 * u16. Even worse, after overflow the
intermediate result will be a negative number, which during the
conversion to a u64 will be sign-extended to a huge integer. Not good.
The solution is to manually cast one of the u16 to a u32 or u64, which
are large enough to not have any overflow and will prevent the implicit
conversion. The type of the u64 is preferred, though a u32 is used
instead of size_t, since that can change depending on the platform.
Change-Id: I5391221d46d620d0e5bd629e2f9680be7a53342e
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 12297{03,04,05,06,07,08,09,10}
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33986
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add a utility to generate a compressed BIOS image for AMD Family 17h.
If the input is an elf file, the utility extracts the program portion
for compression. Otherwise the file is compressed as-is.
In modern AMD systems, the PSP brings up DRAM then uncompresses the
BIOS image into memory prior to x86 beginning execution. The PSP
supports a zlib engine, and interprets the first 256 bytes as a
header, where offset 0x14 containing the uncompressed size. For
further details, see AMD Platform Security Processor BIOS Architecture
Design Guide for AMD Family 17h Processors (NDA only, #55758).
BUG=b:127766506
TEST=Use with WIP Picasso
Change-Id: Id1c54e0a6dae9e4a0362c6635fe8b8aa48a369d8
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
The flag is useful for updaters to determine which areas to leave
alone, such as VPD (vital product data) regions that are set in
factory and might contain unique (MAC addresses) or hard to obtain
(calibration output) data.
It's also useful to see which regions are marked as such.
Change-Id: Ic0a229d474b32ac156cfabc917714ce9d339bac6
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33604
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Fix error "Invalid option -A" by adding "A" to options list.
Also, atoi does not parse hex string, for instance 0x200 is interpreted as 0,
and this causes a failure when updating second FIT table using -j option.
Use strtol instead of atoi
BUG=none
BRANCH=none
TEST=Build and boot hatch after enabling dual bootblock feature.
Change-Id: Ib227437f88ffcccda1ce2f20a9ab098e5aa091c7
Signed-off-by: Pandya, Varshit B <varshit.b.pandya@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33937
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
This is causing coreboot build in Chromium OS to fail.
BUG=None
TEST=emerge-eve coreboot
BRANCH=none
Change-Id: I4faa140b3046651b4ed0a9aeefe437048c6ef0da
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33780
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The ifittool is used instead. Drop old code.
Change-Id: I70fec5fef9ffd1ba3049badb398783f31aefb02f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Add the IntelFirmwareInterfaceTable-tool to modify the FIT.
As cbfstool is overloaded with arguments, introduce a new tool
to only modify FIT, which brings it's own command line syntax.
Provide clean interface to:
* Clear FIT
* Add entry to CBFS file
* Add entry to REGION
* Delete entries
* Add support for types other than 1
* Add support to dump current table
* Add support for top-swap
* Sort entries by type
Most code is reused from existing cbfstool and functionality of cbfstool
is kept. It will be removed once the make system uses only ifittool.
Based on "Intel Trusted Execution Technology (Intel TXT) LAB Handout"
and https://github.com/slimbootloader/slimbootloader .
Change-Id: I0fe8cd70611d58823aca1147d5b830722ed72bd5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31493
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Should include vb2_sha.h header when SHA library functions or
constants are required. This replaces NEED_VB2_SHA_LIBRARY.
BUG=b:124141368, chromium:956474
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I9f32174dbf3de05fbe5279cb8017888757abf368
Signed-off-by: Joel Kitching <kitching@google.com>
Cq-Depend: chromium:1583820
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32454
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The last attribute was never returned.
Fix size compare to retrieve all attributes.
Manually tested and seen all attributes, including the last one.
Change-Id: I08df073158a0f285f96048c92aa8066fa4f57e6f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The Flashmap (FMAP) was not clearly documented. The new flashmap.md
explains where to find more details about that and how / why it was used
in coreboot. Also explained what is FMD and how to use it (based on
original README.fmaptool).
BUG=None
TEST=None (only documentation)
Change-Id: Ia389e56c632096d7c905ed221fd4f140dec382e6
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31766
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
When updating firmware, it is very often that we may want to preserve
few sections, for example vital product data (VPD) including serial
number, calibration data and cache. A firmware updater has to hard-code
the section names that need to be preserved and is hard to maintain.
A better approach is to specify that in FMAP area flags (the `area_flag`
field) using FMAP_AREA_PRESERVE. With this patchset, a FMD parser flag
"PRESERVE" is introduced and will be converted to FMAP_AREA_PRESERVE
when generating FMAP data (by fmap_from_fmd.c).
For example, The FMD statement:
RO_VPD(PRESERVE)@0x0 16k
will generate an FMAP firmware section that:
area_name = "RO_VPD"
area_offset = 0
area_size = 16384
area_flags = FMAP_AREA_PRESERVE
BUG=chromium:936768
TEST=make; boots on x86 "google/eve" and arm "google/kukui" devices
Manually added 'PRESERVE' to some FMD files, and verify (by running
fmap.py) the output coreboot.rom has FMAP_AREA_PRESERVE set
Change-Id: I51e7d31029b98868a1cab0d26bf04a14db01b1c0
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31707
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The recent toolchain update also updated binutils, which has a new
relocation type, introduced with commit bd7ab16b
(x86-64: Generate branch with PLT32 relocation).
Add support for R_X86_64_PLT32, which is handled as R_X86_64_PC32.
Add comment explaining the situation.
Fixes build error on x86_64.
Change-Id: I81350d2728c20ac72cc865e7ba92319858352632
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31468
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The idea of "annotation" for firmware sections was pretty flexible, but
in future we will want multiple attributes applied to same area. For
example, indicate the section must be preserved when updating firmware
so serial number or MAC address can be preserved.
The solution here is to extend annotation so it can take multiple
identifiers (flags) in a row. For example, to declare a 64KB COREBOOT
section as CBFS using annotation:
COREBOOT(CBFS)@0x0 64k
If there's a new flag "PRESERVE" indicating the section must be
preserved before update, we can declare it following CBFS flag:
COREBOOT(CBFS PRESERVE)@0x0 64k
The flags are directly parsed in fmd_parser, and stored in an union
flashmap_flags. Output modules can choose to ignore or process the
flags.
Currently the only supported flag is "CBFS" (for backward compatible
with annotation). There will be more new flags in follow up patches.
BUG=chromium:936768
TEST=make; boots on x86 "google/eve" and arm "google/kukui" devices
Change-Id: Ie2d99f570e6faff6ed3a4344d6af7526a4515fae
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31706
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When updating firmware, we may need to preserve some sections like VPD,
calibration data, ... etc. The logic can be hard-coded in updater as a
list of known names, but a better solution is to have that directly
declared inside FMAP area flags.
To do that, the first step is to apply the changes in flash map
(http://crosreview.com/1493767). A new FMAP_AREA_PRESERVE is now
defined and will be set in future with new syntax in FMD parser.
BUG=chromium:936768
TEST=make; boots an x86 image.
Change-Id: Idba5c8d4a4c5d272f22be85d2054c6c0ce020b1b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/31676
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Relocations for PC relative instructions must not emitted.
As PC64 are unlikely with current code, it never was an issue.
Change-Id: Ife472a287ff15b1c04a516e25ff13221441fd122
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/31469
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Put the FMAP FMAP region right above the coreboot CBFS region.
The other regions like RW_MRC_CACHE and CONSOLE often have alignment
requirements so it makes sense to put those on top. This also
simplifies the code the generate the default fmap a little.
Change-Id: I24fa6c89ecf85fb9002c0357f14aa970ee51b1df
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/30419
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support for relocations on x86_64.
Required for 64bit romstage.
Change-Id: I1ff223d3476776297b501813a953356dd6fa9d67
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/30115
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Add support for 64bit rmodule, as required for relocatable
ramstage on x86_64.
Change-Id: I7fbb3b4c0f76ce82c090b5f16f67a728b6bf94a5
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/29874
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is already a function with the name buffer_size(). Adding a local
variable with the same name will lead to the following error on older
GCC versions (e.g. version 4.4.7):
declaration of 'buffer_size' shadows a global declaration
To fix this rename the local variable to buffer_len.
Change-Id: Ifae3a17152f2f9852d29a4ac038f7e5a75a41614
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/29776
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Arthur Heymans