Move the definition of _(Str) macro to lib/eu-config.h which already
provides a definition of N_(Str) macro. Since lib/eu-config.h is
appended to config.h, it is included into every compilation unit
and therefore both macros are now universally available.
Remove all other definitions of N_(Str) and _(Str) macros from other files
to avoid conflicts and redundancies.
The next step is to replace all uses of gettext(Str) with _(Str).
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
When elf_memory is called we could get a slightly too small image
that doesn't contain a full ELF header (but does contain at least
the e_ident values). Require the full header before even validating
the rest of the ELF header fields.
https://sourceware.org/bugzilla/show_bug.cgi?id=27076
Signed-off-by: Mark Wielaard <mark@klomp.org>
Apparently, commit 2f02e81510 that removed
$(EXEEXT) suffix from shared libraries was incomplete: it missed the
fact that some libraries were included into noinst_PROGRAMS, resulting
to the following automake warnings:
libasm/Makefile.am:66: warning: deprecated feature: target 'libasm.so' overrides 'libasm.so$(EXEEXT)'
libdw/Makefile.am:114: warning: deprecated feature: target 'libdw.so' overrides 'libdw.so$(EXEEXT)'
libelf/Makefile.am:116: warning: deprecated feature: target 'libelf.so' overrides 'libelf.so$(EXEEXT)'
Fix this by renaming noinst_PROGRAMS to noinst_DATA and removing no
longer needed lib{asm,dw,elf}_so_SOURCES variables and add lib{asm,dw,elf).so
to CLEANFILES.
Fixes: 2f02e81510 ("Drop $(EXEEXT) suffix from shared libraries")
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Mark Wielaard <mark@klomp.org>
The elf-knowledge.h contains various macros to deal with specific ELF
knowledge needed to interpret some ELF constructs that can be ambigious
depending on architecture ABI. Update the comment of SH_ENTSIZE_HASH
to add a more technical description of why it is needed.
Signed-off-by: Mark Wielaard <mark@klomp.org>
We already checked the header actually existed for ELFCLASS64 but not
for the ELFCLASS32 case. It is very unlikely it is at this point in the
code, but theoretically it could happen.
Signed-off-by: Mark Wielaard <mark@klomp.org>
GCC with -flto finds some (very) unlikely error paths. It flags callers
of __elf_getphdrnum_chk_rdlock with *dst not yet set because an internal
call to __elf_getphdrnum_rdlock might not initialize *dst either in one
particular failure path. The sanity check that __elf_getphdrnum_chk_rdlock
then performs might happen against uninitialized data. So just set *dst
to zero on failure in __elf_getphdrnum_rdlock so any caller can simply
check either the result/error code or whether *dst is zero or not.
Signed-off-by: Mark Wielaard <mark@klomp.org>
GCC with -flto detects some (very) unlikely issues in error paths.
In theory getting the Ehdr from an Elf handle might fail. But in
most cases where __libelf_data_type is used, we already have the
Ehdr anyway. So simply pass that to __libelf_data_type. In the one
place where we don't have it yet, get it and check for failure
before calling __libelf_data_type.
Signed-off-by: Mark Wielaard <mark@klomp.org>
In elf_getdata.c we have the following to compensate for possibly
bad sh_addralign values of compressed sections:
/* Compressed data has a header, but then compressed data.
Make sure to set the alignment of the header explicitly,
don't trust the file alignment for the section, it is
often wrong. */
if ((flags & SHF_COMPRESSED) != 0)
{
entsize = 1;
align = __libelf_type_align (elf->class, ELF_T_CHDR);
}
Which makes sure the d_data alignment is correct for the Chdr struct
at the start of the compressed section.
But this means that if a user just reads such a compressed section
without changing it, and then tries to write it out again using
elf_update they get an error message about d_align and sh_addralign
being out of sync.
We already correct obviously incorrect sh_entsize fields.
Do the same for the sh_addralign field of a SHF_COMPRESSED section.
Signed-off-by: Mark Wielaard <mark@klomp.org>
GCC10 -fanalyzer with -flto notices __elf64_getshdr_rdlock can fail
and because the result isn't checked in elf_strptr it can cause a
dereference of NULL.
Signed-off-by: Mark Wielaard <mark@klomp.org>
GCC10 -fanalyzer with -flto notices __gelf_getehdr_rdlock can fail
and that the result of the call in __libelf_set_rawdata_wrlock isn't
checked, which can cause a dereference of NULL.
Signed-off-by: Mark Wielaard <mark@klomp.org>
In commit 2092865a7e
"libelf: {de,}compress: ensure zlib resource cleanup" we added a
call to deflate_cleanup to make sure all resources were freed.
As GCC10 -fanalyzer points out that could cause a double free
of out_buf. Fix by removing the free (out_buf) in __libelf_compress.
Signed-off-by: Mark Wielaard <mark@klomp.org>
__elf_getphdrnum_rdlock() handles PN_XNUM by getting sh_info from
elf->state.elf{32,64}.scns.data[0].shdr.e{32,64}. However, that is only
a cache that may or may not have been populated by elf_begin() or
elf{32,64}_getshdr(); if it hasn't been cached yet, elf_getphdrnum()
returns 65535 (the value of PN_XNUM) instead. We should explicitly get
the shdr if it isn't cached.
Signed-off-by: Omar Sandoval <osandov@fb.com>
__libelf_decompress would only cleanup zlib resources via inflateEnd()
in case inflating was successful, but would leak memory if not. Fix this
by calling inflateEnd() unconditionally.
__libelf_decompress did this all the time already, but called
deflateEnd() twice. That is not a (known) issue, but can be cleaned up
by ensuring all error paths use 'return deflate_cleanup' and the success
path calls deflateEnd() only once. Note, the deflate() needs to return
Z_STREAM_END to indicate we are done. Hence change the condition.
Fixes: 272018bba1 ("libelf: Add elf_compress and elf_compress_gnu.")
Signed-off-by: Matthias Maennich <maennich@google.com>
Some years ago, in commit b1d0b0fc "libelf: Use int64_t for offsets in
libelf.h", we changed the public interface to use 64bit offsets/sizes.
This wasn't really a API change, before we relied on loff_t always
being 64bits on all platforms.
We didn't change the implementation to use the int64_t type though.
That was a little confusing, since the function definitions used a
different type, int64_t, from the function implementations, off_t.
Since we always build with _FILE_OFFSET_BITS=64 this should be fine.
But it was a bit sloppy and confusing.
Worse is that we got the translation of offset/sizes wrong in a
couple of places when translating to ELF types. In various places
we would use Elf32_Word or Elf64_Word. But both are 32bit (unsigned)
types! As is GElf_Word. Elf32_Off is 32bits and Elf64_Off is 64bits.
But we were not using those consistently.
This patch introduces comments for the usage of [G]Elf(32|64)Word in
libelf that are correct. And introduces Elf(32|64)_SizeWord in
elf32_updatenull.c where we want to make a difference between sizes
and offsets (the ELF variants are both unsigned, while int64_t/loff_t
is signed).
It also includes a new run-large-elf-file.sh test that creates a
large ELF files (one 64bit, little endian, rel and another big endian,
non-rel) and runs eu-strip, eu-elflint, eu-unstrip and eu-elfcmp.
Before this patch, that test case fails and creates corrupt ELF files.
The test is guarded by some checks that try to make sure there is
enough disk space and memory available on the machine. The test is
skipped otherwise.
Signed-off-by: Mark Wielaard <mark@klomp.org>
We forgot to mark the shdr_flags dirty when only the sh_size or
sh_offset changed during elf_update (). This meant that if there were
no other shdr changes we only wrote out the section data, but didn't
write out the shdr table to the file.
Add a testcase that puts some sections in the reverse order and then
writes out the resulting file again without doing any other
updates. This would show the issue after write out of the
(re-reversed) ELF file (the .shstrtab section offset would be wrong
causing all section names to be garbage). Also run a self test.
Signed-off-by: Mark Wielaard <mark@klomp.org>
During fuzzing of the new xlate_notes testcase I noticed that
gelf_get_note didn't check whether the n_namesz of a note was
too big. This could lead to offset wrapping around. Causing an
infinite loop going over all ELF notes. Fix by adding an overflow
check before updating offset.
Signed-off-by: Mark Wielaard <mark@klomp.org>
When we started parsing new style ELF_T_NHDR8 notes we added extra
checks on alignment and padding. When those failed we would stop
converting and just return the rest of the ELF Note unconverted.
In the case were we just had enough data for just the ELF Note header
and the destionation and source weren't the same we would then
accidentially throw away the Note header conversion we just did.
Fix that by indicating we did correctly convert just the header.
Adds testcase that compares parsing ELF notes with gelf_getnote
and parsing the raw data by hand using elf32_xlatetom using just
the Note header and ignoring the (raw) note data.
Signed-off-by: Mark Wielaard <mark@klomp.org>
Older glibc might not have aligned_alloc (it is C11).
Use posix_memalign instead. posix_memalign requires the alignment to
be a multiple of sizeof (void *). So use malloc for smaller alignments.
Signed-off-by: Mark Wielaard <mark@klomp.org>
When we cannot allocate enough memory to convert the data in
updatemmap we should free the scns before returning an error.
Signed-off-by: Mark Wielaard <mark@klomp.org>
__elf_xfctstof is only used in case the memory size and file size of ELF
data structures are different. This is never the case.
Signed-off-by: Mark Wielaard <mark@klomp.org>
Those functions were intended for ELF versions where the memory and
file sizes of data structures are different. They were never used
because libelf depends on the file and memory sizes being equal
(otherwise using mmap wouldn't work).
Signed-off-by: Mark Wielaard <mark@klomp.org>
Remove (partially defined out) code and data structures dealing with
multiple ELF versions. There hasn't been a new ELF version in the
last 20 years. Simplify the code a bit by just assuming there will
only be one version (EV_CURRENT == 1).
Simplifies elf_version, gets rid of __libelf_version_initialized.
Removes one (or more) array (version) dimension from various tables
and accessor functions (__elf_xfctstom, shtype_map, __libelf_data_type,
__libelf_type_aligns and __libelf_type_sizes).
Signed-off-by: Mark Wielaard <mark@klomp.org>`
This is a corner case that will most likely never occur in practice,
but we have several testcases that compress and decompress zero sized
data. In that case during decompression we might malloc a buffer of
size zero. It is allowed for malloc to return NULL in that case. But
we do need a non-NULL buffer to return and set as result. So make sure
to always at least allocate one byte. Also make sure that we don't
allocate a zero sized conversion buffer for the data.
https://sourceware.org/bugzilla/show_bug.cgi?id=24000
Signed-off-by: Mark Wielaard <mark@klomp.org>
The ar_size is given as a fixed size decimal string, right padded with
spaces. Make sure we read it properly even if there is no terminating
space. Also sanity check len early if we can.
https://sourceware.org/bugzilla/show_bug.cgi?id=24085
Signed-off-by: Mark Wielaard <mark@klomp.org>
We explicitly test (with system-elf-libelf) that our include headers
work with the system elf.h header. But it might be helpful to install
the elf.h file for a private install. Our elf.h header really is just
a copy of the latest glibc elf.h. But it might be newer and include
more constants than the system installed elf.h.
Add a new configure option --enable-install-elfh to install elf.h.
But warn when it is enabled for the default /usr or /usr/local prefix
because it might clash with the glibc/system elf.h header in that case.
Signed-off-by: Mark Wielaard <mark@klomp.org>
We want to make sure the note_len doesn't overflow and becomes shorter
than the note header. But the namesz and descsz checks got the note header
size wrong). Replace the wrong constant (8) with a sizeof cvt_Nhdr (12).
https://sourceware.org/bugzilla/show_bug.cgi?id=24084
Signed-off-by: Mark Wielaard <mark@klomp.org>
When writing out data that needs to be converted we have to make sure
the conversion function is called on correctly aligned buffers. When
using mmap this might mean we have to convert into a temporarily buffer
if the user wants to write out the section at a location that is not
correctly aligned for the section type.
Older gas would generate misaligned ELF notes for the .version
directive. When copying over such notes using mmap from files with
a different endianness using mmap we would get the alignment of the
conversion destination wrong.
The new testcase would fail with configure --enable-sanitize-undefined
on little endian systems. The GCC undefinited sanitizer caught a similar
issue with testfile1 on big endian systems.
gelf_xlate.h:47:1: runtime error: member access within misaligned address
0x7f8145d770d5 for type 'struct Elf32_Nhdr', which requires 4 byte alignment
Signed-off-by: Mark Wielaard <mark@klomp.org>
GCC9 -Wmissing-attributes pointed out that although we alias the fsize
and msize functions only fsize was marked as const. Fix by also marking
the msize definition as const.
https://sourceware.org/bugzilla/show_bug.cgi?id=23884
Signed-off-by: Mark Wielaard <mark@klomp.org>
We didn't set the alignment of SHF_COMPRESSED sections correctly.
Those sections start with an Elf(32|64)_Chdr. Make sure sh_addralign
is setup to be able to read such a struct directly. Likewise don't
trust the alignment set on any SHF_COMPRESSED section, but always
make the (raw) compressed data aligned correctly for the reading the
Elf(32|64)_Chdr directly.
Signed-off-by: Mark Wielaard <mark@klomp.org>
Check whether a section was gnu compressed and decompress it first
before trying to resolve relocations. Recompress it afterwards.
This found a bug in elf_compress_gnu which would use the "raw" file
contents even if the user had just created the section (copying over
the section from the original input file).
Add compressed ET_REL tests to run-strip-reloc.sh testcase.
Signed-off-by: Mark Wielaard <mark@klomp.org>
GNU Build Attribute ELF Notes are generated by the GCC annobin plugin
and described at https://fedoraproject.org/wiki/Toolchain/Watermark
Unfortunately the constants aren't yet described in the standard glibc
elf.h so they have been added to the elfutils specific elf-knowledge.h.
The notes abuse the name owner field to encode some data not in the
description. This makes it a bit hard to parse. We have to match the
note owner name prefix (to "GA") to be sure the type is valid. We also
cannot rely on the owner name being a valid C string since the attribute
name and value can contain zero (terminators). So pass around namesz
to the ebl note parsing functions.
eu-elflint will recognize and eu-readelf -n will now show the notes:
Note section [27] '.gnu.build.attributes' of 56080 bytes at offset 0x114564:
Owner Data size Type
GA 16 GNU Build Attribute OPEN
Address Range: 0x2f30f - 0x2f30f
VERSION: "3p8"
GA 0 GNU Build Attribute OPEN
TOOL: "gcc 8.2.1 20180801"
GA 0 GNU Build Attribute OPEN
"GOW": 45
GA 0 GNU Build Attribute OPEN
STACK_PROT: 0
GA 0 GNU Build Attribute OPEN
"stack_clash": TRUE
GA 0 GNU Build Attribute OPEN
"cf_protection": 0
GA 0 GNU Build Attribute OPEN
"GLIBCXX_ASSERTIONS": TRUE
GA 0 GNU Build Attribute OPEN
"FORTIFY": 0
GA 0 GNU Build Attribute OPEN
PIC: 3
GA 0 GNU Build Attribute OPEN
SHORT_ENUM: FALSE
GA 0 GNU Build Attribute OPEN
ABI: c001100000012
GA 0 GNU Build Attribute OPEN
"stack_realign": FALSE
A new test was added to run-readelf -n for the existing annobin file.
Signed-off-by: Mark Wielaard <mark@klomp.org>
We need to explictly trigger a section data reload after updating the
ELF section rawdata to make sure it gets written out to disk on an
elf_update. Doing this showed one bug/inefficiently when the underlying
file has a different endianness. In that case for debug sections we
would convert by allocating a new buffer and just copying over the
raw data into a new buffer. This is not really necessary and would
hide any relocations done on the rawdata by libdwfl.
Added a couple of new ppc64 big endian testfiles that show the issue.
Signed-off-by: Mark Wielaard <mark@klomp.org>
GNU Property notes are different from normal notes because they use
variable alignment/padding of their fields. They are 8 byte aligned,
but use 4 byte fields. The name is aligned at 4 bytes and padded so
that, the desc is aligned at 8 bytes. The whole note is padded to
8 bytes again. For normal notes all fields are both 4 bytes wide and
4 bytes aligned.
To recognize these new kind of ELF Notes a new Elf_Type is introduced,
ELF_T_NHDR8. This type is used in the xlate functions to determine
how to align and pad the various fields. Since the fields themselves
can now have different alignments we will have to keep track of the
current alignement and use either NOTE_ALIGN4 or NOTE_ALIGN8 to
determine the padding.
To set the correct Elf_Type on the Elf_Data we use either the section
sh_addralign or the segment p_align values. Assuming 8 means the
section or segment contains the new style notes, otherwise normal
notes.
When we cannot determine the "alignment" directly, like when parsing
special kernel sys files, we check the name "GNU" and type
"GNU_PROPERTY_TYPE_0" fields.
ebl_object_note now parses the new NT_GNU_PROPERTY_TYPE_0 and can
extract the GNU_PROPERTY_STACK_SIZE, GNU_PROPERTY_NO_COPY_ON_PROTECTED
and GNU_PROPERTY_X86_FEATURE_1_AND types GNU_PROPERTY_X86_FEATURE_1_IBT
and GNU_PROPERTY_X86_FEATURE_1_SHSTK.
Tests are added for extracting the note from sections or segments
as set by gcc -fcf-protection.
Signed-off-by: Mark Wielaard <mark@klomp.org>
For ELF files with more than SHN_LOWRESERVE sections we always need
section zero to store the section number (it doesn't just fit in the
Ehdr e_shnum field). Make sure to create it if it doesn't exist yet
in elf_getscn. Also fix handling on shnum in updatefile for the mmap
case (we already got this correct for the non-mmap case).
This adds a new test run-copymany-sections.sh which is like
run-copyadd-sections.sh but tries to add two times 65535 sections.
It makes sure libelf can copy the whole file and elfcmp checks they
are the same. It doesn't use mmap for addsections since that doesn't
work yet. ELF_C_RDWR_MMAP needs mremap which will fail since it needs
too much space and the original mmap cannot move.
Signed-off-by: Mark Wielaard <mark@klomp.org>
When ELF_C_RDWR_MMAP is used libelf might have to write overlapping memory
when moving the section data or headers. Make sure to use memmove, not
memcpy. Also the size of the underlying file might have to change. That
means we will have to also extend the mmap region with mremap. Since we
are using direct pointers into the mmapped area we cannot move the mmap,
only extend it. This might still fail if there is not enough free memory
available to extend the mmap region.
Two new test programs have been added. elfcopy which copies a whole elf
file (using either ELF_C_WRITE or ELF_C_WRITE_MMAP). And addsections which
adds new sections to an existing ELF file (using either ELF_C_RDWR or
ELF_C_RDWR_MMAP). The newly added test will fail under valgrind without
the fixes.
Signed-off-by: Mark Wielaard <mark@klomp.org>
Compressing a section that is already compressed is fine, but useless.
But it isn't possible to gnu compress (or decompress) a SHF_COMPRESSED
section since there is no state kept that would tell if the section was
first GNU compressed or first gabi compressed. Calling elf_compress_gnu
on a section and then calling elf_compress on it to decompress it twice
could cause a crash (the other way around is fine). Just disallow it.
https://sourceware.org/bugzilla/show_bug.cgi?id=23528
Signed-off-by: Mark Wielaard <mark@klomp.org>
Because of copy/paste error part of the documentation for
elf_getshdrstrndx and elf_getshstrndx was actually for
elf_getshdrnum and elf_getshnum. Fix it to refer to the proper
ehdr field and deprecated function name.
Signed-off-by: Mark Wielaard <mark@klomp.org>
lizhenlin