For x86 eXecute-In-Place (XIP) pre-memory `.data` section support, we
have to use an extra segment as the VMA/LMA of the data is different
than the VMA/LMA of the code.
To support this requirement, this patch makes cbfstool:
1. Allow the load of an ELF with an extra segment
2. Makes add-stage for XIP (cf. parse_elf_to_xip_stage()) write its
content to the output binary.
To prevent the creation of unsuitable binaries, cbfstool verifies that
the LMA addresses of the segments are consecutives.
TEST=XIP pre-memory stages with a `.data` section have the `.data`
section covered by a second segment properly included right after
the code.
Change-Id: I480b4b047546c8aa4e12dfb688e0299f80283234
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77584
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When using `DECLARE_OPTIONAL_REGION`, it is assumed that
REGION_SIZE(name) == 0 if the region was not defined in the memlayout.
When using non-rmodule stages (i.e., bootblock, romstage, etc), this
assumption holds true, but breaks down in rmodule (i.e., ramstage)
stages.
The rmodule tool is not currently omitting undefined externals from the
relocation table. e.g.,
extern u8 _##name##_size[];
This means that when the rmodule loader runs, it will rewrite the symbol
from 0 (which is the default the linker assumed) to 0 + offset. This is
wrong since the symbol doesn't actually exist. Instead we need to omit
the relocation so it continues to keep the default value of 0.
BUG=b:179699789
TEST=Print out REGION_SIZE(cbfs_cache) in ramstage and verify it is set
to 0.
I also see the following printed by the rmodtool now:
DEBUG: Omitting relocation for undefined extern: _watchdog_tombstone_size
DEBUG: Omitting relocation for undefined extern: _watchdog_tombstone
DEBUG: Omitting relocation for undefined extern: _watchdog_tombstone
DEBUG: Omitting relocation for absolute symbol: _stack_size
DEBUG: Omitting relocation for absolute symbol: _program_size
DEBUG: Omitting relocation for absolute symbol: _cbmem_init_hooks_size
DEBUG: Omitting relocation for absolute symbol: _payload_preload_cache_size
DEBUG: Omitting relocation for absolute symbol: _payload_preload_cache
DEBUG: Omitting relocation for absolute symbol: _payload_preload_cache_size
DEBUG: Omitting relocation for absolute symbol: _payload_preload_cache
DEBUG: Omitting relocation for undefined extern: _cbfs_cache
DEBUG: Omitting relocation for undefined extern: _cbfs_cache_size
As you can see the _watchdog_tombstone will also be fixed by this CL.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ib57e263fa9014da4f6854637000c1c8ad8eb351a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58376
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
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 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>
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>
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>
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>
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>
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>
Header contains ':' in copyright line. rmdoule is a typo
Remove the ';' and correct typo to rmodule.
BUG=N/A
TEST=N/A
Change-Id: I05b1fb80a81682646c9fba3d234de235b6bc9e8c
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/29794
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
This avoids re-declaring common macros like ARRAY_SIZE, MIN, MAX and
ALIGN. Also removes the issues around including both files in any
tool.
Also, fix comparison error in various files by replacing int with
size_t.
Change-Id: I06c763e5dd1bec97e8335499468bbdb016eb28e5
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14978
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
With the previous ELF stage extract support the resulting
ELF files wouldn't handle rmodules correctly in that the
rmodule header as well as the relocations were a part of
the program proper. Instead, try an initial pass at
converting the stage as if it was an rmodule first. If it
doesn't work fall back on the normal ELF extraction.
TEST=Pulled an rmodule out of Chrome OS shellball. Manually
matched up the metadata and relocations.
Change-Id: Iaf222f92d145116ca4dfaa955fb7278e583161f2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12222
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Instead of reaching into src/include and re-writing code
allow for cleaner code sharing within coreboot and its
utilities. The additional thing needed at this point is
for the utilities to provide a printk() declaration within
a <console/console.h> file. That way code which uses printk()
can than be mapped properly to verbosity of utility parameters.
Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11592
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
In order to allow cbfstool to add XIP romstage on x86 without
doing the 'cbfstool locate', relink, then 'cbfstool add' dance
expose the core logic and of rmodule including proving an optional
filter. The filter will be used for ignoring relocations to the
.car.global region.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi.
Change-Id: I192ae2e2f2e727d3183d32fd3eef8b64aacd92f4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11598
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The core logic of the rmodule parser is ideal for
processing romstage ELF files for XIP. To that
end start the work of exposing the logic from
rmodule so cbfstool can take advantage of it.
The properties that both need require:
- Single program segment
- Relocation information
- Filter relocation processing
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi.
Change-Id: I176d0ae0ae1933cdf6adac67d393ba676198861a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11595
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There are currently 2 uses for rmodule programs: stand alone
programs that are separate from the coreboot stages and a
relocatable ramstage. For the ramstage usage there's no reason
to require a rmodule parameter section. Therefore make this
optional.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built ramstage w/ normal linking (w/o a rmodule parameter
section). No error.
Change-Id: I5f8a415e86510be9409a28068e3d3a4d0ba8733e
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11523
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Bring rmodule linking into the common linking method.
The __rmodule_entry symbol was removed while using
a more common _start symbol. The rmodtool will honor
the entry point found within the ELF header. Add
ENV_RMODULE so that one can distinguish the environment
when generating linker scripts for rmodules. Lastly,
directly use program.ld for the rmodule.ld linker script.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage,
sipi_vector, and smm rmodules.
Change-Id: Iaa499eb229d8171272add9ee6d27cff75e7534ac
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11517
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
rmodule.c: In function ‘rmodule_create’:
rmodule.c:287:29: error: ‘phdr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
(phdr->p_vaddr + phdr->p_memsz))) {
^
rmodule.c:204:14: note: ‘phdr’ was declared here
Elf64_Phdr *phdr;
^
Change-Id: I94a235253610348484eef218ec855103a3bb5da5
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Reviewed-on: http://review.coreboot.org/10881
Tested-by: build bot (Jenkins)
Reviewed-by: Francis Rowe <info@gluglug.org.uk>
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
This enables more warnings on the cbfstool codebase and fixes the
issues that surface as a result. A memory leak that used to occur
when compressing files with lzma is also found and fixed.
Finally, there are several fixes for the Makefile:
- Its autodependencies used to be broken because the target for
the .dependencies file was misnamed; this meant that Make
didn't know how to rebuild the file, and so would silently
skip the step of updating it before including it.
- The ability to build to a custom output directory by defining
the obj variable had bitrotted.
- The default value of the obj variable was causing implicit
rules not to apply when specifying a file as a target without
providing a custom value for obj.
- Add a distclean target for removing the .dependencies file.
BUG=chromium:461875
TEST=Build an image with cbfstool both before and after.
BRANCH=None
Change-Id: I951919d63443f2b053c2e67c1ac9872abc0a43ca
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 49293443b4e565ca48d284e9a66f80c9c213975d
Original-Change-Id: Ia7350c2c3306905984cfa711d5fc4631f0b43d5b
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/257340
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/9937
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built secmon which had this type of relocation.
Change-Id: Ie367c348fbf59465e238e5fa60f217f5373501b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a754bc1fe39c19ab8b2f7be9648cccb06156b0ef
Original-Change-Id: If170d9e270daf3153e92d16c06516915c727e930
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218843
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8807
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add support for creating ARM rmodules. There are 3 expected
relocations for an ARM rmodule:
- R_ARM_ABS32
- R_ARM_THM_PC22
- R_ARM_THM_JUMP24
R_ARM_ABS32 is the only type that needs to emitted for relocation
as the other 2 are relative relocations.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built vbootstub for ARM device.
Original-Change-Id: I0c22d4abca970e82ccd60b33fed700b96e3e52fb
Original-Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/190922
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit a642102ba7ace5c1829abe7732199eda6646950a)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ib3b3c90ebb672d8d6a537df896b97dc82c6186cc
Reviewed-on: http://review.coreboot.org/7204
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Currently, rmodules with 0 relocations are not allowed. Fix this by skipping
addition of .rmodules section on 0 relocs.
Change-Id: I7a39cf409a5f2bc808967d2b5334a15891c4748e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/6774
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Apparently when I originally wrote this I confused myself to no end.
The code/data of an rmodule has a set memory size which is associated
with the .payload section. The relocation entries may increase the
overall footprint of the memory size if the rmodule has no bss but
a lot of relocations. Therefore, just compare relocation entries size
plus the file size of the .payload section with the memory size of the
paylod section. The .empty section is added only when we have not met
the final target size.
Change-Id: I5521dff048ae64a9b6e3c8f84a390eba37c7d0f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/6767
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The current implementation of creating rmodules relies
on invoking the linker in a certain manner with the
relocations overlaid on the BSS section. It's not really
surprising that the linker doesn't always behave the way
one wants depending on the linker used and the architecture.
Instead, introduce rmodtool which takes an ELF file as an
input, parses it, and creates a new ELF file in the format
the rmodule loader expects.
Change-Id: I31ac2d327d450ef841c3a7d9740b787278382bef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5378
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Jeremy Compostella