We don't need to use an interposable symbol for this purpose and it's
simpler to just call the syscall in libsys. This resolves a bug where
we were incorrectly using __realpathat in libc not libsys.
While here, drop support for running on a FreeBSD 12 kernel and simplify
includes.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D49048
The rpc(3) itself was not designed with multithreading in mind, but we can
actually achieve some parallelism without modifying the library and the
framework. This transport will allow to process RPCs in threads, with
some hacks on the application side (documented in code). We make
reentrable only one method - SVC_REPLY(). Reading and parsing of incoming
calls is still done synchronously. But the actual processing of the calls
can be offloaded to a thread, and once finished the thread can safely
execute svc_sendreply() and the reply would be sent with the correct xid.
Differential Revision: https://reviews.freebsd.org/D48569
To be used by NFS related daemons that provide RPC services to the kernel.
Some implementation details inside the new svc_nl.c.
Reviewed by: rmacklem
Differential Revision: https://reviews.freebsd.org/D48550
This uses DES and it's likely that nobody uses that in 2025.
If somebody uses this we help them by deprecating and removing this.
Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D30683
- Use GETENTROPY_MAX instead of hard-coding the value.
- Check for EINVAL instead of EIO
Fixes: 473681a1a5 ("libc: Fix getentropy POSIX 2024 conformance issues")
GETENTROPY_MAX should be defined in limits.h. EINVAL is the return
value for buflen > GETENTROPY_MAX.
PR: 282783
Reviewed by: markj, asomers, jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47689
Commit bea89d038a added strlcat but also introduced a memchr wrapper
in the source tree rather than using the autogenerated one used for
AARCH64_STRING_FUNCS. Move memchr.S to MDSRS and add a cleanup rule for
the old wrapper.
Reviewed by: fuz
Sponsored by: The FreeBSD Foundation
Fixes: bea89d038a ("lib/libc/aarch64/string: add strlcat SIMD implementation")
Differential Revision: https://reviews.freebsd.org/D48502
Our SIMD-enhanced strlen() implementation for AArch64 uses
a floating-point comparison to compare a bit mask to zero.
This works fine under normal circumstances, but fails if
the FZ (flush-to-zero) flag is set in FPCR (the floating-point
control register) as then the CPU no longer distinguishes
denormals from zero.
This was not caught during testing; this flag is rarely set
and programs that do so rarely perform string manipulation.
Avoid this problem by using an integer comparison instead.
The performance impact seems to be small (about 0.5 %) on
the Windows 2023 Dev Kit, but seems to be more significant
(up to around 19%) on the RPi 5.
Reviewed by: getz
Fixes: 3863fec1ce
Differential Revision: https://reviews.freebsd.org/D48442
A port of the amd64 implementation with some slight changes due to
differences in instructions provided by aarch64.
No ASIMD for the same reason as the amd64 code: it's just not particularly
suitable for this application.
Event: EuroBSDcon 2024
Approved by: security (cperciva)
Reviewed by: getz, cperciva
Differential Revision: https://reviews.freebsd.org/D46758
Adds a SIMD enhanced strlen for Aarch64. It takes inspiration from
the amd64 implementation but I struggled getting the performance I
had hoped for on cores like the Graviton3 when compared to the
existing implementation from Arm Optimized Routines.
See the DR for bechmark results.
Tested by: fuz (exprun)
Reviewed by: fuz, emaste
Sponsored by: Google LLC (GSoC 2024)
PR: 281175
Differential Revision: https://reviews.freebsd.org/D45623
I noticed that we have a SIMD optimized memcpy in the
arm-optimized-routines in /contrib.
This patch ensures we use the SIMD variant as opposed to the Scalar
optimized variant.
Benchmarks are generated by fuz' strperf utility.
See the DR for benchmark results.
Tested by: fuz (exprun)
Reviewed by: fuz, emaste
Sponsored by: Google LLC (GSoC 2024)
PR: 281175
Differential Revision: https://reviews.freebsd.org/D46251
This patch requires D46243 as it depends on strlcpy being labeled
__strlcpy.
It's a direct copy from the amd64 string functions using memchr and
strlcpy to implement strlcat.
Tested by: fuz (exprun)
Reviewed by: fuz, emaste
Sponsored by: Google LLC (GSoC 2024)
PR: 281175
Differential Revision: https://reviews.freebsd.org/D46272
This patch requires D46170 as it depends on strlcpy being labeled
__memccpy.
It's a direct copy from the amd64 string functions.
Tested by: fuz (exprun)
Reviewed by: fuz, emaste
Sponsored by: Google LLC (GSoC 2024)
PR: 281175
Differential Revision: https://reviews.freebsd.org/D46292
This changeset includes a port of the SIMD implementation of
memccpy for amd64 to Aarch64.
Performance is significantly better than the scalar implementation
except for short strings.
Benchmark results are as usual generated by the strperf utility
written by fuz.
See the DR for benchmark results.
Tested by: fuz (exprun)
Reviewed by: fuz, emaste
Sponsored by: Google LLC (GSoC 2024)
PR: 281175
Differential Revision: https://reviews.freebsd.org/D46170
This changeset includes a port of the SIMD implementation of
strncmp for amd64 to Aarch64.
It is based on D45839 with added handling for the limit.
An extended unit test for strncmp is currently being written to
make sure the bounds checks for page crossings work as expected.
Performance is significantly better than the existing
implementation from the Arm Optimized Routines repository.
Benchmark results are generated by the strperf utility by fuz.
See the DR for benchmark results.
Tested by: fuz (exprun)
Reviewed by: fuz, emaste
Sponsored by: Google LLC (GSoC 2024)
PR: 281175
Differential Revision: https://reviews.freebsd.org/D45943
This changeset includes a port of the SIMD implementation of
strlcpy for amd64 to Aarch64.
It is based on memccpy (D46170) with some minor differences.
Performance is significantly better than the scalar implementation.
Benchmark results are as usual generated by the strperf utility
written by fuz.
See the DR for benchmark results.
Tested by: fuz (exprun)
Reviewed by: fuz, emaste
Sponsored by: Google LLC (GSoC 2024)
PR: 281175
Differential Revision: https://reviews.freebsd.org/D46243
Call into SIMD strlen and stpcpy for an optimized strcat. Port of
D42600 for amd64.
Tested by: fuz (exprun)
Reviewed by: fuz, emaste
Sponsored by: Google LLC (GSoC 2024)
PR: 281175
Differential Revision: https://reviews.freebsd.org/D46417
These are direct copies from the amd64 string functions using the
optimized strcspn from D46398
Tested by: fuz (exprun)
Reviewed by: fuz, emaste
Sponsored by: Google LLC (GSoC 2024)
PR: 281175
Differential Revision: https://reviews.freebsd.org/D46399
This is a port of the Scalar optimized variant of strcspn for amd64
to aarch64 It utilizes a LUT to speed up the function, a SIMD
variant is still under development.
Performance benchmarks are as usual generated by strperf.
See the DR for benchmark results.
Tested by: fuz (exprun)
Reviewed by: fuz, emaste
Sponsored by: Google LLC (GSoC 2024)
PR: 281175
Differential Revision: https://reviews.freebsd.org/D46398
This is a port of the Scalar optimized variant of strspn for amd64
to aarch64.
It utilizes a LUT to speed up the function, a SIMD variant is still
under development.
See the DR for benchmark results.
Tested by: fuz (exprun)
Reviewed by: fuz, emaste
Sponsored by: Google LLC (GSoC 2024)
PR: 281175
Differential Revision: https://reviews.freebsd.org/D46396
This changeset includes a port of the SIMD implementation of strcmp
for amd64 to Aarch64.
Below is a description of its method as described in D41971.
The basic idea is to process the bulk of the string in aligned
blocks of 16 bytes such that one string runs ahead and the other
runs behind. The string that runs ahead is checked for NUL bytes,
the one that runs behind is compared with the corresponding chunk
of the string that runs ahead. This trades an extra load per
iteration for the very complicated block-reassembly needed in the
other implementations (bionic, glibc). On the flip side, we need
two code paths depending on the relative alignment of the two
buffers.
The initial part of the string is compared directly if it is known
not to cross a page boundary. Otherwise, a complex slow path to
avoid crossing into unmapped memory commences.
Performance is better in most cases than the existing
implementation from the Arm Optimized Routines repository.
See the DR for benchmark results.
Tested by: fuz (exprun)
Reviewed by: fuz, emaste
Sponsored by: Google LLC (GSoC 2024)
PR: 281175
Differential Revision: https://reviews.freebsd.org/D45839
A number of image processing packages assume that swab() can handle to
and from being the same. However, POSIX.1 states that overlapping
buffers produces undefined results. Our old implementation would produce
coherent results, but the recent change to the musl-inspired code does
not. Since there's complaints in the forums for these image processing
packages for musl and now FreeBSD, update the algorithm to just read a
word at a time and bswap16 the results. All FreeBSD's architecutres
support unaligned access in userland, and swab is not used in the kernel
(g_part_apm has its own copy), so opt for even simpler code that's
easier to understand. This makes the overlapping behavior match i386 again,
since its assembler routine for swab handles overlapping correctly.
PR: 283698
Sponsored by: Netflix
Reviewed by: nwhitehorn
Differential Revision: https://reviews.freebsd.org/D48259
Doing some debugging I noticed that applications using rpc(3) would often
make lseek(2) on a totally bogus file descriptor, that looks more like a
pointer. So, what happens here is that xdrrec type xdr doesn't keep a
track of how many bytes were sent/received on the stream and tries to
obtain this number via lseek(2). Then it adds/subtracts the offset in the
internal buffer from the obtained number. This code originates from the
original Sun RPC import in 1994. However, it was not a working code even
if Solaris would support lseek(2) on a socket, because it was passing not
the file descriptor, but a pointer to opaque data from upper RPC layer.
It could be that previously (before import to FreeBSD) code was correct,
but the Solaris 8 documentation says that lseek(2) on socket isn't
supported [1]. Maybe supported on older Solaris?
Anyway, this lseek(2) never worked and xdr_getpos() would always fail on
xdrrec object, until 8f55a568f6 in 2008 it was slightly fixed to
tolerate failure of lseek(2) and return a correct value within the small
internal buffer for XDR_ENCODE mode and a an incorrect (negative to
unsigned) result for XDR_DECODE. It seems no consumer ever calls
xdr_getpos()/xdr_setpos() on this kind of descriptor when in XDR_DECODE
mode.
So, remove this lseek(2) and preserve operation within the small buffer
only. Supposedly fix the operation for XDR_DECODE mode. Note that there
is no use and no test coverage for the XDR_DECODE.
Note that xdr(3) manual page already documents limitations for
xdr_getpos() and xdr_setpos() for the stream type objects.
[1] https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8003/6ruu1b0or/index.html
Reviewed by: asomers, markj
Differential Revision: https://reviews.freebsd.org/D48205
These tests create a linked list with one entry for every group on the
running system. On a system with about 30,000 groups, the test took 69
seconds to run, and crashed Kyua with the below error:
kyua: E: string or blob too big (sqlite op: sqlite3_bind_blob) (sqlite db: /root/.kyua/store/results.usr_tests.20241231-203317-570235.db).
Fix the test by limiting it to operating on the first 1024 groups.
Apply the same change to getpw_test and getserv_test too, which are
vulnerable to the same problem.
MFC after: 2 weeks
Sponsored by: ConnectWise
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D48275
Make it easire to update jemalloc by moving the FreeBSD specific files
and the generated files into lib/libc. This allows us to regenerate them
more easily, and emphasizes a bit that we may have to regenerate stuff
from upstream.
This is necessary to also unthin the import from the vendor branch as
well (which will be needed to simplify the imports in the future since
we are trying to use contrib/jemalloc for two different things).
No functional change.
Sponsored by: Netflix
The more generated things that are in contrib/jemalloc tree, the more
chances for interference goes way up. So, move this file into our
lib/libc tree. I didn't add a 'generated file' line / info, but this is
funky enough I don't think we need that. We do add things to the man
page, and that should be tracked in the contrib/jemalloc tree to allow
better importing experience.
Sponsored by: Netflix
The day-of-week calculation used the raw year value without adjusting
for TM_YEAR_BASE, so it was off by one for 300 years out of every 400;
it just happened to be correct for 1901 through 2000. It also used a
loop where a simple addition would have sufficed.
While here, simplify our version of Gauss's algorithm, and document
that we assume the Gregorian calendar.
MFC after: 1 week
PR: 282916
Reviewed by: imp, allanjude, philip
Differential Revision: https://reviews.freebsd.org/D47977
For some reason return value of the __je_bootstrap_malloc()
is not checked and then de-referenced few lines below, causing
a SEGV if an early allocation fails.
MFC after: 1 month
The new unit test validates that the range reduction works correctly.
We do not currently validate that there is no bias as that would take
too much time and memory for a unit test.
Reviewed by: cem
Approved by: emaste
Differential Revision: https://reviews.freebsd.org/D47659
Daniel Lemire has published a more efficient range reduction algorithm
for finding a random number in a given range without bias, reducing the
number of divisions to none in the common case and 1 in case the initial
sample is rejected.
This speeds up performance by 22% on amd64, 15% on i386, and 70% on armv7.
os: FreeBSD
arch: amd64
cpu: Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz
│ benchmark.out │
│ sec/op │
Arc4random_uniform 56.53n ± 0%
Fast_uniform 44.00n ± 0%
geomean 49.87n
Reviewed by: cem
Approved by: emaste
Differential Revision: https://reviews.freebsd.org/D47659
It is needed for SSP support.
Reported by: netchild, Shawn Webb
Fixes: 62dab3d016 ("getentropy: Remove fallback code")
Sponsored by: The FreeBSD Foundation
Our implementation currently diverges from POSIX 2024 in a couple of
ways, as now noted in the BUGS section.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47589
The return value is not required to be the difference between the
differing bytes, only less than zero, zero, or greater than zero.
Reviewed by: fuz
Event: Kitchener-Waterloo Hackathon 202406
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47683
We don't in general support running newer libc on an older kernel, but
have occasionally added support for specific functionality on a case-by-
case basis. When we do this it is usually done as an aid for developers
to get across a change that introduced new functionality, as for 64-bit
inodes and the introduction of the getrandom syscall.
The getrandom syscall was added in commit e9ac27430c ("Implement
getrandom(2) and getentropy(3)") in 2018, and exists in all supported
FreeBSD versions. The ECAPMODE special case applied to a few months
worth of kernel versions also in 2018 -- fixed as of commit ed1fa01ac4
("Regen after r337998.").
The backwards-compatibility support is no longer needed, so remove it.
Relnotes: Yes
Reviewed by: brooks, cem, delphij
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47636
getentropy has a comment about a special case to support kernels between
SVN revisions r331280 and r337999. Add the corresponding Git hashes so
there's a usable reference after Subversion infrastructure disappears.
Sponsored by: The FreeBSD Foundation
Noticed just a little too late, stub_null returns a `void *` but these
prototypes have no return value. As far as I know, all of our archs
will throw the return value in a caller-saved register and it'll simply
be ignored, but it's probably worth being more accurate.
Fixes: 83aafcdc88 ("libc, libthr: coordinate stubs for [...]")
If libthr isn't linked into the process, then we don't have any pthreads
to worry about and our stubs can just return success -- there are none
to suspend/resume.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D47350
Some sanitizers need to be able to use dl_iterate_phdr() after stopping
the rest of the process, but it's very hard to do so reliably as a
non-participant in the main logic of the program.
Introduce _dl_iterate_phdr_locked to bypass the locking that's normally
required for dl_iterate_phdr() and slap some scary warning on it. It
will remain undocumented and probably shouldn't be used for anything
else.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D47558
