The commit 446997ff14 introduced
this new usage of resplen. If build with gcc 9 -march>=z13 on s390x,
the following warning occurs:
res_send.c: In function ‘__res_context_send’:
res_send.c:539:6: error: ‘resplen’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
539 | if (resplen > HFIXEDSZ)
| ^
Therefore this patch adds a further DIAG_IGNORE_NEEDS_COMMENT in the
same way as it was previously done for usages of resplen or n.
See commit d1bc2cbbed.
This introduces a concept of trusted name servers, for which the
AD bit is passed through to applications. For untrusted name
servers (the default), the AD bit in responses are cleared, to
provide a safe default.
This approach is very similar to the one suggested by Pavel Šimerda
in <https://bugzilla.redhat.com/show_bug.cgi?id=1164339#c15>.
The DNS test framework in support/ is enhanced with support for
setting the AD bit in responses.
Tested on x86_64-linux-gnu.
Change-Id: Ibfe0f7c73ea221c35979842c5c3b6ed486495ccc
Since gettimeofday will shortly be implemented in terms of
clock_gettime on all platforms, internal code should use clock_gettime
directly; in addition to removing a layer of indirection, this will
allow us to remove the PLT-bypass gunk for gettimeofday. (We can't
quite do that yet, but it'll be coming later in this patch series.)
In many cases, the changed code does fewer conversions.
The changed code always assumes __clock_gettime (CLOCK_REALTIME)
cannot fail. Most of the call sites were assuming gettimeofday could
not fail, but a few places were checking for errors. POSIX says
clock_gettime can only fail if the clock constant is invalid or
unsupported, and CLOCK_REALTIME is the one and only clock constant
that's required to be supported. For consistency I grepped the entire
source tree for any other places that checked for errors from
__clock_gettime (CLOCK_REALTIME), found one, and changed it too.
(For the record, POSIX also says gettimeofday can never fail.)
(It would be nice if we could declare that GNU systems will always
support CLOCK_MONOTONIC as well as CLOCK_REALTIME; there are several
places where we are using CLOCK_REALTIME where _MONOTONIC would be
more appropriate, and/or trying to use _MONOTONIC and then falling
back to _REALTIME. But the Hurd doesn't support CLOCK_MONOTONIC yet,
and it looks like adding it would involve substantial changes to
gnumach's internals and API. Oh well.)
A few Hurd-specific files were changed to use __host_get_time instead
of __clock_gettime, as this seemed tidier. We also assume this cannot
fail. Skimming the code in gnumach leads me to believe the only way
it could fail is if __mach_host_self also failed, and our
Hurd-specific code consistently assumes that can't happen, so I'm
going with that.
With the exception of support/support_test_main.c, test cases are not
modified, mainly because I didn't want to have to figure out which
test cases were testing gettimeofday specifically.
The definition of GETTIME in sysdeps/generic/memusage.h had a typo and
was not reading tv_sec at all. I fixed this. It appears nobody has been
generating malloc traces on a machine that doesn't have a superseding
definition.
There are a whole bunch of places where the code could be simplified
by factoring out timespec subtraction and/or comparison logic, but I
want to keep this patch as mechanical as possible.
Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu,
powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
When using a system (e.g. Ubuntu 18.04) with libidn2 2.0.4 or earlier,
test results include:
FAIL: resolv/tst-resolv-ai_idn
FAIL: resolv/tst-resolv-ai_idn-latin1
It was previously stated
<https://sourceware.org/ml/libc-alpha/2018-05/msg00771.html> that "It
should fail to indicate you have bugs in your system libidn.".
However, the glibc testsuite should be indicating whether there are
bugs in glibc, not whether there are bugs in other system pieces - so
unless you consider it a glibc bug that it fails to work around the
libidn issues, these FAILs are not helpful. And as a general
principle, it's best for the expected glibc test results to be clean,
with Bugzilla used to track known bugs in glibc itself, rather than
people needing to know about the expected FAILs to tell if there are
problems with their glibc build. So, while there is an argument that
install.texi (not just the old NEWS entries for 2.28) should explain
the use of libidn2 and that 2.0.5 or later is recommended, test FAILs
are not the right way to indicate the presence of an old libidn2
version.
This patch accordingly makes those tests return UNSUPPORTED for older
libidn2 versions, just as they do when libidn2 isn't present at all.
As implied by that past discussion, it's possible this could result in
UNSUPPORTED for systems with older versions but whatever required
fixes backported so the tests previously passed, if there are any such
systems.
Tested for x86_64 on Ubuntu 18.04, including verifying that putting an
earlier version in place of 2.0.5 results in the tests FAILing whereas
using 2.0.5 as in the patch results in UNSUPPORTED. Florian reports
that the tests still run on Fedora 30, with libidn 2.2.0.
* resolv/tst-resolv-ai_idn-latin1.c (do_test): Mark test
unsupported with libidn2 before 2.0.5.
* resolv/tst-resolv-ai_idn.c (do_test): Likewise.
This patch fixes the gcc warnings seen with gcc 9 -march>=z13 on s390x:
res_send.c: In function ‘__res_context_send’:
res_send.c:498:7: error: ‘resplen’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
498 | if (n == 0 && (buf2 == NULL || *resplen2 == 0))
| ^
In this case send_vc is inlined into __res_context_send
and the maybe uninitialized resplen belongs to the one in send_vc.
In send_vc there is already a DIAG_IGNORE_NEEDS_COMMENT (5, "-Wmaybe-uninitialized")
and a comment which explains that this is a false-positive.
Note that resplen is used as return value.
This patch adds a further DIAG_IGNORE_NEEDS_COMMENT around the declaration of n
in __res_context_send and the comparison after n was set to the return value of send_vc.
ChangeLog:
* resolv/res_send.c (__res_context_send): Disable maybe-uninitialized
warning.
The purpose of the bp[0] == '.' check is unclear. Only the root domain
starts with '.'. The empty string is accepted as a domain name in many
places, denoting the root, but using it implicitly is confusing.
This functionality was deprecated in glibc 2.25.
This commit only includes the core changes to remove the
functionality. It does not remove the RES_USE_INET6 handling in the
individual NSS service modules and the res_use_inet6 function.
These changes will happen in future commits.
This patch removes the HP_TIMING_BITS usage for fast random bits and replace
with clock_gettime (CLOCK_MONOTONIC). It has unspecified starting time and
nano-second accuracy, so its randomness is significantly better than
gettimeofday.
Althoug it should incur in more overhead (specially for architecture that
support hp-timing), the symbol is also common implemented as a vDSO.
Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu. I also
checked on a i686-gnu build.
* include/random-bits.h: New file.
* resolv/res_mkquery.c [HP_TIMING_AVAIL] (RANDOM_BITS,
(__res_context_mkquery): Remove usage hp-timing usage and replace with
random_bits.
* resolv/res_send.c [HP_TIMING_AVAIL] (nameserver_offset): Likewise.
* sysdeps/posix/tempname.c [HP_TIMING_AVAIL] (__gen_tempname):
Likewise.
The Linux kernel suppresses some ICMP error messages by default for
UDP sockets. This commit enables full ICMP error reporting,
hopefully resulting in faster failover to working name servers.
This patch adds fall-through comments in some cases where -Wextra
produces implicit-fallthrough warnings.
The patch is non-exhaustive. Apart from architecture-specific code
for non-x86_64 architectures, it does not change sunrpc/xdr.c (legacy
code, probably should have such changes, but left to be dealt with
separately), or places that already had comments about the
fall-through but not matching the form expected by
-Wimplicit-fallthrough=3 (the default level with -Wextra; my
inclination is to adjust those comments to match rather than
downgrading to -Wimplicit-fallthrough=1 to allow any comment), or one
place where I thought the implicit fallthrough was not correct and so
should be handled separately as a bug fix. I think the key thing to
consider in review of this patch is whether the fall-through is indeed
intended and correct in each place where such a comment is added.
Tested for x86_64.
* elf/dl-exception.c (_dl_exception_create_format): Add
fall-through comments.
* elf/ldconfig.c (parse_conf_include): Likewise.
* elf/rtld.c (print_statistics): Likewise.
* locale/programs/charmap.c (parse_charmap): Likewise.
* misc/mntent_r.c (__getmntent_r): Likewise.
* posix/wordexp.c (parse_arith): Likewise.
(parse_backtick): Likewise.
* resolv/ns_ttl.c (ns_parse_ttl): Likewise.
* sysdeps/x86/cpu-features.c (init_cpu_features): Likewise.
* sysdeps/x86_64/dl-machine.h (elf_machine_rela): Likewise.
The IPv4 address parser in the getaddrinfo function is changed so that
it does not ignore trailing whitespace and all characters after it.
For backwards compatibility, the getaddrinfo function still recognizes
legacy name syntax, such as 192.000.002.010 interpreted as 192.0.2.8
(octal).
This commit does not change the behavior of inet_addr and inet_aton.
gethostbyname already had additional sanity checks (but is switched
over to the new __inet_aton_exact function for completeness as well).
To avoid sending the problematic query names over DNS, commit
6ca53a2453 ("resolv: Do not send queries
for non-host-names in nss_dns [BZ #24112]") is needed.
Before this commit, nss_dns would send a query which did not contain a
host name as the query name (such as invalid\032name.example.com) and
then reject the answer in getanswer_r and gaih_getanswer_slice, using
a check based on res_hnok. With this commit, no query is sent, and a
host-not-found error is returned to NSS without network interaction.
The __libc_freeres framework does not extend to non-libc.so objects.
This causes problems in general for valgrind and mtrace detecting
unfreed objects in both libdl.so and libpthread.so. This change is
a pre-requisite to properly moving the malloc hooks out of malloc
since such a move now requires precise accounting of all allocated
data before destructors are run.
This commit adds a proper hook in libc.so.6 for both libdl.so and
for libpthread.so, this ensures that shm-directory.c which uses
freeit () to free memory is called properly. We also remove the
nptl_freeres hook and fall back to using weak-ref-and-check idiom
for a loaded libpthread.so, thus making this process similar for
all DSOs.
Lastly we follow best practice and use explicit free calls for
both libdl.so and libpthread.so instead of the generic hook process
which has undefined order.
Tested on x86_64 with no regressions.
Signed-off-by: DJ Delorie <dj@redhat.com>
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Contributed by
Agustina Arzille <avarzille@riseup.net>
Amos Jeffries <squid3@treenet.co.nz>
David Michael <fedora.dm0@gmail.com>
Marco Gerards <marco@gnu.org>
Marcus Brinkmann <marcus@gnu.org>
Neal H. Walfield <neal@gnu.org>
Pino Toscano <toscano.pino@tiscali.it>
Richard Braun <rbraun@sceen.net>
Roland McGrath <roland@gnu.org>
Samuel Thibault <samuel.thibault@ens-lyon.org>
Thomas DiModica <ricinwich@yahoo.com>
Thomas Schwinge <tschwinge@gnu.org>
* htl: New directory.
* sysdeps/htl: New directory.
* sysdeps/hurd/htl: New directory.
* sysdeps/i386/htl: New directory.
* sysdeps/mach/htl: New directory.
* sysdeps/mach/hurd/htl: New directory.
* sysdeps/mach/hurd/i386/htl: New directory.
* nscd/Depend, resolv/Depend, rt/Depend: Add htl dependency.
* sysdeps/mach/hurd/i386/Implies: Add mach/hurd/i386/htl imply.
* sysdeps/mach/hurd/i386/libpthread.abilist: New file.
The old implementation based on hsearch_r used an ad-hoc C string
encoding and produced an incorrect format on the wire for domain
names which contained bytes which needed escaping when printed.
This commit switches to ns_name_pton for the wire format conversion
(now that we have separate tests for it) and uses a tsearch tree
with a suitable comparison function to locate compression targets.
This patch increases timeouts on three tests I observed timing out on
slow systems.
* malloc/tst-malloc-tcache-leak.c (TIMEOUT): Define to 50.
* posix/tst-glob-tilde.c (TIMEOUT): Define to 200.
* resolv/tst-resolv-res_ninit.c (TIMEOUT): Define to 50.
This patch, relative to a tree with
<https://sourceware.org/ml/libc-alpha/2017-11/msg00797.html> (pending
review) applied, obsoletes p_secstodate, making the underlying
function __p_secstodate into a compat symbol not available for new
binaries or ports. The calls in ns_print.c (part of incomplete
handling of TKEY) are changed to use %lu to print times instead of
trying to pretty-print the times any more.
Tested for x86_64.
* resolv/res_debug.c (p_secstodate): Condition definition on
[SHLIB_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)]. Define
directly as __p_secstodate, and as a compat symbol. Do not use
libresolv_hidden_def.
* resolv/resolv.h (p_secstodate): Remove macro and function
declaration.
* resolv/ns_print.c (ns_sprintrrf): Print times with %lu, not
using p_secstodate.
* include/resolv.h (__p_secstodate): Do not use
libresolv_hidden_proto.
* resolv/Makefile (tests): Move tst-p_secstodate to ....
(tests-internal): ... here.
* resolv/tst-p_secstodate.c: Include <shlib-compat.h>. Condition
all contents on [TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)]
and declare and use __p_secstodate and use compat_symbol_reference
in that case.
[!TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)] (do_test): Add
implementation returning 77.
The resolv/res_debug.c function p_secstodate (which is a public
function exported from libresolv, taking an unsigned long argument)
does:
struct tm timebuf;
time = __gmtime_r(&clock, &timebuf);
time->tm_year += 1900;
time->tm_mon += 1;
sprintf(output, "%04d%02d%02d%02d%02d%02d",
time->tm_year, time->tm_mon, time->tm_mday,
time->tm_hour, time->tm_min, time->tm_sec);
If __gmtime_r returns NULL (because the year overflows the range of
int), this will dereference a null pointer. Otherwise, if the
computed year does not fit in four characters, this will cause a
buffer overrun of the fixed-size 15-byte buffer. With current GCC
mainline, there is a compilation failure because of the possible
buffer overrun.
I couldn't find a specification for how this function is meant to
behave, but Paul pointed to RFC 4034 as relevant to the cases where
this function is called from within glibc. The function's interface
is inherently problematic when dates beyond Y2038 might be involved,
because of the ambiguity in how to interpret 32-bit timestamps as such
dates (the RFC suggests interpreting times as being within 68 years of
the present date, which would mean some kind of interface whose
behavior depends on the present date).
This patch works on the basis of making a minimal fix in preparation
for obsoleting the function. The function is made to handle times in
the interval [0, 0x7fffffff] only, on all platforms, with <overflow>
used as the output string in other cases (and errno set to EOVERFLOW
in such cases). This seems to be a reasonable state for the function
to be in when made a compat symbol by a future patch, being compatible
with any existing uses for existing timestamps without trying to work
for later timestamps. Results independent of the range of time_t also
simplify the testcase.
I couldn't persuade GCC to recognize the ranges of the struct tm
fields by adding explicit range checks with a call to
__builtin_unreachable if outside the range (this looks similar to
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80776>), so having added
a range check on the input, this patch then disables the
-Wformat-overflow= warning for the sprintf call (I prefer that to the
use of strftime, as being more transparently correct without knowing
what each of %m and %M etc. is).
I do not know why this build failure should be new with mainline GCC
(that is, I don't know what GCC change might have introduced it, when
the basic functionality for such warnings was already in GCC 7).
I do not know if this is a security issue (that is, if there are
plausible ways in which a date before -999 or after 9999 from an
untrusted source might end up in this function). The system clock is
arguably an untrusted source (in that e.g. NTP is insecure), but
probably not to that extent (NTP can't communicate such wild
timestamps), and uses from within glibc are limited to 32-bit inputs.
Tested with build-many-glibcs.py that this restores the build for arm
with yesterday's mainline GCC. Also tested for x86_64 and x86.
[BZ #22463]
* resolv/res_debug.c: Include <libc-diag.h>.
(p_secstodate): Assert time_t at least as wide as u_long. On
overflow, use integer seconds since the epoch as output, or use
"<overflow>" as output and set errno to EOVERFLOW if integer
seconds since the epoch would be 14 or more characters.
(p_secstodate) [__GNUC_PREREQ (7, 0)]: Disable -Wformat-overflow=
for sprintf call.
* resolv/tst-p_secstodate.c: New file.
* resolv/Makefile (tests): Add tst-p_secstodate.
($(objpfx)tst-p_secstodate): Depend on $(objpfx)libresolv.so.
res_hnok rejected some host names used on the Internet, such as
www-.example.com. res_hnok and res_dnok failed to perform basic syntax
checking on DNS domain names.
Also fix res_mailok, res_ownok.
Remove the bogus targets (and source) that supposedly build ga_test.
This code was added to resolv very early in the development process
but does not appear to be an actual test program. The target for
building this file is tests but because the glibc Make system is
built the way it is, the target is overriden by higher-level tests
targets and, therefore, the ga_test program is never built. Removing
the target and the source code makes the resolv/Makefile less confusing.
Tested by building and running 'make check' on 64 bit host running
Kernel 4.10.0-19 configured with
--prefix=/home/hawkinsw/code/glibc-build/install
--enable-hardcoded-path-in-tests
--disable-mathvec
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Various subdirectories of glibc include Banner files to put some text
in the output of executing libc.so.6, under "Available extensions".
Some of those subdirectories (e.g. crypt) may originally have been
add-ons (and so optional, so a particular glibc build might or might
not have included them), but except for libidn they aren't now (or if
only included in some builds, in the case of soft-fp, the inclusion
depends on the architecture for which glibc is configured rather than
having any glibc configuration for which it's an optional feature),
and it doesn't seem useful for the libc.so.6 output to call out a few
features like that.
This patch removes the non-add-on Banner files, updating contrib.texi
where they noted contributions not otherwise mentioned there.
Tested for x86_64.
* crypt/Banner: Remove file.
* nptl/Banner: Likewise.
* resolv/Banner: Likewise.
* soft-fp/Banner: Likewise.
* nptl/Makefile ($(objpfx)banner.h): Remove rule.
($(objpfx)version.d): Remove dependency on banner.h.
($(objpfx)version.os): Likewise.
* nptl/version.c (banner): Do not include banner.h.
* manual/contrib.texi: Update entries for Richard Henderson, Jakub
Jelinek and BIND code.
