pf: attempt to handle overlapping group and interface names
pf assumes that network groups and network interfaces share a namespace
(that is, a name is unused, a group or an interface, never both a the
same time). Unfortunately this assumption was broken when interface
renaming was introduced.
Attempt to cope with this rather than panicking. Note that this is a
band-aid, not a full solution. The correct fix is for the network stack
to go back to enforcing a single namespace for groups and interfaces.
PR: 297220
Reported by: Robert Morris
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit d2a5b5a86a92e86f77737273ab4b2e99da63c21d)
pf: check if a group has a kif before dereferencing it
It's possible for interface groups to not have had a pfi_kkif assigned to
them, so before we pass that pointer to pfi_kkif_update() we must check if it's
actually set.
We've seen panics such as this, where we get an address update for an interface
that belongs to a group without associated pfi_kkif:
Tracing pid 12 tid 100034 td 0xfffff80100d2a000
kdb_enter() at kdb_enter+0x33/frame 0xfffffe0067eed340
panic() at panic+0x43/frame 0xfffffe0067eed3a0
trap_pfault() at trap_pfault+0x3c9/frame 0xfffffe0067eed3f0
calltrap() at calltrap+0x8/frame 0xfffffe0067eed3f0
--- trap 0xc, rip = 0xffffffff8102ebd5, rsp = 0xfffffe0067eed4c0, rbp = 0xfffffe0067eed500 ---
pfi_kkif_update() at pfi_kkif_update+0x15/frame 0xfffffe0067eed500
pfi_kkif_update() at pfi_kkif_update+0x1fc/frame 0xfffffe0067eed550
pfi_ifaddr_event() at pfi_ifaddr_event+0x82/frame 0xfffffe0067eed5a0
srcaddr_change_event() at srcaddr_change_event+0xa7/frame 0xfffffe0067eed610
[20 lines not shown]
pf: attempt to handle overlapping group and interface names
pf assumes that network groups and network interfaces share a namespace
(that is, a name is unused, a group or an interface, never both a the
same time). Unfortunately this assumption was broken when interface
renaming was introduced.
Attempt to cope with this rather than panicking. Note that this is a
band-aid, not a full solution. The correct fix is for the network stack
to go back to enforcing a single namespace for groups and interfaces.
PR: 297220
Reported by: Robert Morris
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit d2a5b5a86a92e86f77737273ab4b2e99da63c21d)
pf: check if a group has a kif before dereferencing it
It's possible for interface groups to not have had a pfi_kkif assigned to
them, so before we pass that pointer to pfi_kkif_update() we must check if it's
actually set.
We've seen panics such as this, where we get an address update for an interface
that belongs to a group without associated pfi_kkif:
Tracing pid 12 tid 100034 td 0xfffff80100d2a000
kdb_enter() at kdb_enter+0x33/frame 0xfffffe0067eed340
panic() at panic+0x43/frame 0xfffffe0067eed3a0
trap_pfault() at trap_pfault+0x3c9/frame 0xfffffe0067eed3f0
calltrap() at calltrap+0x8/frame 0xfffffe0067eed3f0
--- trap 0xc, rip = 0xffffffff8102ebd5, rsp = 0xfffffe0067eed4c0, rbp = 0xfffffe0067eed500 ---
pfi_kkif_update() at pfi_kkif_update+0x15/frame 0xfffffe0067eed500
pfi_kkif_update() at pfi_kkif_update+0x1fc/frame 0xfffffe0067eed550
pfi_ifaddr_event() at pfi_ifaddr_event+0x82/frame 0xfffffe0067eed5a0
srcaddr_change_event() at srcaddr_change_event+0xa7/frame 0xfffffe0067eed610
[20 lines not shown]
ipfw: rework 32-bit KBI detection
When we run 14.X jail on 15.X host system previous implementation could
not correctly detect 32-bit KBI due to jails can overwrite osreldate.
Add special handling for this case and use detection using
IP_FW_DUMP_SOPTCODES and IP_FW_XGET sockopts version.
Reported by: Vova Grebenschikov
Fixes: 704ec5e68c44
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D56616
wpa: Update to 2.12
Fixes and new features include:
hostapd:
* support RSN overriding (e.g., WPA3-Personal Compatibility Mode)
* EHT/IEEE 802.11be/Wi-Fi 7
- more complete support
- fix message validation issues that could enable DoS attacks
- fix group key rekeying
* enable SAE group 20 by default if SAE-EXT-KEY is enabled
* reject unexpected SAE password identifier to avoid DoS attack against
a specific STA
* mandate use of SAE H2E when using password identifiers
* assign VLAN when using SAE with PMKSA caching
* support SPP A-MSDU negotiation
* support IEEE 802.11bi functionality
- changing SAE password identifiers
- EPPKE
[50 lines not shown]
release/Makefile.gce: migrate gsutil usages to gcloud CLI
Google Cloud recommends migrating from gsutil to gcloud storage CLI.
Update gce-do-upload target to use `gcloud storage buckets create` and
`gcloud storage cp` instead of `gsutil mb` and `gsutil cp` commands.
PR: conf/297016
(cherry picked from commit 4174cc2f69d36105a735b19fadc9c18497b02b1a)
release/Makefile.gce: migrate gsutil usages to gcloud CLI
Google Cloud recommends migrating from gsutil to gcloud storage CLI.
Update gce-do-upload target to use `gcloud storage buckets create` and
`gcloud storage cp` instead of `gsutil mb` and `gsutil cp` commands.
PR: conf/297016
(cherry picked from commit 4174cc2f69d36105a735b19fadc9c18497b02b1a)
usb: xhci: allow up to 1s for SET_ADDRESS
Some devices take a little longer, and the spec doesn't really seem to
mandate a maximum. The common path in usbd_req_set_address() has
already been bumped to 1s and I have a headset (Logitech H390) that does
need a little bit longer, so let's match it in xhci.
Reviewed by: aokblast
Differential Revision: https://reviews.freebsd.org/D58717
usb: use SYSINIT(9) order instead of using non-existing subsystem
Found with: clang -Werror=assign-enum
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D58710
tests/netinet/socket_afinet: multibind second socket can be different
Allows to add tests to the table where the second socket doesn't take
address from the first. No functional change yet, all tests test the same
conditions.
Differential Revision: https://reviews.freebsd.org/D58087
tests/netinet/socket_afinet: unroll multibind test into a table
The test has 6 dimensions: address family, socket type, socket option on
the first socket, socket option on the second socket, is first socket
bound to specific address or wildcard and is the second socket priveleged
or not. Before the change 3 dimensions are implemented as 3 nested for()
loops, 2 dimensions are implemented as repetitions in the test body and
one dimension as two actions in the innermost loop.
I'm about to add one more dimension: whether the second socket is bound to
a specific address or wildcard instead of using first socket's
getsockopt(2) result. Also, there is a change under discussion that would
make SOCK_STREAM sockets behave different to SOCK_DGRAM. That would break
result consistency in the dimensions of socket type.
We expect that consistency in the dimension of address families shall
never break, thus this one remains a for() loop. The priveleged & non-
privileged bind(2) attempts also remain as two actions, but expected
results are in the table. The rest of dimensions are unrolled into a
[7 lines not shown]
inpcb: take a pcbinfo database out from single lock
Initialize all three hashes (exact, wild, load balance group) with a per-
bucket lock. Nothing changes for the packet lookup KPI - it still uses
SMR section for thread safety. But connect(2) and bind(2) operations gain
parallelism now.
The main concept is that as we lookup inpcb database for editing, we are
accumulating bucket locks necessary to accomplish the operation. Once all
lookups are complete and we are good to go, the inpcb is inserted (or
moved) and accumulated lock context is released.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D58131
tests/netinet/socket_afinet: add more tests to multibind
Add tests where first socket and second socket are bound to different
addresses, e.g. first specific and second wildcard and vice versa.
Mark success with SO_REUSEPORT on the second socket as a bug suspect.
Mark failure to bind to INADDR_ANY in presence of other UID's specific
bound socket to the same port as probably too strict.
Differential Revision: https://reviews.freebsd.org/D58088
taskqueue: Move wakeup() out of tq_mutex
taskqueue KPI require wakeup() to be called for each completed
task. With everything else there heavily optimized over the years,
even when doing nothing this wakeup()'s lock/unlock is significant.
Since no external taskqueue consumer can depend on the tq_mutex,
we can move the wakeup() out of it. It creates some complications
for internal waiters, but those should be much more rare, and can
be handled with separate locked wakeups on demand.
My tests of taskqueue-intensive ZFS RAIDZ writes on 64-core system
show performance improvement from this change ~4%, while same time
reducing CPU usage by several percent due to lower lock contention,
confirmed by CPU profiler.
