Following up ziaee's pattern, and add andy's line.
I'm not sure whether the original commit bit creation date should be used,
and use commit bit re-activation date for now.
MFC after: 1 week
This used to be needed when interface renames were broadcast using the
ifnet_departure_event eventhandler, but since commit 349fcf079c
("net: add ifnet_rename_event EVENTHANDLER(9) for interface renaming"),
it has no purpose. Remove it.
Reviewed by: pouria, zlei
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D55171
When I removed the Realtek rtww8x firmware from base I missed to
add rtw88fw.4 to ObsoleteFiles.inc [1].
While adding this, also remove a leftover reference in rtw88.4.
Reported by: Herbert J. Skuhra (herbert gojira.at) [1]
Fixes: cf94672363
MFC after: 3 days
These manuals abused the name macro for every line of kernel cfg as well
as an example command to show the module name which was mixed in without
separation. This bugs the whatis database into thinking that `INET` and
`kldload` are names for this page, and violates best practice by mixing
commands and configuration in a continuous example.
Rewrite to use the kernel configuration macro, Cd, and show the module
name via an example configuration in rc.conf, according to the spec and
established practice. Do not bump the date because these markup errors
are not a content change.
MFC after: 3 days
The git-arc script was moved from devel/freebsd-git-devtools to
devel/freebsd-git-arc.
Reviewed by: ziaee
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55128
Now that we have angle bracket characters for all common display sizes,
sprinkle in the correct macros for the structures in this page. While
here, fix a mdoc typo, a linter warning, and switch a parenthetical to
a much smoother appositive.
MFC after: 3 days
Fixes: 7cd6da268a (vt.4: Style pass)
+ Mention relevance of this file in the vt manual screen.font entry
+ The vidfont manual is in section one, not eight
+ Remove leftover blank line from freebsd tag removal
MFC after: 3 days
Add capability VLAN_HWTAGGING to the epair interface and enable it by
default.
When sending a packet over a VLAN interface that uses an epair
interface, the flag M_VLANTAG and the ether_vtag (which contains the
VLAN ID and/or PCP) are set in the mbuf to inform the hardware that
the VLAN header has to be added. The sending epair end does not need
to actually add a VLAN header. It can just pass the mbuf with this
setting to the other epair end, which receives the packet. The
receiving epair end can just pass the mbuf with this setting to the
upper layer. Due to this setting, the upper layer believes that there
was a VLAN header that has been removed by the interface.
If the packet later leaves the host, the outgoing physical interface
can add the VLAN header in hardware if it supports VLAN_HWTAGGING.
If not, the implementation of Ethernet or bridge adds the VLAN header
in software.
Reviewed by: zlei, tuexen
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D52465
This breaks the riscv64 build; clearly the version we have in-tree is
not new enough to work. That or our build system needs tweaking. Either
way, we're not ready for this, and enabling it without testing was
misguided.
This reverts commit c59a47dc6c.
Previously it was enabled for all architectures except but RISC-V.
Upstream made significant progress on RISC-V support over the last
year[1], and although there's still some FreeBSD-specific work to do we
can start building it now.
[1] https://jonasdevlieghere.com/post/lldb-2025/
Sponsored by: The FreeBSD Foundation
These warnings were already marked with -Wno-error=, but they trigger
so many false positives in libc++ headers to be utterly useless for
C++ code, so disable them entirely for C++.
Reviewed by: imp, dim
Differential Revision: https://reviews.freebsd.org/D54867
Build fails with BHYVE_SNAPSHOT enabled on non-amd64,
so add it to BROKEN_OPTIONS for these arches.
PR: 292686
Reviewed by: emaste, markj
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54873
pf's divert-to action can be used to pass packets to a divert socket,
but divert.4 didn't mention this, only referencing ipfw. Try to make
the text a bit more general.
Reviewed by: igoro, kp, glebius
MFC after: 2 weeks
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D54848
When witness(4) detects lock order reversals (LORs), it prints
information about the stack trace which caused the LOR. If available,
it can also print information about the first stack trace which
established the other lock ordering. However, it only does this for
"simple" LORs where the two locks in question were directly locked
in the opposite order. When the lock order was established through
a more complex pattern of intermediate locks, WITNESS only prints
the stack trace where it detected the LOR.
This commit provides new functionality to provide more verbose
information about the lock chain(s) which established the lock
ordering. The new functionality can be disabled by setting the
debug.witness.trace sysctl/tunable to 1. The new functionality
is also available through the debug.witness.badstacks sysctl,
which has been modified to always show the more verbose
information.
Reviewed by: markj, glebius (previous version), kib (previous version)
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D54785
MFC after: 1 month
Add SPMC (system power management controller) driver as acpi_spmc. This
is the device which provides the LPI device D-state constraints and
allows for OSPM to send S0ix/modern standby entry/exit notifications.
This supports the original Intel DSM
(https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf,
untested), the AMD DSM (tested), and the Microsoft DSM (tested).
Before entry, acpi_spmc_check_constraints is called to notify of any
violated power constraints. This will use acpi_pwr_get_state to get
current device D-states when that gets added back.
Reviewed by: olce
Tested by: jkim, Oleksandr Kryvulia, Matthias Lanter
Approved by: olce
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48387
While here, wrap the line to 80 characters.
Reviewed by: jlduran
Fixes: c54534e602 ("capsicum.4: Add some more detail from the Capsicum paper")
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D54761
Add symbols found in the port but not in base. This requires replacing
a shared libkrb5profile.so with libkrb5profile.a (with -fPIC so it can
be used by shared libraries). We do this by making libkrb5profile
INTERNALLIB.
Base currently has libkrb5profile in a shared library. The patch moves
those functions to the various "consumer" libraries as the port does.
Symbols that should be in the other libraries are in libkrb5profile.so.
This is causing some ports issues.
PR: 291695
Reported by: michaelo, markj, Chris Inacio <inacio@andrew.cmu.edu>
Tested by: michaelo
Fixes: ae07a5805b
Reviewed by: michaelo (previous version)
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D54323
This patch adds the same functionality for the IPv4 header checksum
as was done erlier for the SCTP/TCP/UDP transport checksum.
When the IP implementation sends a packet, it does not compute the
corresponding checksum but defers that. It will determine whether the
network interface selected for the packet has the requested capability
and computes the checksum in software, if the selected network
interface does not have the requested capability.
Do this not only for packets being sent by the local IP stack, but
also when forwarding packets. Furthermore, when such packets are
delivered to a local IP stack, do not compute or validate the checksum,
since such packets have never been on the wire. This allows to support
checksum offloading also in the case of local virtual machines or
jails. Support for epair interfaces will be added in a separate commit.
Reviewed by: pouria, tuexen
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54455
The prison may also be considered part of the subject by way of its
ucred association, but I don't think this is significantly different
enough today than before recent work -- policies could have always
taken them into account, and some did (e.g., mac_bsdextended).
Reported by: olce
Reviewed by: olce, ziaee
Differential Revision: https://reviews.freebsd.org/D54748
pf(4) users who use limiters in current should update the rules
accordingly to reflect the change in default behavior. The existing
rule which reads as follows:
pass in from any to any state limiter test
needs to be changed to:
pass in from any to any state limiter test (no-match)
OK dlg@
Obtained from: OpenBSD, sashan <sashan@openbsd.org>, c600931321
Sponsored by: Rubicon Communications, LLC ("Netgate")
NO_FP_LIBC was added in 2004 to save space by disabling FP support in
*printf()/*scanf(). The size benefit is negligible on modern systems
and conflicts with assumptions made by current base utilities.
Remove the option and always build libc with floating-point support.
Reported by: Oskar Holmlund <eovholmlund at gmail com>
MFC after: 2 weeks
If the kernel is built without stack(9) (options STACK),
then the mentioned sysctl(8) kern.tty_info_kstacks will not be found.
MFC after: 3 days
Reviewed by: kib, ziaee
Differential Revision: https://reviews.freebsd.org/D54701
The bge interface is special with respect to transmit checksumi
offloading. In the default settings, an bge interface announces TXCSUM
capabilities, but only supports TCP/IPv4 and not UDP/IPv4 due to
limitations of some of the NICs. This results in problems when the bge
interface becomes a member of a bridge. Since currently only the
TXCSUM capabilities are synced when a member is added to a bridge and
not the protocol specific capabilities, this can result in a situation
where UDP packets are sent out using a bge interface without having a
correct checksum.
To mitigate this problem, initially don't announce TXCSUM capabilities,
when UDP transmit checksum is disabled. It is still possible to enable
TXCSUM capabilities via ifconfig.
PR: 291420
Reviewed by: Timo Voelker
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D54486
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
Pouria Mousavizadeh Tehrani