It is needed for SSP support.
Reported by: netchild, Shawn Webb
Fixes: 62dab3d016 ("getentropy: Remove fallback code")
Sponsored by: The FreeBSD Foundation
All the other libutil section 3 manpages document this, and although
it's heavily implied by the libutil.h header in the synopsis, we should
still be explicit and consistent.
PR: 280078
Reviewed by: jrtc27
MFC after: 1 week
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
Also remove some information from HISTORY that is no longer needed (and
could be confusing), now that _Fork is part of a standard.
Reported by: kib
Reviewed by: imp, kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47588
- loader.efi.8: use proper way of printing a backslash.
- usr.bin/gzip/gzip.1: contained a non-breaking space (in utf-8, 0xC2A0).
- lib/libpmc/pmc.*.3: remove two duplicate .Xr lines
Signed-off-by: Graham Percival <gperciva@tarsnap.com>
Reviewed by: mhorne, Alexander Ziaee <concussious.bugzilla@runbox.com>
MFC after: 3 days
Sponsored by: Tarsnap Backup Inc.
Pull Request: https://github.com/freebsd/freebsd-src/pull/1523
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
LSan wants to be able to register atfork handlers at __lsan_init time,
which can happen either at the first intercepted function call or in a
.preinit_array function. Both of these end up being very early in rtld
and executed with the bind lock held, which ends up causing problems
when we go to _libpthread_init().
Instead of requiring libpthread to be initialized, just insert the new
atfork handler straight into the list if it's not ready yet. The
critical section and locking should not be necessary if we're really
executing this early, as there won't be any threads to contend with.
Reviewed by: kib (earlier version), markj
Differential Revision: https://reviews.freebsd.org/D47349
Test that it generally functions, and also that registering multiple
times calls each handler in the order that it's documented to call them
in.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D47348
It was disabled by default in fe52b7f60e. We planned to (but did not)
remove the option before FreeBSD 14. Remove it now, for FreeBSD 15.
Relnotes: Yes
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31558
This deprecates the vm_create() and vm_open() interfaces and introduces
vm_openf(), which takes flags controlling its behaviour. In particular,
it will optionally create a VM first, and it can optionally reinitialize
an existing VM. This enables some simplification of existing consumers.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D47030
This does not change the rendered ascii at all.
Signed-off-by: Graham Percival <gperciva@tarsnap.com>
Reviewed by: mhorne, Alexander Ziaee <concussious.bugzilla@runbox.com>
MFC after: 3 days
Sponsored by: Tarsnap Backup Inc.
Pull Request: https://github.com/freebsd/freebsd-src/pull/1473
The alternative, more concise, translations for signal names, are left
intact under XXX in comments.
Noted by: emaste
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
- Invalid/non-existent/unable to use message catalog file should result in
ENOENT, and not in EFTYPE.
- Added detection of several cases of wrong file format due to length [*].
- Update man page.
* Based on the original patch from PR.
PR: 172805
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D47413
With this patch, it is possible to call fchmod() on a unix socket prior
to binding it to the filesystem namespace, so that the mode is set
atomically. Without this, one has to call chmod() after bind(), leaving
a window where threads can connect to the socket with the default mode.
After bind(), fchmod() reverts to failing with EINVAL.
This interface is copied from Linux.
The behaviour of fstat() is unmodified, i.e., it continues to return the
mode as set by soo_stat().
PR: 282393
Reviewed by: kib
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D47361
PDU data alignment (PDA) isn't necessarily a power of 2, just a
multiple of 4, so use roundup() instead of roundup2() to compute the
PDU data offset (PDO).
Sponsored by: Chelsio Communications
The caller supplied PDU data alignment (PDA) field from
nvmf_association_params is the caller's restriction on data alignment
(so affects received PDUs), and the PDA value received from the other
end is the remote end's restriction (so affects transmitted PDUs).
I had these backwards so that if the remote end advertised a PDA it
was used as the receive PDA instead of the transmit PDA.
Sponsored by: Chelsio Communications
Add machine-dependent parts for bhyve hypervisor to support
virtualization on RISC-V ISA.
No objection: markj
Sponsored by: UK Research and Innovation
Differential Revision: https://reviews.freebsd.org/D45512
xdr_void() should have type xdrproc_t, make it so.
PR: 280514
Reviewed by: brooks, dim
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D47340
These were reported by `mandoc -T lint ...` as warnings.
Signed-off-by: Graham Percival <gperciva@tarsnap.com>
Reviewed by: mhorne
MFC after: 3 days
Sponsored by: Tarsnap Backup Inc.
Pull Request: https://github.com/freebsd/freebsd-src/pull/1475
Using short temp filenames as /tmp/temp.XXXX (4 or 6 X) was probably ok
20 years ago, but not anymore. Best practice is to use 10 X. Given that our
users often copy & paste examples from our manual pages we need to
update the documentation.
PR: 261437
C23 (ISO/IEC 9899:2024) is not out yet, but will be shortly.
SVID1 is needed for the history section of memccpy(3).
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47284
This gives the function the ability to return only global symbols.
Sponsored by: Juniper Networks, Inc.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D47206
Unfortunately gcc 12's is not yet capable of compiling all of libc++
19's C++23 code, which results in errors similar to:
/usr/src/freebsd/src/contrib/llvm-project/libcxx/include/__algorithm/ranges_contains.h:41:3: error: 'static constexpr bool std::__1::ranges::__contains::__fn::operator()(_Iter, _Sent, const _Type&, _Proj)' must be a non-static member function
41 | operator()(_Iter __first, _Sent __last, const _Type& __value, _Proj __proj = {}) {
| ^~~~~~~~
/usr/src/freebsd/src/contrib/llvm-project/libcxx/include/__algorithm/ranges_contains.h:48:3: error: 'static constexpr bool std::__1::ranges::__contains::__fn::operator()(_Range&&, const _Type&, _Proj)' must be a non-static member function
48 | operator()(_Range&& __range, const _Type& __value, _Proj __proj = {}) {
| ^~~~~~~~
Until we can get rid of gcc 12, work around this by making it compile
libc++ in C++20 mode instead.
NOTE: The resulting libc++ library will not be C++23 compatible! Please
try to avoid shipping it, and use gcc 13 instead, if you must use gcc.
PR: 280562
MFC after: 3 days
libcrypt bundles the various hash functions it needs,
duplicating code that is also found in libmd.
Unbundle the hash functions and apply the same hack used
for libncursesw so static consumers link -lmd in addition
to -lcrypt.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D47062
Prevent a potentially sufficiently smart compiler from optimising
away our attempts to clear sensitive buffers.
A related change was discussed and rejected in D16059, but I don't
believe the reasoning there applies: the code clearly documents its
intent that the `memset` calls clear sensitive buffers so they don't
hang around. `explicit_bzero` is the appropriate function for this
purpose. A potential performance disadvantage seems less important:
the functions in crypt are specifically designed to be slow, so a
few extra calls to guarantee that sensitive buffers are cleared does
not significantly affect runtime.
See also: D16059
Reviewed by: delphij, kevans
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D47037
