For each input readelf output, localplt.awk parses each 'Relocation
section' entry, checks its offset against the dynamic section entry, and
saves each DT_JMPREL, DT_RELA, and DT_REL offset value it finds. After
all lines are read, the script checks if any segment offset differed
from 0, meaning at least one 'Relocation section' was matched.
However, if the shared object was built with RELR support and the static
linker could place all the relocation on DT_RELR, there would be no
DT_JMPREL, DT_RELA, and DT_REL entries; only a DT_RELR.
For the current three ABIs that support (aarch64, x86, and powerpc64),
the powerpc64 ld.so shows the behavior above. Both x86_64 and aarch64
show extra relocations on '.rela.dyn', which makes the script check to
succeed.
This patch fixes by handling DT_RELR, where the offset is checked
against the dynamic section entries and if the shared object contains an
entry it means that there are no extra PLT entries (since all
relocations are relative).
It fixes the elf/check-localplt failure on powerpc.
Checked with a build/check for aarch64-linux-gnu, x86_64-linux-gnu,
i686-linux-gnu, arm-linux-gnueabihf, s390x-linux-gnu, powerpc-linux-gnu,
powerpc64-linux-gnu, and powerpc64le-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Sort tunables list at the time it's generated. Note: adding new
tunables will cause other tunable IDs to change, but that was
the case before anyway. POSIX does not guarantee the order of "foo
in bar" AWK operators, so the order was indeterminate before anyway.
Even depending on the order to be the same across multiple calls,
such as in this script, is undefined, so sorting the list resolves
that also.
Note that sorting is not dependent on the user's locale.
Tunable with environment variables aliases are also ignored if
glibc.rtld.enable_secure is enabled. The tunable parsing is also
optimized a bit, where the loop that checks each environment variable
only checks for the tunables with aliases instead of all tables.
Checked on aarch64-linux-gnu and x86_64-linux-gnu.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
This adds the OpenRISC hard float glibc variant to the build many
script. We update the compiler for glibc to support hard-float
multilibs to allow us to use a single generic compiler for all glibc
variants, this requires updating the compiler name.
Tested and all builds are passing.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Until GCC removes Nios II support (at which point we should do so as
well), this is now needed for GCC 14 / mainline to build for
nios2-linux-gnu target.
Tested with build-many-glibcs.py (GCC mainline) for nios2-linux-gnu.
This patch adds some --disable-multi-arch variants for s390x.
As the used IFUNC variants and __GI symbols depend on the used
gcc -march=cpu-level, there are multiple new configurations.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
'_' is used in Makefile variable names and many variables end with
"^# name". Relax sort-makefile-lines.py to allow '_' in name and
"^# name" as variable end. This fixes BZ #31385.
Change "\(" and "\)" to "\\(" and "\\)" in test_printers_common.py. This
fixes the test warning:
.../scripts/test_printers_common.py:101: SyntaxWarning: invalid escape sequence '\('
Reviewed-by: Florian Weimer <fweimer@redhat.com>
A version string may contain non-digit characters, commonly found in
built-from-VCS tools, e.g.
```
git version 2.39.GIT
git version 2.43.0.493.gbc7ee2e5e1
```
`int()` will raise a ValueError, leading to a spurious 'missing'.
Reviewed-by: DJ Delorie <dj@redhat.com>
Simplify the advisory format by dropping the -Backport tags and instead
stick to using just the -Commit tags. To identify backports, put a
substring of git-describe into the release version in the brackets next
to the commit ref. This way, it not only identifies that the fix (or
regression) is on the release/2.YY/master branch, it also disambiguates
regressions/fixes in the branch from those in the tarball.
Add a README to make it easier for consumers to understand the format.
Additionally, the Release wiki needs to be updated to inform the release
manager to:
1. Generate a NEWS snipped from the advisories directory
AND
2. on release/2.YY/master, replace the advisories directory with a text
file pointing to the advisories directory in master so that we don't
have to update multiple locations.
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Andreas K. Hüttel <dilfridge@gentoo.org>
It turns out that the replacement of datetime.datetime.utcnow(), for a
warning produced early in running build-many-glibcs.py with Python
3.12, (a) wasn't complete (there were other uses elsewhere in the
script also needing updating) and (b) broke reading of build-time from
build-state.json, because an aware datetime was written out including
+00:00 for the timezone, which was not expected by the strptime call.
Fix the first by making the change to
datetime.datetime.now(datetime.timezone.utc) for all the remaining
utcnow() calls. Fix the second by using strftime with an explicit
format instead of just str() when formatting build times for
build-state.json and and email subjects, and then setting the timezone
explicitly when reading from build-state.json. (Other uses, in
particular messages output by the bot, continue to use str() as the
precise format should not matter in those cases; it shouldn't actually
matter for email subjects either but it seems a good idea to keep
those short.)
Tested with a bot-cycle run and checking the format of times in
build-state.json afterwards.
Running build-many-glibcs.py with Python 3.12 or later produces a
warning:
build-many-glibcs.py:566: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
build_time = datetime.datetime.utcnow()
Replace with datetime.datetime.now(datetime.timezone.utc) (the
datetime.UTC constant is new in 3.11, so not suitable for use in this
script at present).
Running build-many-glibcs.py with Python 3.12 or later produces a
warning:
build-many-glibcs.py:173: SyntaxWarning: invalid escape sequence '\.'
m = re.fullmatch('([0-9]+)\.([0-9]+)[.0-9]*', l)
Use a raw string instead to avoid that warning. (Note: I haven't
checked whether any other Python scripts included with glibc might
have issues with newer Python versions.)
Add ELF_DYNAMIC_AFTER_RELOC to allow target specific processing after
relocation.
For x86-64, add
#define DT_X86_64_PLT (DT_LOPROC + 0)
#define DT_X86_64_PLTSZ (DT_LOPROC + 1)
#define DT_X86_64_PLTENT (DT_LOPROC + 3)
1. DT_X86_64_PLT: The address of the procedure linkage table.
2. DT_X86_64_PLTSZ: The total size, in bytes, of the procedure linkage
table.
3. DT_X86_64_PLTENT: The size, in bytes, of a procedure linkage table
entry.
With the r_addend field of the R_X86_64_JUMP_SLOT relocation set to the
memory offset of the indirect branch instruction.
Define ELF_DYNAMIC_AFTER_RELOC for x86-64 to rewrite the PLT section
with direct branch after relocation when the lazy binding is disabled.
PLT rewrite is disabled by default since SELinux may disallow modifying
code pages and ld.so can't detect it in all cases. Use
$ export GLIBC_TUNABLES=glibc.cpu.plt_rewrite=1
to enable PLT rewrite with 32-bit direct jump at run-time or
$ export GLIBC_TUNABLES=glibc.cpu.plt_rewrite=2
to enable PLT rewrite with 32-bit direct jump and on APX processors with
64-bit absolute jump at run-time.
Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
I've updated copyright dates in glibc for 2024. This is the patch for
the changes not generated by scripts/update-copyrights and subsequent
build / regeneration of generated files.
One of the requirements to becoming a CVE Numbering Authority (CNA) is
to publish advisories. Do this by maintaining a file for each CVE fixed
in the advisories directory in the source tree. Links to the advisories
can then be shared as:
https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/GLIBC-SA-YYYY-NNNN
The file format at the moment is rudimentary and derives from the git
commit format, i.e. a subject line and a potentially multi-paragraph
description and then tags to describe some meta information. This is a
loose format at the moment and could change as we evolve this.
Also add a script process-fixed-cves.sh that processes these advisories
and generates a list to add to NEWS at release time.
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The patch adds two new macros, TUNABLE_GET_DEFAULT and TUNABLE_IS_INITIALIZED,
here the former get the default value with a signature similar to
TUNABLE_GET, while the later returns whether the tunable was set by
the environment variable.
Checked on x86_64-linux-gnu.
Reviewed-by: DJ Delorie <dj@redhat.com>
Tested-by: Zhangfei Gao <zhangfei.gao@linaro.org>
The tunable privilege levels were a retrofit to try and keep the malloc
tunable environment variables' behavior unchanged across security
boundaries. However, CVE-2023-4911 shows how tricky can be
tunable parsing in a security-sensitive environment.
Not only parsing, but the malloc tunable essentially changes some
semantics on setuid/setgid processes. Although it is not a direct
security issue, allowing users to change setuid/setgid semantics is not
a good security practice, and requires extra code and analysis to check
if each tunable is safe to use on all security boundaries.
It also means that security opt-in features, like aarch64 MTE, would
need to be explicit enabled by an administrator with a wrapper script
or with a possible future system-wide tunable setting.
Co-authored-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: DJ Delorie <dj@redhat.com>
The years of dealing with Binutils, GCC and GDB test results
made the community create good tools for comparison and analysis
of DejaGnu test results. This change allows to use those tools
for Glibc's test results as well.
The motivation for this change is Linaro's pre-commit testers,
which use a modified version of GCC's validate_failures.py
to create test xfail lists with baseline failures and known
flaky tests. See below links for an example xfails file (only
one link is supposed to work at any given time):
- https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/lastSuccessfulBuild/artifact/artifacts/artifacts.precommit/sumfiles/xfails.xfail/*view*/
- https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/lastSuccessfulBuild/artifact/artifacts/sumfiles/xfails.xfail/*view*/
Specifacally, this patch changes format of glibc's .sum files from ...
<cut>
FAIL: elf/test1
PASS: string/test2
</cut>
... to ...
<cut>
=== glibc tests ===
Running elf ...
FAIL: elf/test1
Running string ...
PASS: string/test2
</cut>.
And output of "make check" from ...
<cut>
FAIL: elf/test1
</cut>
... to ...
<cut>
FAIL: elf/test1
=== Summary of results ===
1 FAIL
1 PASS
</cut>.
Signed-off-by: Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
All the crypt related functions, cryptographic algorithms, and
make requirements are removed, with only the exception of md5
implementation which is moved to locale folder since it is
required by localedef for integrity protection (libc's
locale-reading code does not check these, but localedef does
generate them).
Besides thec code itself, both internal documentation and the
manual is also adjusted. This allows to remove both --enable-crypt
and --enable-nss-crypt configure options.
Checked with a build for all affected ABIs.
Co-authored-by: Zack Weinberg <zack@owlfolio.org>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The libcrypt was maked to be phase out on 2.38, and a better project
already exist that provide both compatibility and better API
(libxcrypt). The sparc optimizations add the burden to extra
build-many-glibcs.py configurations.
Checked on sparc64 and sparcv9.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The majority of grp routines are entry points for nss functionality.
This commit removes the 'grp' subdirectory and moves all nss-relevant
functionality and all tests to 'nss', and the 'setgroups' stub into
'posix' (alongside the 'getgroups' stub). References to grp/ are
accordingly changed. In addition, compat-initgroups.c, a fallback
implementation of initgroups is renamed to initgroups-fallback.c so that
the build system does not confuse it for nss_compat/compat-initgroups.c.
Build time improves very slightly; e.g. down from an average of 45.5s to
44.5s on an 8-thread mobile x86_64 CPU.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Notes for future devs:
* Add tools as you find they're needed, with version 0,0
* Bump version when you find an old tool that doesn't work
* Don't add a version just because you know it works
Co-authored-by: Lukasz Majewski <lukma@denx.de>
Co-authored-by: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
This patch makes build-many-glibcs.py use the new GMP 6.3.0 and MPFR
4.2.1 releases.
Tested with build-many-glibcs.py (host-libraries, compilers and glibcs
builds).
The 30379efad1 added _FORTIFY_SOURCE checks without check if compiler
does support all used fortify levels. This patch fixes it by first
checking at configure time the maximum support fortify level and using
it instead of a pre-defined one.
Checked on x86_64 with gcc 11, 12, and 13.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Tested-by: Florian Weimer <fweimer@redhat.com>
We mentioned eventual dropping of libcrypt in the 2.28 NEWS. Actually
put that plan in motion by first disabling building libcrypt by default.
note in NEWS that the library will be dropped completely in a future
release.
Also add a couple of builds into build-many-glibcs.py.
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Andreas K. Hüttel <dilfridge@gentoo.org>
The _FORTIFY_SOURCE is used as default by some system compilers,
and there is no way to check if some fortify extension does not
trigger any conformance issue.
Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Add --enable-fortify-source option.
It is now possible to enable fortification through a configure option.
The level may be given as parameter, if none is provided, the configure
script will determine what is the highest level possible that can be set
considering GCC built-ins availability and set it.
If level is explicitly set to 3, configure checks if the compiler
supports the built-in function necessary for it or raise an error if it
isn't.
If the configure option isn't explicitly enabled, it _FORTIFY_SOURCE is
forcibly undefined (and therefore disabled).
The result of the configure checks are new variables, ${fortify_source}
and ${no_fortify_source} that can be used to appropriately populate
CFLAGS.
A dedicated patch will follow to make use of this variable in Makefiles
when necessary.
Updated NEWS and INSTALL.
Adding dedicated x86_64 variant that enables the configuration.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
We add a 'make check' test that lints all Makefiles in the source
directory of the glibc build. This linting test ensures that the
lines in all Makefiles will be sorted correctly as developers
creates patches. It is added to 'make check' because it is
light-weight and supports the existing developer workflow
The test adds ~3s to a 'make check' execution.
No regressions on x86_64 and i686.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
We must return < 0, 0, or > 0 as the result of the comparison function
for cmp_to_key() to work correctly across all comparisons.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The scripts/sort-makefile-lines.py script sorts Makefile variables
according to project expected order.
The script can be used like this:
$ scripts/sort-makefile-lines.py < elf/Makefile > elf/Makefile.tmp
$ mv elf/Makefile.tmp elf/Makefile
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
This patch updates build-many-glibcs.py to use Linux 6.3 and GCC 13
branch by default.
Tested with build-many-glibcs.py (host-libraries, compilers and glibc
builds).
