It is not present in the sources and 'git log -S KERN_QUANTUM main'
returns nothing.
Reviewed by: olce
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D46823
Reduce the number of md5c.c between the three of these from two to one
by just reaching into the kernel build for both userland builds. The
precedent for this already exists for sha2 in both cases.
_libmd_ symbol privatization bits have been moved to sys/md5.h and
md5.h remains to #include <sys/md5.h> for compatibility.
This stops exporting MD5Pad() in the process because the kernel stopped
exporting it in 502a35d60f. soversion is bumped accordingly.
This also renames the libc version of stack_protector.c; it previously
only worked by coincidence because .PATH ordering worked out such that
we got the right one, but this is not the case anymore. Remove the
landmine.
PR: 280784 (exp-run)
Reviewed by: allanjude, delphij
Differential Revision: https://reviews.freebsd.org/D34497
and allow to revert it back to 48 with WITHOUT_JEMALLOC_LG_VADDR_WIDE build
option.
Reviewed by: andrew, emaste
Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D46686
As xprintf has not kept up with our standard printf(3) implementation,
it is becoming increasingly dangerous to continue to allow it to take
over if USE_XPRINTF is defined. Remove that code, while still allowing
applications which know about xprintf to select it.
Reviewed by: phk
Differential Revision: https://reviews.freebsd.org/D46765
The manual page says %m is replaced with “the string representation of
the error code stored in the errno variable at the beginning of the
call”. However, we don't actually save `errno` until fairly late in
`__vfprintf()`. Make sure it is saved before we do anything that
might perturb `errno`.
MFC after: 1 week
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D46718
The purpose of the "bounds" test is to check that the function does not
overread the array bounds. The old unit test, copied from the strlcpy()
one, always ensured that we see the character c memccpy() is looking for
in the source array before the array ends. While this is correct for
strlcpy(), memccpy()'s specification does not guarantee that c is
present within the given size limit.
The updated test handles this case better, ensuring that the source
array ends early if c is not supposed to be present.
Reported by: getz
Approved by: emaste
See also: D46052
Event: GSoC 2024
Differential Revision: https://reviews.freebsd.org/D46051
Don't provide default linkage for jemalloc 3.0 compatability symbols.
We stopped declaring these interfaces with the introduction of jemalloc
4.0 prior to FreeBSD 11.0. Any code using them would have had to
declare them manually so stop declaring them and export the symbols
directly for compatability. Arguably they should be x86 only as they
were never declared on other Tier-1 architectures.
Reviewed by: imp, kib
Differential Revision: https://reviews.freebsd.org/D46407
Derived from tests posted by kib in D46108. I made one of them use a
pthread barrier instead of sleeping.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D46176
Call it libc_exit_test instead of exit_test because the NetBSD test
suite already has a file with the latter name. This is in preparation
for adding other exit()-related tests.
MFC after: 2 weeks
An overread condition in memccpy(dst, src, c, len) would occur if
src does not cross a 16 byte boundary and there is no instance of
c between *src and the next 16 byte boundary. This could cause a
read fault if src is just before the end of a page and the next page
is unmapped or unreadable.
The bug is a consequence of basing memccpy() on the strlcpy() code:
whereas strlcpy() assumes that src is a nul-terminated string and
hence a terminator is always present, c may not be present at all in
the source string. It was not caught earlier due to insufficient
unit test design.
As a part of the fix, the function is refactored such that the runt
case (buffer length from last alignment boundary between 1 and 32 B)
is handled separately. This reduces the number of conditional
branches on all code paths and simplifies the handling of early
matches in the non-runt case. Performance is improved slightly.
os: FreeBSD
arch: amd64
cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
│ memccpy.unfixed.out │ memccpy.fixed.out │
│ sec/op │ sec/op vs base │
Short 66.76µ ± 0% 62.45µ ± 1% -6.44% (p=0.000 n=20)
Mid 7.938µ ± 0% 7.967µ ± 0% +0.36% (p=0.001 n=20)
Long 3.577µ ± 0% 3.577µ ± 0% ~ (p=0.429 n=20)
geomean 12.38µ 12.12µ -2.08%
│ memccpy.unfixed.out │ memccpy.fixed.out │
│ B/s │ B/s vs base │
Short 1.744Gi ± 0% 1.864Gi ± 1% +6.89% (p=0.000 n=20)
Mid 14.67Gi ± 0% 14.61Gi ± 0% -0.36% (p=0.001 n=20)
Long 32.55Gi ± 0% 32.55Gi ± 0% ~ (p=0.429 n=20)
geomean 9.407Gi 9.606Gi +2.12%
Reported by: getz
Reviewed by: getz
Approved by: mjg (blanket, via IRC)
See also: D46051
MFC: stable/14
Event: GSoC 2024
Differential Revision: https://reviews.freebsd.org/D46052
Checking the first nibble of the IPv6 address to be 0 and then
excluding two well known cases (v4-mapped, loopback) leaves us with
more cases where the first nibble could be 0, e.g., the RFC 6052,
2.1 Well-Known Prefix 64:ff9b::/96.
It is not practical to track them all and it is not clear what lead
to this special casing originally, so remove them.
While here also remove the IN6_IS_ADDR_LINKLOCAL() + NI_NUMERICHOST
case as link-local address resolution does exist.
We do leave the IN6_IS_ADDR_MULTICAST() case for now as I could
not find any references to any official reverse lookups for these.
Adding comments for more case (and some historic behaviour) in order
to make it easier to follow the logic.
PR: 279618
Fixes: 6cb9418289
MFC after: 6 weeks
Reviewed by: hrs
Differential Revision: https://reviews.freebsd.org/D45547
GCC doesn't like `#pragma weak macro(foo)`, but that's fine; just slap
a __weak_symbol on the definition to more reliably make it weak
anyways.
Reviewed by: kib (earlier version), markj
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D45976
GCC emits a warning about shadowing a builtin with our mempcpy
declaration, so switch it to using the same model as memcpy() and
use the apparently-existing __builtin___mempcpy_chk().
Reviewed by: kib (earlier version), markj
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D45976
Test case to check if an implementation of memset correctly
handles the value passed being wider than a byte
Approved by: emaste
Reviewed By: fuz (GSoC mentor), emaste
Sponsored by: Google LLC (GSoC 2024)
Differential Revision: https://reviews.freebsd.org/D45738
The entire recv*() implementation set is ripe for opportunities to
validate, so do what we can with what we have.
Reviewed by: markj
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D45686
Notably sanity check indices passed to the FD_*() macros against the
size of the fd_set itself.
Reviewed by: markj
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D45685
Check both the buffer size of the iov object itself, as well as that
of each indidvidually io base.
Reviewed by: markj
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D45684
That is to say, fortify getrandom(2).
Reviewed by: markj
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D45683
This includes all of the w*() equivalents to str*()/mem*() implemented
in more or less the same way. For these ones, we'll just use
header-only implementations from the start to stop further cluttering
the libc symbol table.
Reviewed by: markj
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D45682
The immediately obvious and attractive targets from <stdlib.h> are
arc4random_buf(3) and realpath(3) -- scraping the header didn't reveal
much else of interest.
Reviewed by: markj
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D45681
For poll/ppoll we just need to bounds-check the poll array that we're
about to write out to.
Reviewed by: kib, markj (earlier version)
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D45680
ssp/ssp.h needed some improvements:
- `len` isn't always a size_t, it may need casted
- In some cases we may want to use a len that isn't specified as a
parameter (e.g., L_ctermid), so __ssp_redirect() should be more
flexible.
- In other cases we may want additional checking, so pull all of the
declaration bits out of __ssp_redirect_raw() so that some functions
can implement the body themselves.
strlcat/strlcpy should be the last of the fortified functions that get
their own __*_chk symbols, and these cases are only done to be
consistent with the rest of the str*() set.
Reviewed by: markj
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D45679
Switch away from pointer arithmetic to provide more obvious semantics
for checking overlap on pointer ranges. This lets us remove some casts
that need not exist and removes some possible fragility in its use.
While we're here, check for overflow just in case; sometimes we use a
caller-supplied size if __builtin_object_size(3) can't deduce the buffer
size, and we should fail the check if the size is nonsensical for the
provided buffers.
Reviewed by: markj
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
The _FORTIFY_SOURCE tests will be generated by a lua script to avoid a
lot of redundancy in writing these tests. For each function that we're
fortifying, the plan is to test at least the following three scenarios:
- Writing up to one byte before the end of the buffer,
- Writing up to the end of the buffer,
- Writing one byte past the end of the buffer
The buffer is shoved into a struct on the stack to guarantee a stack
layout in which we have a valid byte after the buffer so that level 2
fortification will trip and we can have confidence that it wasn't some
other stack/memory protection instead.
The generated tests are divided roughly into which header we're
attributing them to so that we can parallelize the build -- the full set
is a bit over 9000 lines of C and takes 11s to build on the hardware
that I'm testing on if it's a single monolothic file.
Reviewed by: markj
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D45678
We'll be using it in some upcoming definitions in headers, so move it
back now but slap a warning on it. Our upcoming uses will all be inside
of inline functions, so we're not overly concerned about double
evaluation immediately.
Reviewed by: markj
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D45677
Armv6 is being removed from the treem and the comment applies to armv7.
Reviewed by: manu, imp, emaste
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45645
See 8164d511d6 ("libc/tests: Fix installation without MK_TOOLCHAIN")
for some background. Here we should really be testing MK_CLANG instead,
since that's what gates compilation of libclang_rt.
Fixes: 8164d511d6 ("libc/tests: Fix installation without MK_TOOLCHAIN")
There is some exotic conditional logic here to avoid building a
particular test if a certain UBSAN library isn't present in the
toolchain sysroot. This causes build failures for me when doing an
"installworld WITHOUT_TOOLCHAIN=", which I do frequently during tests.
I believe the problem is that SYSROOT is unset during installworld, so
the build sees the host's copy of libclang_rt.ubsan_standalone.a and
then tries to install a binary that wasn't built during buildworld. Try
to make the check a bit less fragile.
Reviewed by: dim
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D45035
To fix WITHOUT_NIS build. Building yp_xdr.c is gated by MK_NIS.
PR: 279270
Reported by: peterj
Reported by: matteo
Reported by: Michael Dexter's Build Option Survey run
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45347
Notably:
- libc needs to #undef some of the macros from ssp/* for underlying
implementations
- ssp/* wants a __RENAME() macro (snatched more or less from NetBSD)
There's some extra hinkiness included for read(), since libc spells it
as "_read" while the rest of the world spells it "read."
Reviewed by: imp, ngie
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D32307
This is a mostly-unmodified copy of the various *_chk implementations
and headers from NetBSD, without yet modifying system headers to start
actually including them. A future commit will also apply the needed
bits to fix ssp/unistd.h.
Reviewed by: imp, pauamma_gundo.com (both previous versions), kib
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D32306
Allow restoring the behavior of '{' as described in regex(3).
Ie. only treat it as start of bounds if followed by a digit.
If NO_STRICT_REGEX is not defined, the behavior introduced by
commit a4a801688c is retained,
otherwise the previous behavior is restored.
Differential Revision: https://reviews.freebsd.org/D45134
Capsicum-sandboxed applications generally cannot use dlopen, as absolute
and cwd-relative paths cannot be accessed. Mention that fdlopen is
useful for sandboxed applications.
PR: 277169
Reviewed by: markj, oshogbo
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45108
When checking for the destructor pointer belonging to some still
loaded dso, do not limit the possible dso to the one instantiated the
destructor. For instance, dso could set up the dtr pointer to a function
from libcxx.
PR: 278701
Reported by: vd
Reviewed by: dim, emaste, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D45074
