In particular, we should provide a hint about mac.conf(5), since libjail
will just use the mac_prepare_type(3) API to provide a reasonably sane
interface for system administrators. Progammers wanting to fetch an
arbitrary MAC label would need to bypass libjail and use jail_get(2)
directly with their own prepared `struct mac`.
Differential Revision: https://reviews.freebsd.org/D54067
This adds the following hooks:
- mpo_prison_check_attach: check for subject capability to attach to
a given jail
- mpo_prison_check_create: check for subject capability to create a
jail with the given option set
- mpo_prison_check_get: check for subject capability to fetch the
given parameters for a jail
- mpo_prison_check_set: check for subject capability to set the
given parameters for a jail
- mpo_prison_check_remove: check for subject capability to remove the
jail
check_get wouldn't typically be a privileged operation, but is included
to give MAC policies a wider range of capabilities at a relatively low
cost. We also add two more for the purpose of label propagation:
- mpo_prison_created: surface the creation of a jail so that one can
do propagation to, e.g., the root vnode or any mounts
- mpo_prison_attached: attach an existing process to the jail so that
one can propagate the jail label to the process, as appropriate.
It is unclear if this is preferred vs. having separate associate entry
points for each type of object we might associate. That would split
these up like so:
- prison_created -> prison_associate_vnode
- prison_attached -> prison_associate_proc
Some sample policy ideas that should be feasible to implement with this
set of hooks, in case it's inspiring:
- mac_bomb: policy that allows a poudriere user to construct jails
without root privilege, given a restricted set of jail parameters.
Slap a warning label on it.
- mac_capsule: policy that realizes the capsule idea that I pitched[0]
on -jail@ to create jails that are effectively immutable once
sealed, using these hooks and a label.
Perhaps a silly idea, but a downstream could consider a scenario where
it can implement special jail enumeration using a MAC policy and a
cooperating application that specifies non-parameter options to filter
the results.
[0] https://lists.freebsd.org/archives/freebsd-jail/2025-September/000550.html
Reviewed by: olce (slightly earlier version)
Differential Revision: https://reviews.freebsd.org/D53954
This change extends pf(4) limiters so administrator
can specify action the rule executes when limit is
reached. By default when limit is reached the limiter
overrides action specified by rule to no-match.
If administrator wants to block packet instead then
rule with limiter should be changed to:
pass in from any to any state limiter test (block)
OK dlg@
Obtained from: OpenBSD, sashan <sashan@openbsd.org>, 04394254d9
Sponsored by: Rubicon Communications, LLC ("Netgate")
linked with the plural from other text, and
matches "Source Limiters. From Atanas Vladimirov.
Obtained from: OpenBSD, sthen <sthen@openbsd.org>, d4acfc5766
Sponsored by: Rubicon Communications, LLC ("Netgate")
both source and state limiters can provide constraints on the number
of states that a set of rules can create, and optionally the rate
at which they are created. state limiters have a single limit, but
source limiters apply limits against a source address (or network).
the source address entries are dynamically created and destroyed,
and are also limited.
this started out because i was struggling to understand the source and
state tracking options in pf.conf, and looking at the code made it
worse. it looked like some functionality was missing, and the code also
did some things that surprised me. taking a step back from it, even it
if did work, what is described doesn't work well outside very simple
environments.
the functionality i'm talking about is most of the stuff in the
Stateful Tracking Options section of pf.conf(4).
some of the problems are illustrated one of the simplest options:
the "max number" option that limits the number of states that a
rule is allowed to create:
- wiring limits up to rules is a problem because when you load a
new ruleset the limit is reset, allowing more states to be created
than you intended.
- a single "rule" in pf.conf can expand to multiple rules in the
kernel thanks to things like macro expansion for multiple ports.
"max 1000" on a line in pf.conf could end up being many times
that in effect.
- when a state limit on a rule is reached, the packet is dropped.
this makes it difficult to do other things with the packet, such a
redirect it to a tarpit or another server that replies with an
outage notices or such.
a state limiter solves these problems. the example from the pf.conf.5
change demonstrates this:
An example use case for a state limiter is to restrict the number of
connections allowed to a service that is accessible via multiple
protocols, e.g. a DNS server that can be accessed by both TCP and UDP on
port 53, DNS-over-TLS on TCP port 853, and DNS-over-HTTPS on TCP port 443
can be limited to 1000 concurrent connections:
state limiter "dns-server" id 1 limit 1000
pass in proto { tcp udp } to port domain state limiter "dns-server"
pass in proto tcp to port { 853 443 } state limiter "dns-server"
a single limit across all these protocols can't be implemented with
per rule state limits, and any limits that were applied are reset
if the ruleset is reloaded.
the existing source-track implementation appears to be incomplete,
i could only see code for "source-track global", but not "source-track
rule". source-track global is too heavy and unweildy a hammer, and
source-track rule would suffer the same issues around rule lifetimes
and expansions that the "max number" state tracking config above has.
a slightly expanded example from the pf.conf.5 change for source limiters:
An example use for a source limiter is the mitigation of denial of
service caused by the exhaustion of firewall resources by network or port
scans from outside the network. The states created by any one scanner
from any one source address can be limited to avoid impacting other
sources. Below, up to 10000 IPv4 hosts and IPv6 /64 networks from the
external network are each limited to a maximum of 1000 connections, and
are rate limited to creating 100 states over a 10 second interval:
source limiter "internet" id 1 entries 10000 \
limit 1000 rate 100/10 \
inet6 mask 64
block in on egress
pass in quick on egress source limiter "internet"
pass in on egress proto tcp probability 20% rdr-to $tarpit
the extra bit is if the source limiter doesn't have "space" for the
state, the rule doesn't match and you can fall through to tarpitting
20% of the tcp connections for fun.
i've been using this in anger in production for over 3 years now.
sashan@ has been poking me along (slowly) to get it in a good enough
shape for the tree for a long time. it's been one of those years.
bluhm@ says this doesnt break the regress tests.
ok sashan@
Obtained from: OpenBSD, dlg <dlg@openbsd.org>, 8463cae72e
Sponsored by: Rubicon Communications, LLC ("Netgate")
The STAGE_SETS and STAGE_TARGETS need to match
STAGE_DIR.
For each STAGE_SET we have STAGE_DIR.${STAGE_SET}
and create a target stage_files.${STAGE_SET},
the settings all need to be self consistent to work.
The apst_data tunable allows APST configuration to be adjusted
during controller initialization. It accepts an array of encoded
integers, each defining specific transition parameters.
Relnotes: YES
Signed-off-by: Alexey Sukhoguzov <sap@eseipi.net>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1444
APST is an optional NVMe power-saving feature that allows devices
to autonomously enter higher non-operational power states after a
certain amount of idle time, reducing the controller's overall power
consumption.
Signed-off-by: Alexey Sukhoguzov <sap@eseipi.net>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1444
This updates the smartpqi driver to Microchip's
latest available public release.
Reviewed by: imp
Approved by: imp
Sponsored by: Microchip Technology Inc.
Differential Revision: https://reviews.freebsd.org/D52507
Extend the FreeBSD OFED build framework to include the Broadcom bnxtre RDMA
provider library.
This change:
-Registers libbnxtre in src.libnames.mk so it is built and installed as part
of the OFED libraries.
-Adds bnxtre to the OFED pcap dependency set when MK_OFED is enabled.
-Declares proper dependency mappings for bnxtre (ibverbs, pthread).
-Introduces LIBBNXTREDIR for consistent object directory handling.
-Updates libibverbs and librdmacm build rules to link against libbnxtre,
enabling Broadcom RoCE device support at runtime.
-libbnxtre library uses below constructor to register with the libibverbs,
static attribute((constructor)) void bnxt_re_register_driver(void)
These updates ensure that applications using libibverbs and librdmacm can
discover and use Broadcom bnxt RDMA devices on FreeBSD.
Reviewed by: markj, ssaxena
Differential Revision: https://reviews.freebsd.org/D54368
MFC after: 3 days
The commit message has to be rewritten as it is not clear and lacks
some key details about the change.
This reverts commit 35dd53a9e1.
Reported by: jrtc27
Remote stray "-r" from the example of installing a toolchain
to alternate root.
Reviewed by: ivy
Differential Revision: https://reviews.freebsd.org/D54611
Freeing completed transmit mbufs can be time consuming (due to them
being cold in cache, and due to ext free routines taking locks),
especially when we batch tx completions. If we do this when holding
the tx ring mutex, this can cause lock contention on the tx ring mutex
when using iflib_simple_transmit.
To resolve this, this patch opportunistically copies completed mbuf
pointers into a new array (ifsd_m_defer) so they can be freed after
dropping the transmit mutex. The ifsd_m_defer array is
opportunistically used, and may be NULL. If its NULL, then we free
mbufs in the old way. The ifsd_m_defer array is atomically nulled
when a thread is using it, and atomically restored when the freeing
thread is done with it. The use of atomics here avoids
acquire/release of the tx lock to restore the array after freeing
mbufs.
Since we're no longer always freeing mbufs inline, peeking into them to see if a
transmit used TSO or not will cause a useless cache miss, as nothing
else in the mbuf is likely to be accessed soon. To avoid that cache
miss, we encode a TSO or not TSO flag in the lower bits of the mbuf
pointer stored in the ifsd_m array. Note that the IFLIB_NO_TSO flag
exists primarily for sanity/debugging.
iflib_completed_tx_reclaim() was refactored to break out
iflib_txq_can_reclaim() and _iflib_completed_tx_reclaim()
so the that the tx routine can call iflib_tx_credits_update()
just once, rather than twice.
Note that deferred mbuf freeing is not enabled by default, and can be
enabled using the dev.$DEV.$UNIT.iflib.tx_defer_mfree sysctl.
Differential Revision: https://reviews.freebsd.org/D54356
Sponsored by: Netflix
Reviewed by: markj, kbowling, ziaee
Document the new tx related sysctls I've added to iflib in the
last few months: tx_reclaim_ticks & tx_reclaim_thresh
Sponsored by: Netflix
Reviewed by: ziaee
Differential Revision: https://reviews.freebsd.org/D54564
MFC after: 3 days
Adjust document description, description section, and hardware section
to include Chelsio T7. Since this driver now supports many generations,
order reverse chronologically. Compare language to ice.4 and bnxt.4,
the other terabit ethernet drivers.
This list of HARDWARE is obtained from the Chelsio prouduct selector.
MFC after: 3 days (T7 support shipped with 15.0)
Discussed with: jhb, np
Differential Revision: https://reviews.freebsd.org/D54276
Document the supported PPC/POWER CPUTYPEs in the example make.conf.
Update bsd.cpu.mk to handle CPUs newer than POWER9, and remove
32-bit CPUTYPEs since we no longer support those at all.
Reviewed by: imp, jhibbits
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D54257
Similar to base 63d1c3c436, suppress -Wc++20-extensions for gcc.
Otherwise libc++ headers will lead to many -Werror warnings, due to our
use of -Wsystem-headers, which is not officially supported upstream.
MFC after: 3 days
Add a cross reference to smbmsg(8) which is useful for discovering local
devices and difficult to find otherwise.
PR: 247749
Reviewed by: pauamma@gundo.com
Differential Review: https://reviews.freebsd.org/D40839
Similar to the build epoch check, cache a list of source options in the
object tree, and force a clean build if the cached list does not match
the current list, after filtering out options which are known not to
affect the build (e.g. CLEAN, TESTS, WARNS).
This also adds a DEPEND_CLEANUP option (which defaults to yes unless
the CLEAN option is set) which can be used to skip depend-cleanup for
faster incremental builds.
MFC after: 1 week
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D52011
In commit faeaa25f56 MK_REPRODUCIBLE_PATHS was introduced, but some
ports that include bsd.debug.mk then started to fail with:
make: /usr/share/mk/bsd.debug.mk:19: Variable "MK_REPRODUCIBLE_PATHS" is undefined
in /usr/share/mk/bsd.lib.mk:525
in /wrkdirs/usr/ports/devel/libsysinfo/work/libsysinfo-0.0.3/Makefile:16
make: Fatal errors encountered -- cannot continue
This is because bsd.debug.mk includes bsd.opts.mk, not src.opts.mk. Move
the MK_REPRODUCIBLE_PATHS option to bsd.opts.mk to fix this.
Reviewed by: imp, emaste
Fixes: faeaa25f56
Extend the normal compat.linuxkpi.80211.IF.dump_stas sysctl by
queue information. This was helpful for debugging various issues,
like selecting the outbound queue, stopping queues for BAR and helped
finding multiple bugs.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
, related functions, and the EXTERROR_VERBOSE environment variable.
Reviewed by: emaste, mckusick
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54380
Otherwise, these lead to many -Werror warnings in libc++ headers, due to
our use of -Wsystem-headers, which is not officially supported upstream:
Suppress -Wc++20-extensions, due to:
/usr/include/c++/v1/__algorithm/simd_utils.h:96:50: error: explicit template parameter list for lambdas is a C++20 extension [-Werror,-Wc++20-extensions]
96 | inline constexpr size_t __simd_vector_size_v = []<bool _False = false>() -> size_t {
| ^
Suppress -Wc++23-lambda-attributes, due to:
/usr/include/c++/v1/__format/format_functions.h:462:32: error: an attribute specifier sequence in this position is a C++23 extension [-Werror,-Wc++23-lambda-attributes]
462 | if (bool __is_identity = [&] [[__gnu__::__pure__]] // Make sure the compiler knows this call can be eliminated
| ^
Suppress -Wnullability-completeness, due to:
/usr/include/c++/v1/string:1068:80: error: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Werror,-Wnullability-completeness]
1068 | _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 basic_string(const _CharT* __s, size_type __n) {
| ^
MFC after: 3 days
While here, add some white spaces to improve the readability of source
code.
Reviewed by: ziaee, #manpages
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54121
There are many environments that you do not want the paths to be
canonicalized. For example, if I always build a product from a specific
path in a jail that's dependent on the product version, I don't want
that to be sanitized to /usr/src because when I have profiling tools run
against multiple kernels, I can't do A/B testing and results processing
if everything points to /usr/src (sadly, the profiling tools cannot
remap back to the original like gdb can). Since we need both active at
the same time, symbloic link fallbacks don't work.
We do want the rest of the build to be reproducible, however. We'll get
the same binaries if we rebuild later since we always rebuild with the
same path.
Turn them both on for maximum reproduction for environments where that
cannot be guaranteed.
Sponsored by: Netflix
Input from: emaste, ivy
Differential Revision: https://reviews.freebsd.org/D52959
Kyle Evans