UPDATING: Fix entry for getgroups(2)/setgroups(2)
Fix a typo, grammar, and generally rephrase for better clarity.
Fixes: 3463f02706db ("UPDATING: add an entry for [gs]etgroups")
MFC after: 1 day
MFC to: stable/15
Sponsored by: The FreeBSD Foundation
(cherry picked from commit b7cff2a8c47eb09968430e53cab8b05cf8897d3f)
nvme.4: Canonicalize LOADER TUNABLES
Improve style for consistency with the rest of the manual
and add the tunables to the search database.
MFC after: 3 days
Reviewed by: seuros
Differential Revision: https://reviews.freebsd.org/D59165
xen.4: Canonicalize SYNOPSIS
Move the prose about support that was here to the second sentence of
DESCRIPTION. Remove the note about i386 since i386 is dead in 15.0.
The rest of the manual still contains details about i386 and could
use some TLC by a Xen user.
MFC after: 3 days (to 15 only)
TI AM335x: update clock names
Due to upstream has changed to use clock-output-names we need
to update the names in our code aswell.
Approved by: imp(earlier revison), manu(mentor)
Tested by: Rick Richard
Differential revision: https://reviews.freebsd.org/D46713
TI AM335x: Remove clock_common.*
These helper function will not be needed anymore
because the way that clocks are parsed from the DTS is reworked.
Approved by: imp, manu(mentor)
Tested by: Rick Richard
Differential revision: https://reviews.freebsd.org/D46712
nullfs: Allow VSOCK to be mounted on top of another VSOCK
In the world of containers, mounting a unix(4) socket is a common
practice to allow communication between processes within containers.
For example, both Podman and Docker can expose a unix(4) socket,
and that same unix(4) socket can be mounted as a file accessible
to a process inside a container, allowing that application to control
Podman or Docker. Another example is PHP-FPM with NGINX, where,
instead of using TCP/IP for communication between containers, a
unix(4) socket is sufficient.
However, nullfs(4) and all related components do not allow mounting
a VSOCK on top of another. The current workaround involves creating
the socket in a directory and mounting that directory. This is an
option, though it does not provide a good user experience compared
to directly mounting a VSOCK on top of another, since the application
that creates the socket may create other sockets in that directory,
and the user may not wish to share them, or, worse yet, applications
that create unix(4) sockets may not provide any authentication at
[9 lines not shown]
pf: Send syncookies from the receiving thread
pf sends outbound packets by offloading them to a single per-vnet SWI handler
through the `V_pf_sendqueue` mbuf queue. A large DDoS attack may overwhelm
that per-vnet queue with syncookie packets and cause contention in the SWI
handler that negatively affects other pf operations.
Fix this by sending the initial syncookie challenge from the context
of the receiving thread. This avoids the syncookie-induced contention on
the `pf_intr` mbuf queue.
Sponsored by: Klara, Inc.
Sponsored by: Entersekt
MFC after: 3 weeks
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D59068
sys/tests/kern/pdopenpid: pdopenpid(2) is allowed in cap mode
Adjust test to check for ECAPMODE using grandchild instead of child.
Childrens can be opened even in cap mode. Add test for the later.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58989
pdptrace(2): allow debugging in capability mode
The pdopenpid(2) syscall is allowed in capability mode. Add the chicken
switch security.bsd.ptrace_in_cap_mode, which disables it without
reboot, if needed.
The descriptor passed to pdptrace(2) must have the CAP_PTRACE
capability enabled. This capability is not enabled by default by
pdfork()/pdopenpid(), and the calls do not return a procdesc suitable
for debugging. The opening code must prepare for debugging in advance by
passing the PD_PTRACE_CAP flag to pdfork()/pdopenpid().
For ptrace(2), allow PT_CLEARSTEP and PT_GET_CHILDREN for the current
thread and process in cap mode as well.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58989
pdopenpid(2): allow in capability mode with restrictions
The pdopenpid() syscall is allowed to open processes which are either
direct children of the caller, or are debuggees already attached to the
calling process. This is reasonable because we could have controlled the
child on fork anyway.
The procdesc-less debuggee can legitimately appear due to ptrace
FOLLOW-FORK mode.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58989
kern: add p_canopen()
The function defines the policy for allowing to open a pid.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58989
tests/sys/kern/pdwait: adjust test for the addition of CAP_PTRACE
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58586
ptrace: split sys_ptrace()/freebsd32_ptrace()
The code to handle copyin and copyout of the structured parameters is
moved into the helpers.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58586
