This extends the strcspn() unit tests to catch mistakes in the
implementation that only appear when a mismatch occurs in a certain
position of the string against a certain position of the set.
See also: 52d4a4d4e0
Sponsored by: The FreeBSD Foundation
Approved by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D41821
When memcmp(a, b, len) (or equally, bcmp) is called with a phony length
such that a + len < a, the code would malfunction and not compare the
two buffers correctly. While such arguments are illegal (buffers do not
wrap around the end of the address space), it is neverthless conceivable
that people try things like memcmp(a, b, SIZE_MAX) to compare a and b
until the first mismatch, in the knowledge that such a mismatch exists,
expecting memcmp() to stop comparing somewhere around the mismatch.
While memcmp() is usually written to confirm to this assumption, no
version of ISO/IEC 9899 guarantees this behaviour (in contrast to
memchr() for which it is).
Neverthless it appears sensible to at least not grossly misbehave on
phony lengths. This change hardens memcmp() against this case by
comparing at least until the end of the address space if a + len
overflows a 64 bit integer.
Sponsored by: The FreeBSD Foundation
Approved by: mjg (blanket, via IRC)
See also: b2618b651b
MFC after: 1 week
Abstract out the details of the FreeBSD build into a $TINFO_OBJDIR that
external builds can override if they orchestrate the build a bit
differently and have a different objdir layout as a result. This makes
the ncurses build a little bit more flexible without requiring weird
backflips.
Reviewed by: bapt, sjg
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D41834
Headers from src/include were in the runtime-dev package but
subdirectories of src/include ended up in utilities-dev by default.
Neither package is a good choice - the headers in src/include are not
useful without the libraries contained in clibs-dev.
This moves the standard C headers to clibs-dev (C++ headers are already
in this package). While working on this, I found that various clang
libraries and headers were also bundled into utilities-dev by default
so these are also moved to clang-dev.
I also added a FreeBSD-build-essential meta package to make it simple to
install all the toolchain parts.
PR: 254173
Reviewed byb: manu
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41815
Ideally we should be testing __FreeBSD_version (1400079) and/or
BOOTSTRAPPING from an older version, but restore compatibility to
older FreeBSD versions and macOS while we find out a better way to
fix it.
When a string is matched against a set of 17--32 characters, each chunk
of the string is matched first against the first 16 characters of the
set and then against the remaining characters. We also check at the
same time if the string has a nul byte in the current chunk, terminating
the search if it does.
Due to misconceived logic, the order of checks was "first half of set,
nul byte, second half of set", meaning that a match with the second half
of the set was ignored when the string ended in the same 16 bytes.
Reverse the order of checks to fix this problem.
Sponsored by: The FreeBSD Foundation
Approved by: mjg (blanket, via IRC)
MFC after: 1 week
MFC to: stable/14
When memchr(buf, c, len) is called with a phony len (say, SIZE_MAX),
buf + len overflows and we have buf + len < buf. This confuses the
implementation and makes it return incorrect results. Neverthless we
must support this case as memchr() is guaranteed to work even with
phony buffer lengths, as long as a match is found before the buffer
actually ends.
Sponsored by: The FreeBSD Foundation
Reported by: yuri, des
Tested by: des
Approved by: mjg (blanket, via IRC)
MFC after: 1 week
MFC to: stable/14
PR: 273652
Now that we have an optimised memchr(3), we can use it to implement
strnlen(3) with better perofrmance.
Sponsored by: The FreeBSD Foundation
Approved by: mjg
MFC after: 1 week
MFC to: stable/14
Differential Revision: https://reviews.freebsd.org/D41598
This is conceptually similar to strchr(3), but there are
slight changes to account for the buffer having an explicit
buffer length.
Sponsored by: The FreeBSD Foundation
Approved by: mjg
MFC after: 1 week
MFC to: stable/14
Differential Revision: https://reviews.freebsd.org/D41598
This is conceptually very similar to the strcspn(3) implementations
from D41557, but we can't do the fast paths the same way.
Sponsored by: The FreeBSD Foundation
Approved by: mjg
MFC after: 1 week
MFC to: stable/14
Differential Revision: https://reviews.freebsd.org/D41567
To cover the new optimised amd64 strspn(3) SIMD implementation, extend
the previously written strcspn(3) unit test to also cover strspn(3).
Sponsored by: The FreeBSD Foundation
Approved by: mjg
MFC after: 1 week
MFC to: stable/14
Differential Revision: https://reviews.freebsd.org/D41567
We currently use the NetBSD test suite to cover strcspn(3). It only
contains a very rudimentary test of this function. This all new set
of unit tests for the FreeBSD test suite should cover many more edge
cases relating to alignment issues.
Sponsored by: The FreeBSD Foundation
Approved by: mjg
MFC after: 1 week
MFC to: stable/14
Differential Revision: https://reviews.freebsd.org/D41557
This changeset adds both a scalar and an x86-64-v2 implementation
of the strcspn(3) function to libc. A baseline implementation does not
appear to be feasible given the requirements of the function.
The scalar implementation is similar to the generic libc implementation,
but expands the bit set into a byte set to reduce latency, improving
performance. This approach could probably be backported to the generic
C version to benefit other platforms.
The x86-64-v2 implementation is built around the infamous pcmpistri
instruction. An alternative implementation based on the Muła/Langdale
algorithm [1] was prototyped, but performed worse than the pcmpistri
approach except for sets of more than 16 characters with long input
strings.
All implementations provide special cases for the empty set (reduces to
strlen as well as single-character sets (reduces to strchr). The
x86-64-v2 kernel falls back to the scalar implementation for sets of
more than 32 characters. This limit could be raised by additional
multiples of 16 through the use of additional pcmpistri code paths, but
I consider this case to be too rare to be of importance.
[1]: http://0x80.pl/articles/simd-byte-lookup.html
Sponsored by: The FreeBSD Foundation
Approved by: mjg
MFC after: 1 week
MFC to: stable/14
Differential Revision: https://reviews.freebsd.org/D41557
This adds test cases for %wN and %wfN to the printf(3) and scanf(3) tests.
While here, fix a few nits in the N2630 test cases.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D41743
This adds specific width length modifiers in the form of wN and wfN (where N is 8, 16, 32, or 64) which allow printing intN_t and int_fastN_t without resorting to casts or PRI macros.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D41725
LIBCSRCDIR is defined in bsd.libnames.mk, which is read in later in the
Makefile than the line:
.if exists(${LIBCSRCDIR}/${MACHINE_ARCH})
so we test to see if /${MARCHIN_ARCH} exists which it usually doesn't
(but did for me since I mounted 13.2R SD image there). Move to defining
our own LIBC_SRCTOP in terms of SRCTOP to treat these uniformily.
Sponsored by: Netflix
Reviewed by: sjg
Differential Revision: https://reviews.freebsd.org/D41661
With the new simd-dispatch framework documented in simd(7),
add cross-references to the new man pages to appropriate places.
Sponsored by: The FreeBSD Foundation
Approved by: emaste
MFC to: stable/14
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D41697
[builtins][AArch64] Implement _sync out-of-line atomics
Whilst Clang does not use these, recent GCC does, and so on systems such
as FreeBSD that wish to use compiler-rt as the system runtime library
but also wish to support building programs with GCC these interfaces are
needed.
This is a light adaptation of the code committed to GCC by Sebastian Pop
<spop@amazon.com>, relicensed with permission for use in compiler-rt.
Fixes https://github.com/llvm/llvm-project/issues/63483
Reviewed By: sebpop, MaskRay
Differential Revision: https://reviews.llvm.org/D158536
Reviewed by: dim
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41716
Background:
The pm_ev field of struct pmc_op_pmcallocate and struct pmc
traditionally contains the index of the chosen event, corresponding to
the __PMC_EVENTS array in pmc_events.h. This is a static list of events,
maintained by FreeBSD.
In the usual case, libpmc translates the user supplied event name
(string) into the pm_ev index, which is passed as an argument to the
allocation syscall. On the kernel side, the allocation method for the
relevant hwpmc class translates the given index into the event code that
will be written to an event selection register.
In 2018, a new source of performance event definitions was introduced:
the pmu-events json files, which are maintained by the Linux kernel. The
result was better coverage for newer Intel processors with a reduced
maintenance burden for libpmc/hwpmc. Intel and AMD CPUs were
unconditionally switched to allocate events from pmu-events instead of
the traditional scheme (959826ca1b, 81eb4dcf9e).
Under the pmu-events scheme, the pm_ev field contains an index
corresponding to the selected event from the pmu-events table, something
which the kernel has no knowledge of. The configuration for the
performance counting registers is instead passed via class-dependent
fields (struct pmc_md_op_pmcallocate).
In 2021 I changed the allocation logic so that it would attempt to
pull from the pmu-events table first, and fall-back to the traditional
method (dfb4fb4116). Later, pmu-events support for arm64 and power8
CPUs was added (28dd6730a5 and b48a2770d4).
The problem that remains is that the pm_ev field is overloaded, without
a definitive way to determine whether the event allocation came from the
pmu-events table or FreeBSD's statically-defined PMC events. This
resulted in a recent fix, 21f7397a61.
Change:
To disambiguate these two supported but separate use-cases, add a new
flag, PMC_F_EV_PMU, to be set as part of the allocation, indicating that
the event index came from pmu-events.
This is useful in two ways:
1. On the kernel side, we can validate the syscall arguments better.
Some classes support only the traditional event scheme (e.g.
hwpmc_armv7), while others support only the pmu-events method (e.g.
hwpmc_core for Intel). We can now check for this. The hwpmc_arm64
class supports both methods, so the new flag supersedes the existing
MD flag, PM_MD_EVENT_RAW.
2. The flag will be tracked in struct pmc for the duration of its
lifetime, meaning it is communicated back to userspace. This allows
libpmc to perform the reverse index-to-event-name translation
without speculating about the meaning of the index value.
Adding the flag is a backwards-incompatible ABI change. We recently
bumped the major version of the hwpmc module, so this breakage is
acceptable.
Reviewed by: jkoshy
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40753
Have it call the platform-dependent version. For better layering, move
the reset logic inside the new function. This is mainly to facilitate an
upcoming change.
Reviewed by: jkoshy
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40752
While here, also update a mention of ANSI C.
Sponsored by: Klara, Inc.
Reviewed by: kevans, markj
Differential Revision: https://reviews.freebsd.org/D41686
This will enable alternative mallocs to be included in the tree and
selected by setting LIBC_MALLOC. As there is only one today (jemalloc)
this option does nothing, but we expect to add other implementations
in the future. This will also reduce diffs to CheriBSD.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D41660
strverscmp(3) and versionsort(3) where first released in 13.2
PR: 273401
Reviewed by: kib
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D41617
The new nvlist-based status call allows us to easily add new counters.
However, the libpfctl interface defines a TAILQ, so it's not quite
trivial to find the counter consumers are interested in.
Provide convenience functions to access the counters.
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D41649
These aren't really needed, since TACACS+ does not support enumeration, but providing placeholders keeps nsdispatch() from complaining that they're missing.
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D41658
src.opts.mk includes bsd.own.mk, which sets SHLIBDIR, so having this
line after it does nothing. Hoist it like other libraries so it takes
effect.
Reported by: vishwin
Fixes: 2964804ef9 ("librt: unbreak LIB32 build")
This adds formatted input/output of binary integer numbers to the printf(), scanf(), and strtol() families, including their wide-character counterparts.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D41511
Clear cached_passphrase before generating a new key, otherwise the
operation nonsensically tries to reuse the old passphrase.
PR: 254966
Pull Request: https://github.com/freebsd/freebsd-src/pull/780
MFC after: 1 week
libzfs uses librt as a dependency. Following 315ee00fa9 systems with
a separate / and /usr will fail to load the libzfs.so library because
librt.so is not available due to the fact that /usr is not mounted yet.
Install librt in /lib making it available to libzfs.
Reported by: emaste, imp
Fixes: 315ee00fa9
Differential Revision: https://reviews.freebsd.org/D41612
When the buffer is immediately preceeded by the character we
are looking for and begins with one higher than that character,
and the buffer is misaligned, a match was errorneously detected
in the first character. Fix this by changing the way we prevent
matches before the buffer from being detected: instead of
removing the corresponding bit from the 0x80..80 mask, set the
LSB of bytes before the buffer after xoring with the character we
look for.
The bug only affects amd64 with ARCHLEVEL=scalar (cf. simd(7)).
The change comes at a 2% performance impact for short strings
if ARCHLEVEL is set to scalar. The default configuration is not
affected.
os: FreeBSD
arch: amd64
cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
│ strchrnul.scalar.0.out │ strchrnul.scalar.2.out │
│ sec/op │ sec/op vs base │
Short 57.89µ ± 2% 59.08µ ± 1% +2.07% (p=0.030 n=20)
Mid 19.24µ ± 0% 19.73µ ± 0% +2.53% (p=0.000 n=20)
Long 11.03µ ± 0% 11.03µ ± 0% ~ (p=0.547 n=20)
geomean 23.07µ 23.43µ +1.53%
│ strchrnul.scalar.0.out │ strchrnul.scalar.2.out │
│ B/s │ B/s vs base │
Short 2.011Gi ± 2% 1.970Gi ± 1% -2.02% (p=0.030 n=20)
Mid 6.049Gi ± 0% 5.900Gi ± 0% -2.47% (p=0.000 n=20)
Long 10.56Gi ± 0% 10.56Gi ± 0% ~ (p=0.547 n=20)
geomean 5.045Gi 4.969Gi -1.50%
MFC to: stable/14
MFC after: 3 days
Approved by: mjg (blanket, via IRC)
Sponsored by: The FreeBSD Foundation
This module allows controlled privilege escallation via mac labels
securely associated with a process via mac_veriexec.
There are over 700 PRIV_* but we can compress many of them into
a single GBL_* thus constraining the size of gbl labels.
The goal is to allow a daemon to run as an unprivileged process while
still being able a set of privileged operations needed.
We add APIs to libveriexec so that userland processes can check labels
and an exec_script API that allows a suitably labeled process to run
something like a python interpreter directly if necessary;
overcomming the 'indirect' flag applied to the interpreter.
Add -l option to sbin/veriexec to report labels.
Reviewed by: stevek
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D41431
