Through fixes and improvements our ipfilter sources have diverged
enough to warrant move from contrib into sbin/ipf. Now that I'm
planning on implementing MSS clamping as in iptables it makes more
sense to move ipfilter to sbin.
This is the second of three commits of the ipfilter move.
Suggested by glebius on two occaions.
Suggested by and discussed with: glebius
Reviewed by: glebius, kp (for #network)
Differential Revision: https://reviews.freebsd.org/D33510
(cherry picked from commit 41edb306f0)
Through fixes and improvements our ipfilter sources have diverged
enough to warrant move from contrib into sys/netpil. Now that I'm
planning on implementing MSS clamping as in iptables it makes more
sense to move ipfilter to netpfil.
This is the first of three commits the ipfilter move.
Suggested by glebius on two occaions.
Suggested by and discussed with: glebius
Reviewed by: glebius, kp (for #network)
Differential Revision: https://reviews.freebsd.org/D33510
(cherry picked from commit 3b9b51fe46)
Vendor import GA release of unbound 1.14.0.
Merge commit '9b87431a326169e72d5ca55670cb3c95205aa350' into unbound/main
(cherry picked from commit 273016e836)
Since trie configuration remains invariant during each DXR instance
lifetime, instead of shifting and masking lookup keys by values
computed at runtime, compile upfront several dxr_lookup()
configurations with hardcoded shift / mask constants, and choose the
apropriate lookup function version after each DXR instance rebuild.
In synthetic tests this yields small but measurable (5-10%) lookup
throughput improvement, depending on FIB size and prefix patterns.
MFC after: 3 days
(cherry picked from commit e7abe200c2)
Per RFC2822 the maximum transmitted line length is "998 characters...
excluding the CRLF." In a file the maximum is 999 with the \n included.
Previously mail containing a line with exactly 999 characters would
bounce.
PR: 208261
Reported by: Helge Oldach
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 1a0dde338d)
This was prompted by the recent pkexec vulnerability (CVE-2021-4034).
This change is being made on general principle for setuid/setgid
binaries and is not in response to an actual issue.
Reviewed by: kevans, markj (both earlier)
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34087
(cherry picked from commit 1c91aedf25)
Disable the gdb packet run length encoding for 3-symbol repetitions.
While it is technically possible to encode them, they have no advantage
over sending the characters verbatim (the resulting length is the same)
and they result in sending non-printable \x1f character. The protocol
has been designed with the intent of avoiding non-printable characters
and therefore the run length encoding is biased to emit \x20 (a space)
with the minimal intended run length of 4.
While at it, simplify the logic by merging the different 'if' blocks
into a single while loop, and moving 'runlen == 0' check lower.
Reviewed by: cem, emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33686
(cherry picked from commit 028a372fe2)
- Check that catopen() succeeded before calling catclose(). musl will
crash in the latter if the catalogue descriptor is -1.
- Keep the message catalogue open for most of sort(1)'s actual
operation.
- Don't use catgets(3) to print error messages if catopen(3) had failed.
Reviewed by: arichardson, emaste
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 8d8b9b560a)
The new lock introduced in 5f5e32f1b3 needs to be initialised early so
that it can be safely destroyed if we error out.
Reported-by: syzbot+d76113e9a4ae0c0fcac2@syzkaller.appspotmail.com
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit e5ca5e801d)
The roundrobin pool stores its state in the rule, which could
potentially lead to invalid addresses being returned.
For example, thread A just executed PF_AINC(&rpool->counter) and
immediately afterwards thread B executes PF_ACPY(naddr, &rpool->counter)
(i.e. after the pf_match_addr() check of rpool->counter).
Lock the rpool with its own mutex to prevent these races. The
performance impact of this is expected to be low, as each rule has its
own lock, and the lock is also only relevant when state is being created
(so only for the initial packets of a connection, not for all traffic).
See also: https://redmine.pfsense.org/issues/12660
Reviewed by: glebius
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D33874
(cherry picked from commit 5f5e32f1b3)
In my understanding this is only needed to workaround lost interrupts.
I was thinking to remove it completely, but the comment about edge-
triggered interrupt may be true and needs deeper investigation. ~1Hz
should be often enough to handle the supposedly rare loss cases, but
rare enough to not appear in top. Add sysctl hw.atkbd.hz to tune it.
MFC after: 1 month
(cherry picked from commit 9e007a88d6)
These routines are used internally by GEOM to dispatch I/O requests to a
provider, typically for tasting or for updating GEOM class metadata
blocks.
These routines assumed that partial I/O did not occur without setting
BIO_ERROR, but this is possible in at least two cases:
- Some or all of the I/O range is beyond the provider's mediasize.
In this scenario g_io_check() truncates the bounds of the request
before it is handed to the target provider.
- A read from vnode-backed md(4) device returns EOF (the backing vnode
is allowed to be smaller than the device itself) or partial vnode I/O
occurs.
In these scenarios g_read_data() could return a partially uninitialized
buffer. Many consumers are not affected by the first case, since the
offsets used for provider metadata or tasting are relative to the
provider's mediasize, but in some cases metadata is read at fixed
offsets, such as when searching for a UFS superblock using the offsets
defined by SBLOCKSEARCH.
Thus, modify the routines to explicitly check for a non-zero residual
and return EIO in that case. Remove a related check from the
DIOCGDELETE ioctl handler, it is handled within g_delete_data() now.
Reviewed by: mav, imp, kib
Reported by: KMSAN
Sponsored by: The FreeBSD Foundation
(cherry picked from commit d91d2b513e)
Merge commit 6b0f35931a44 from llvm git (by Jennifer Yu):
Fix signal during the call to checkOpenMPLoop.
The root problem is a null pointer is accessed during the call to
checkOpenMPLoop, because loop up bound expr is an error expression
due to error diagnostic was emit early.
To fix this, in setLCDeclAndLB, setUB and setStep instead return false,
return true when LB, UB or Step contains Error, so that the checking is
stopped in checkOpenMPLoop.
Differential Revision: https://reviews.llvm.org/D107385
Note this only fixes the assertion reported in bug 261567; some other
tweaks for port dependencies are probably still required to make it
build to completion.
PR: 261567
MFC after: 3 days
(cherry picked from commit fdf2784101)
TCP_BBR:
- Fix a typo introducted in 1b90dfa5d2, which was reported by tuexen@
TCP_RACK:
- Correct two sysctl descriptions: s/corret/correct/
tcp_bbr(4): Also fix s/measurment/measurement/ in the man page
(cherry picked from commit b3df222eae)
The kern.elf64.aslr.pie_enable and kern.elf32.aslr.pie_enable sysctls
control the default setting for PIE binary address randomization, but
it is possible to enable or disable ASLR on a per-process basis. Use
procctl(2) to query whether ASLR is enabled.
(Note that with ASLR enabled but sysctl kern.elf64.aslr.pie_enable=0
a PIE binary will in effect have randomization disabled, and be
functional with msan. This is not intended as as a user-facing control
though. The user can use proccontrol(1) to disable aslr for the
process.)
Approved by: dim
Obtained from: LLVM 64de0064f315f57044294879d9ff4eacb454d45b
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33933
(cherry picked from commit 7cafe89f9c)
Before this change bufdaemon and bufspacedaemon threads used
kthread_shutdown() to stop activity on system shutdown. The problem is
that kthread_shutdown() has no idea about the wait channel and lock used
by specific thread to wake them up reliably. As result, up to 9 threads
could consume up to 9 seconds to shutdown for no good reason.
This change introduces specific shutdown functions, knowing how to
properly wake up specific threads, reducing wait for those threads on
shutdown/reboot from average 4 seconds to effectively zero.
MFC after: 2 weeks
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D33936
(cherry picked from commit b7ff445ffa)
Merge commit c7c84b90879f from llvm git (by Adrian Prantl):
[DwarfDebug] Refuse to emit DW_OP_LLVM_arg values wider than 64 bits
DwarfExpression::addUnsignedConstant(const APInt &Value) only supports
wider-than-64-bit values when it is used to emit a top-level DWARF
expression representing the location of a variable. Before this change,
it was possible to call addUnsignedConstant on >64 bit values within a
subexpression when substituting DW_OP_LLVM_arg values.
This can trigger an assertion failure (e.g. PR52584, PR52333) when it
happens in a fragment (DW_OP_LLVM_fragment) expression, as
addUnsignedConstant on >64 bit values splits the constant into separate
DW_OP_pieces, which modifies DwarfExpression::OffsetInBits.
This change papers over the assertion errors by bailing on overly wide
DW_OP_LLVM_arg values. A more comprehensive fix might be to be to split
wide values into pointer-sized fragments.
[0] https://github.com/llvm/llvm-project/blob/e71fa03/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp#L799-L805
Patch by Ricky Zhou!
Differential Revision: https://reviews.llvm.org/D115343
MFC after: 3 days
(cherry picked from commit 9738bc28ab)
We had a hardcoded limit of 1/128-th of physical memory that was further
subdivided between all CPUs as principal buffers are allocated on the
per-CPU basis. Actually, the buffers could use up 1/64-th of the
memmory because with the default switch policy there are two buffers per
CPU.
This commit allows to change that limit.
Note that the discussed limit is per dtrace command invocation.
The idea is to limit the size of a single malloc(9) call, not the total
memory size used by DTrace buffers.
(cherry picked from commit 7fdf0e8835)
Flip dwwdt_prevent_restart to false. What's the use of a watchdog if it
does not restart a hung system?
Add a knob for panic-ing on the first timeout, resetting on the second
one. This can be useful if interrupts can still work, otherwise a reset
recovers a system without any aid for debugging the hang.
The change also doubles the timeout that's programmed into the hardware.
The previous version of the code always had the interrupt on the first
timeout enabled, but it took no action on it. Only the second timeout
could be configured to reset the system. So, the hardware timeout was
set to a half of the user requested timeout. But now,we can take a
corrective action on the first timeout, so we use the user requested
timeout.
While here, define boolean sysctl-s as such.
(cherry picked from commit ee900888c4)
ASLR stack randomization will reappear in a forthcoming commit. Rather
than inserting a random gap into the stack mapping, the entire stack
mapping itself will be randomized in the same way that other mappings
are when ASLR is enabled.
No functional change intended, as the stack gap implementation is
currently disabled by default.
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 758d98debe)
The size of the ps_strings structure varies between ABIs, so this is
useful for computing the address of the ps_strings structure relative to
the top of the stack when stack address randomization is enabled.
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 3fc21fdd5f)
Rather than fetching the ps_strings address directly from a process'
sysentvec, use this macro. With stack address randomization the
ps_strings address is no longer fixed.
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 706f4a81a8)
For consistancy with the kernel linker script also use ${MACHINE} for
finding the kernel module linker script. As we currently only use this
for amd64 and i386 this is a no-op, but I'm planning on using this with
arm64 where ${MACHINE} != ${MACHINE_ARCH}.
Reviewed by: markj, kib, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33841
(cherry picked from commit 2754373f9a)
This was pointed out by markj in the review, but I missed it and forgot
to fix before pushing.
Reported by: markj
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 78c347d9f3)
