Add a priv_check for PRIV_PROC_MEM_WRITE which will be blocked
by mac_veriexec if being enforced, unless the process has a maclabel
to grant priv.
Reviewed by: stevek
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D46692
Define a pctrie iterator type. A pctrie iterator is a wrapper around a
pctrie that remembers a position in the trie where the last search
left off, and where a new search can resume. When the next search is
for an item very near in the trie to where the last search left off,
iter-based search is faster because instead of starting from the root,
the search usually only has to back up one or two steps up the
root-to-last-search path to find the branch that leads to the new
search target.
Every kind of lookup (plain, lookup_ge, lookup_le) that can begin with
the trie root can begin with an iterator instead. An iterator can also
do a relative search ("look for the item 4 greater than the last item
I found") because it remembers where that last search ended. It can
also search within limits ("look for the item bigger than this one,
but it has to be less than 100"), which can save time when the next
item beyond the limits and that is known before we actually know what
that item it is. An iterator can also be used to remove an item that
has already been found, without having to search for it again.
Iterators are vulnerable to unsynchronized data changes. If the
iterator is created with a lock held, and that lock is released and
acquired again, there's no guarantee that the iterator path remains
valid.
Reviewed by: markj
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D45627
This reverts commit f08247fd88.
This assertion is triggered by
ktls_test:ktls_transmit_aes128_cbc_1_0_sha1_control. Remove the assertion until
we fully understand why.
Sponsored by: Rubicon Communications, LLC ("Netgate")
m_copyback() modifies the mbuf, so it must be a writable mbuf.
Reviewed by: glebius
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D46627
The only supported 32-bit Arm architecture is Armv7. Remove old checks
for earlier architecture revisions.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45957
This is a feature which allows one to splice two TCP sockets together
such that data which arrives on one socket is automatically pushed into
the send buffer of the spliced socket. This can be used to make TCP
proxying more efficient as it eliminates the need to copy data into and
out of userspace.
The interface is copied from OpenBSD, and this implementation aims to be
compatible. Splicing is enabled by setting the SO_SPLICE socket option.
When spliced, data that arrives on the receive buffer is automatically
forwarded to the other socket. In particular, splicing is a
unidirectional operation; to splice a socket pair in both directions,
SO_SPLICE needs to be applied to both sockets. More concretely, when
setting the option one passes the following struct:
struct splice {
int fd;
off_t max;
struct timveval idle;
};
where "fd" refers to the socket to which the first socket is to be
spliced, and two setsockopt(SO_SPLICE) calls are required to set up a
bi-directional splice.
select(), poll() and kevent() do not return when data arrives in the
receive buffer of a spliced socket, as such data is expected to be
removed automatically once space is available in the corresponding send
buffer. Userspace can perform I/O on spliced sockets, but it will be
unpredictably interleaved with splice I/O.
A splice can be configured to unsplice once a certain number of bytes
have been transmitted, or after a given time period. Once unspliced,
the socket behaves normally from userspace's perspective. The number of
bytes transmitted via the splice can be retrieved using
getsockopt(SO_SPLICE); this works after unsplicing as well, up until the
socket is closed or spliced again. Userspace can also manually trigger
unsplicing by splicing to -1.
Splicing work is handled by dedicated threads, similar to KTLS. A
worker thread is assigned at splice creation time. At some point it
would be nice to have a direct dispatch mode, wherein the thread which
places data into a receive buffer is also responsible for pushing it
into the sink, but this requires tighter integration with the protocol
stack in order to avoid reentrancy problems.
Currently, sowakeup() and related functions will signal the worker
thread assigned to a spliced socket. so_splice_xfer() does the hard
work of moving data between socket buffers.
Co-authored by: gallatin
Reviewed by: brooks (interface bits)
MFC after: 3 months
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D46411
- Make less ambiguous;
- extend to provide more context for post-mortem.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D43776
MFC after: 2 weeks
For rangeset-next search, use exact search rather than greater-than search.
Move a bit of the testing logic from the pmap code to the common rangeset code.
Reviewed by: kib (previous version)
Tested by: pho (previous version)
Differential Revision: https://reviews.freebsd.org/D46314
The struct timespec tv_sec member is of type time_t. Make sure that all
variables related to this member are of the type time_t. This is important for
targets where long is a 32-bit type and time_t a 64-bit type.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1373
For example, printf("%+i", 1) prints "+1". However, kvprintf() did
print just "1" for this example. According to PRINTF(3):
A sign must always be placed before a number produced by a signed
conversion.
For "%+r" radix conversions, keep the "+" handling as it is, since this
is a non-standard conversion. For "%+p" pointer conversions, continue
to ignore the sign modifier to be in line with libc.
This change allows to support the ' conversion modifier in the future.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1310
Switch to unsigned arithmetic to handle overflow not relying on -fwrap,
and specially treat the case of length == 0 from posix_fadvise() which
passes OFF_MAX as the end to VOP. There, roundup() overflows and -fwrap
causes bend and endn become negative. Using uintmax_t gives the place
for roundup() to not wrap.
Also remove locals with single use, and move calculations out from under
bo lock.
Reported by: tmunro
Reviewed by: markj, tmunro
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D46518
'ushm_refcnt' is unsigned. Don't leave the impression it isn't.
No functional change (intended).
Reviewed by: kib
Approved by: emaste (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46126
This hardens against provoked use-after-free occurences should there be
reference counting leaks in the future (which is currently not the
case).
At the deepest level, umtx_shm_find_reg_unlocked() now returns EOVERFLOW
when it cannot grant an additional reference to the registry object, and
so will umtx_shm_find_reg(). umtx_shm_create_reg() will fail if calling
umtx_shm_find_reg() returns EOVERFLOW (meaning a SHM object for the
passed key already exists, but we can't acquire another reference on
it), avoiding the creation of a duplicate registry entry for a given key
(this wouldn't pose problem for the rest of the code in its current
form, but is expressly avoided for intelligibility and hardening
purposes).
Since umtx_shm_find_reg*(), and consequently the whole _umtx_op() system
call, can only return EOVERFLOW on such a bug manifesting, we don't
document that return value.
Reviewed by: kib, emaste
Approved by: emaste (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46126
umtx_shm_unref_reg_locked() would unconditionally drop the "registry"
reference, tied to USHMF_LINKED.
This is not a problem for caller umtx_shm_object_terminated(), which
operates under the 'umtx_shm_lock' lock end-to-end, but it is for
indirect caller umtx_shm(), which drops the lock between
umtx_shm_find_reg() and the call to umtx_shm_unref_reg(true) that
deregisters the umtx shared region (from 'umtx_shm_registry';
umtx_shm_find_reg() only finds registered shared mutexes).
Thus, two concurrent user-space callers of _umtx_op() with UMTX_OP_SHM
and flags UMTX_SHM_DESTROY, both progressing past umtx_shm_find_reg()
but before umtx_shm_unref_reg(true), would then decrease twice the
reference count for the single reference standing for the shared mutex's
registration.
Reported by: Synacktiv
Reviewed by: kib
Approved by: emaste (mentor)
Security: FreeBSD-SA-24:14.umtx
Security: CVE-2024-43102
Security: CAP-01
Sponsored by: The Alpha-Omega Project
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46126
...into the only USHMF_LINKED, as they are always set or unset together.
This is both to stop giving the impression that they can be set/unset
independently, which they can't with the current code, and to make it
clearer that an upcoming reference counting fix is correct.
Reviewed by: kib
Approved by: emaste (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46126
Those variables are not going to be changed at runtime. Make them const
to avoid potential overwriting. This will also help spotting accidental
global variables shadowing, since the variable's name such as `version`
is short and commonly used.
This change was inspired by reviewing khng's work D44760.
No functional change intended.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D45227
This should reduce the frequency of smr_synchronize() calls, that
otherwise occur on almost each rangelock unlock.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D46482
Cheat mode is incompatible with code which locks multiple ranges in the
same vnode, with at least one range being write-locked. This can arise
in kern_copy_file_range(). Until that's handled somehow, avoid the
problem to make the fusefs tests stable.
PR: 281073
Fixes: 9ef425e560 ("rangelocks: add fast cheating mode")
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D46457
A rangelock entry covers the range [start, end), so entries e1 and e2
with e1->end == e2->start do not overlap.
PR: 281073
Fixes: 5badbeeaf0 ("Re-implement rangelocks part 2")
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D46458
The usual way of handling process exit exit in capsicum(4) mode is
by using process descriptors (pdfork(2)) instead of the traditional
fork(2)/wait4(2) API. But most apps hadn't been converted this way,
and many cannot because the wait is hidden behind a library APIs that
revolve around PID numbers and not descriptors; GLib's
g_spawn_check_wait_status(3) is one example.
Thus, provide backwards compatibility by allowing the wait(2) family
of functions in Capsicum mode, except for child processes created by
pdfork(2).
Reviewed by: brooks, oshogbo
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D44372
It is defined as const char[] in config.c which is auto generated by
usr.sbin/config/kernconf.tmpl .
While here prefer macro SYSCTL_CONST_STRING to avoid casting.
MFC after: 1 week
There is no need to hold the sockbuf lock while checking uio_resid.
No functional change intended.
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
