#
948f31d7 |
| 12-Aug-2022 |
Gleb Smirnoff <glebius@FreeBSD.org> |
netinet: do not broadcast PRC_REDIRECT_HOST on ICMP redirect
This is expensive and useless call. It has been useless since Alexander melifaro@ moved the forwarding table to nexthops with passive in
netinet: do not broadcast PRC_REDIRECT_HOST on ICMP redirect
This is expensive and useless call. It has been useless since Alexander melifaro@ moved the forwarding table to nexthops with passive invalidation. What happens now is that cached route in a inpcb would get invalidated on next ip_output().
These were the last users of pfctlinput(), so garbage collect it.
Reviewed by: melifaro Differential revision: https://reviews.freebsd.org/D36156
show more ...
|
#
82042465 |
| 20-Jul-2022 |
Kornel Dulęba <kd@FreeBSD.org> |
icmp6: Improve validation of PMTU
Currently we accept any pmtu between IPV6_MMTU(1280B) and the link mtu. In some network topologies could allow a bad actor to perform a DOS attack. Contrary to IPv4
icmp6: Improve validation of PMTU
Currently we accept any pmtu between IPV6_MMTU(1280B) and the link mtu. In some network topologies could allow a bad actor to perform a DOS attack. Contrary to IPv4 in IPv6 oversized packets are dropped, and a ICMP PACKET_TOO_BIG message is sent back to the sender. After receiving an ICMPv6 packet with pmtu bigger than the current one the victim will start sending frames that will be dropped a router with reduced MTU. Although it will eventually receive another message with correct pmtu, an attacker can still just inject their spoofed packets frequently enough to overwrite the correct value. This issue is described in detail in RFC8201, section 6. Fix this by checking the current pmtu, and accepting the new one only if it's smaller.
Approved by: mw(mentor) Reviewed by: tuexen MFC after: 1 week Sponsored by: Stormshield Obtained from: Semihalf Differential Revision: https://reviews.freebsd.org/D35871
show more ...
|
Revision tags: release/13.1.0 |
|
#
db0ac6de |
| 02-Dec-2021 |
Cy Schubert <cy@FreeBSD.org> |
Revert "wpa: Import wpa_supplicant/hostapd commit 14ab4a816"
This reverts commit 266f97b5e9a7958e365e78288616a459b40d924a, reversing changes made to a10253cffea84c0c980a36ba6776b00ed96c3e3b.
A mism
Revert "wpa: Import wpa_supplicant/hostapd commit 14ab4a816"
This reverts commit 266f97b5e9a7958e365e78288616a459b40d924a, reversing changes made to a10253cffea84c0c980a36ba6776b00ed96c3e3b.
A mismerge of a merge to catch up to main resulted in files being committed which should not have been.
show more ...
|
#
266f97b5 |
| 02-Dec-2021 |
Cy Schubert <cy@FreeBSD.org> |
wpa: Import wpa_supplicant/hostapd commit 14ab4a816
This is the November update to vendor/wpa committed upstream 2021-11-26.
MFC after: 1 month
|
#
de2d4784 |
| 02-Dec-2021 |
Gleb Smirnoff <glebius@FreeBSD.org> |
SMR protection for inpcbs
With introduction of epoch(9) synchronization to network stack the inpcb database became protected by the network epoch together with static network data (interfaces, addre
SMR protection for inpcbs
With introduction of epoch(9) synchronization to network stack the inpcb database became protected by the network epoch together with static network data (interfaces, addresses, etc). However, inpcb aren't static in nature, they are created and destroyed all the time, which creates some traffic on the epoch(9) garbage collector.
Fairly new feature of uma(9) - Safe Memory Reclamation allows to safely free memory in page-sized batches, with virtually zero overhead compared to uma_zfree(). However, unlike epoch(9), it puts stricter requirement on the access to the protected memory, needing the critical(9) section to access it. Details:
- The database is already build on CK lists, thanks to epoch(9). - For write access nothing is changed. - For a lookup in the database SMR section is now required. Once the desired inpcb is found we need to transition from SMR section to r/w lock on the inpcb itself, with a check that inpcb isn't yet freed. This requires some compexity, since SMR section itself is a critical(9) section. The complexity is hidden from KPI users in inp_smr_lock(). - For a inpcb list traversal (a pcblist sysctl, or broadcast notification) also a new KPI is provided, that hides internals of the database - inp_next(struct inp_iterator *).
Reviewed by: rrs Differential revision: https://reviews.freebsd.org/D33022
show more ...
|
Revision tags: release/12.3.0 |
|
#
c541bd36 |
| 21-Aug-2021 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
lltable: Add support for "child" LLEs holding encap for IPv4oIPv6 entries.
Currently we use pre-calculated headers inside LLE entries as prepend data for `if_output` functions. Using these headers
lltable: Add support for "child" LLEs holding encap for IPv4oIPv6 entries.
Currently we use pre-calculated headers inside LLE entries as prepend data for `if_output` functions. Using these headers allows saving some CPU cycles/memory accesses on the fast path.
However, this approach makes adding L2 header for IPv4 traffic with IPv6 nexthops more complex, as it is not possible to store multiple pre-calculated headers inside lle. Additionally, the solution space is limited by the fact that PCB caching saves LLEs in addition to the nexthop.
Thus, add support for creating special "child" LLEs for the purpose of holding custom family encaps and store mbufs pending resolution. To simplify handling of those LLEs, store them in a linked-list inside a "parent" (e.g. normal) LLE. Such LLEs are not visible when iterating LLE table. Their lifecycle is bound to the "parent" LLE - it is not possible to delete "child" when parent is alive. Furthermore, "child" LLEs are static (RTF_STATIC), avoding complex state machine used by the standard LLEs.
nd6_lookup() and nd6_resolve() now accepts an additional argument, family, allowing to return such child LLEs. This change uses `LLE_SF()` macro which packs family and flags in a single int field. This is done to simplify merging back to stable/. Once this code lands, most of the cases will be converted to use a dedicated `family` parameter.
Differential Revision: https://reviews.freebsd.org/D31379 MFC after: 2 weeks
show more ...
|
#
7045b160 |
| 28-Jul-2021 |
Roy Marples <roy@marples.name> |
socket: Implement SO_RERROR
SO_RERROR indicates that receive buffer overflows should be handled as errors. Historically receive buffer overflows have been ignored and programs could not tell if they
socket: Implement SO_RERROR
SO_RERROR indicates that receive buffer overflows should be handled as errors. Historically receive buffer overflows have been ignored and programs could not tell if they missed messages or messages had been truncated because of overflows. Since programs historically do not expect to get receive overflow errors, this behavior is not the default.
This is really really important for programs that use route(4) to keep in sync with the system. If we loose a message then we need to reload the full system state, otherwise the behaviour from that point is undefined and can lead to chasing bogus bug reports.
Reviewed by: philip (network), kbowling (transport), gbe (manpages) MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D26652
show more ...
|
Revision tags: release/13.0.0 |
|
#
8268d82c |
| 15-Feb-2021 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Remove per-packet ifa refcounting from IPv6 fast path.
Currently ip6_input() calls in6ifa_ifwithaddr() for every local packet, in order to check if the target ip belongs to the local ifa in proper
Remove per-packet ifa refcounting from IPv6 fast path.
Currently ip6_input() calls in6ifa_ifwithaddr() for every local packet, in order to check if the target ip belongs to the local ifa in proper state and increase its counters.
in6ifa_ifwithaddr() references found ifa. With epoch changes, both `ip6_input()` and all other current callers of `in6ifa_ifwithaddr()` do not need this reference anymore, as epoch provides stability guarantee.
Given that, update `in6ifa_ifwithaddr()` to allow it to return ifa without referencing it, while preserving option for getting referenced ifa if so desired.
MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D28648
show more ...
|
#
605284b8 |
| 13-Feb-2021 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Enforce net epoch in in6_selectsrc().
in6_selectsrc() may call fib6_lookup() in some cases, which requires epoch. Wrap in6_selectsrc* calls into epoch inside its users. Mark it as requiring epoch b
Enforce net epoch in in6_selectsrc().
in6_selectsrc() may call fib6_lookup() in some cases, which requires epoch. Wrap in6_selectsrc* calls into epoch inside its users. Mark it as requiring epoch by adding NET_EPOCH_ASSERT().
MFC after: 1 weeek Differential Revision: https://reviews.freebsd.org/D28647
show more ...
|
#
924d1c9a |
| 08-Feb-2021 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Revert "SO_RERROR indicates that receive buffer overflows should be handled as errors." Wrong version of the change was pushed inadvertenly.
This reverts commit 4a01b854ca5c2e5124958363b3326708b913a
Revert "SO_RERROR indicates that receive buffer overflows should be handled as errors." Wrong version of the change was pushed inadvertenly.
This reverts commit 4a01b854ca5c2e5124958363b3326708b913af71.
show more ...
|
#
4a01b854 |
| 07-Feb-2021 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
SO_RERROR indicates that receive buffer overflows should be handled as errors. Historically receive buffer overflows have been ignored and programs could not tell if they missed messages or messages
SO_RERROR indicates that receive buffer overflows should be handled as errors. Historically receive buffer overflows have been ignored and programs could not tell if they missed messages or messages had been truncated because of overflows. Since programs historically do not expect to get receive overflow errors, this behavior is not the default.
This is really really important for programs that use route(4) to keep in sync with the system. If we loose a message then we need to reload the full system state, otherwise the behaviour from that point is undefined and can lead to chasing bogus bug reports.
show more ...
|
#
d9999ae9 |
| 28-Oct-2020 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Fix use-after-free in icmp6_notify_error().
Reported by: Maxime Villard <max at m00nbsd.net> Reviewed by: markj MFC after: 3 days
|
Revision tags: release/12.2.0 |
|
#
4caea9b1 |
| 19-Oct-2020 |
Mark Johnston <markj@FreeBSD.org> |
icmp6: Count packets dropped due to an invalid hop limit
Pad the icmp6stat structure so that we can add more counters in the future without breaking compatibility again, last done in r358620. Annota
icmp6: Count packets dropped due to an invalid hop limit
Pad the icmp6stat structure so that we can add more counters in the future without breaking compatibility again, last done in r358620. Annotate the rarely executed error paths with __predict_false while here.
Reviewed by: bz, melifaro Sponsored by: NetApp, Inc. Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D26578
show more ...
|
#
eddfb2e8 |
| 03-Jul-2020 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Fix IPv6 regression introduced by r362900.
PR: kern/247729
|
#
6ad7446c |
| 02-Jul-2020 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Complete conversions from fib<4|6>_lookup_nh_<basic|ext> to fib<4|6>_lookup().
fib[46]_lookup_nh_ represents pre-epoch generation of fib api, providing less guarantees over pointer validness and re
Complete conversions from fib<4|6>_lookup_nh_<basic|ext> to fib<4|6>_lookup().
fib[46]_lookup_nh_ represents pre-epoch generation of fib api, providing less guarantees over pointer validness and requiring on-stack data copying.
With no callers remaining, remove fib[46]_lookup_nh_ functions.
Submitted by: Neel Chauhan <neel AT neelc DOT org> Differential Revision: https://reviews.freebsd.org/D25445
show more ...
|
Revision tags: release/11.4.0 |
|
#
da187ddb |
| 01-Jun-2020 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
* Add rib_<add|del|change>_route() functions to manipulate the routing table.
The main driver for the change is the need to improve notification mechanism. Currently callers guess the operation data
* Add rib_<add|del|change>_route() functions to manipulate the routing table.
The main driver for the change is the need to improve notification mechanism. Currently callers guess the operation data based on the rtentry structure returned in case of successful operation result. There are two problems with this appoach. First is that it doesn't provide enough information for the upcoming multipath changes, where rtentry refers to a new nexthop group, and there is no way of guessing which paths were added during the change. Second is that some rtentry fields can change during notification and protecting from it by requiring customers to unlock rtentry is not desired.
Additionally, as the consumers such as rtsock do know which operation they request in advance, making explicit add/change/del versions of the functions makes sense, especially given the functions don't share a lot of code.
With that in mind, introduce rib_cmd_info notification structure and rib_<add|del|change>_route() functions, with mandatory rib_cmd_info pointer. It will be used in upcoming generalized notifications.
* Move definitions of the new functions and some other functions/structures used for the routing table manipulation to a separate header file, net/route/route_ctl.h. net/route.h is a frequently used file included in ~140 places in kernel, and 90% of the users don't need these definitions.
Reviewed by: ae Differential Revision: https://reviews.freebsd.org/D25067
show more ...
|
#
e7403d02 |
| 01-Jun-2020 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Revert r361704, it accidentally committed merged D25067 and D25070.
|
#
79674562 |
| 01-Jun-2020 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
* Add rib_<add|del|change>_route() functions to manipulate the routing table.
The main driver for the change is the need to improve notification mechanism. Currently callers guess the operation data
* Add rib_<add|del|change>_route() functions to manipulate the routing table.
The main driver for the change is the need to improve notification mechanism. Currently callers guess the operation data based on the rtentry structure returned in case of successful operation result. There are two problems with this appoach. First is that it doesn't provide enough information for the upcoming multipath changes, where rtentry refers to a new nexthop group, and there is no way of guessing which paths were added during the change. Second is that some rtentry fields can change during notification and protecting from it by requiring customers to unlock rtentry is not desired.
Additionally, as the consumers such as rtsock do know which operation they request in advance, making explicit add/change/del versions of the functions makes sense, especially given the functions don't share a lot of code.
With that in mind, introduce rib_cmd_info notification structure and rib_<add|del|change>_route() functions, with mandatory rib_cmd_info pointer. It will be used in upcoming generalized notifications.
* Move definitions of the new functions and some other functions/structures used for the routing table manipulation to a separate header file, net/route/route_ctl.h. net/route.h is a frequently used file included in ~140 places in kernel, and 90% of the users don't need these definitions.
Reviewed by: ae Differential Revision: https://reviews.freebsd.org/D25067
show more ...
|
#
a37a5246 |
| 28-May-2020 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Use fib[46]_lookup() in mtu calculations.
fib[46]_lookup_nh_ represents pre-epoch generation of fib api, providing less guarantees over pointer validness and requiring on-stack data copying.
Conver
Use fib[46]_lookup() in mtu calculations.
fib[46]_lookup_nh_ represents pre-epoch generation of fib api, providing less guarantees over pointer validness and requiring on-stack data copying.
Conversion is straight-forwarded, as the only 2 differences are requirement of running in network epoch and the need to handle RTF_GATEWAY case in the caller code.
Differential Revision: https://reviews.freebsd.org/D24974
show more ...
|
#
9ac7c6cf |
| 15-Apr-2020 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Convert IP/IPv6 forwarding, ICMP processing and IP PCB laddr selection to the new routing KPI.
Reviewed by: ae Differential Revision: https://reviews.freebsd.org/D24245
|
#
051669e8 |
| 25-Jan-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r356931 through r357118.
|
#
34a5582c |
| 22-Jan-2020 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Bring back redirect route expiration.
Redirect (and temporal) route expiration was broken a while ago. This change brings route expiration back, with unified IPv4/IPv6 handling code.
It introduces
Bring back redirect route expiration.
Redirect (and temporal) route expiration was broken a while ago. This change brings route expiration back, with unified IPv4/IPv6 handling code.
It introduces net.inet.icmp.redirtimeout sysctl, allowing to set an expiration time for redirected routes. It defaults to 10 minutes, analogues with net.inet6.icmp6.redirtimeout.
Implementation uses separate file, route_temporal.c, as route.c is already bloated with tons of different functions. Internally, expiration is implemented as an per-rnh callout scheduled when route with non-zero rt_expire time is added or rt_expire is changed. It does not add any overhead when no temporal routes are present.
Callout traverses entire routing tree under wlock, scheduling expired routes for deletion and calculating the next time it needs to be run. The rationale for such implemention is the following: typically workloads requiring large amount of routes have redirects turned off already, while the systems with small amount of routes will not inhibit large overhead during tree traversal.
This changes also fixes netstat -rn display of route expiration time, which has been broken since the conversion from kread() to sysctl.
Reviewed by: bz MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D23075
show more ...
|
#
0700d2c3 |
| 03-Dec-2019 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
Make icmp6_reflect() static.
icmp6_reflect() is not used anywhere outside icmp6.c, no reason to export it.
Sponsored by: Netflix
|
#
a4adf6cc |
| 01-Dec-2019 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
Fix m_pullup() problem after removing PULLDOWN_TESTs and KAME EXT_*macros.
r354748-354750 replaced the KAME macros with m_pulldown() calls. Contrary to the rest of the network stack m_len checks bef
Fix m_pullup() problem after removing PULLDOWN_TESTs and KAME EXT_*macros.
r354748-354750 replaced the KAME macros with m_pulldown() calls. Contrary to the rest of the network stack m_len checks before m_pulldown() were not put in placed (see r354748). Put these m_len checks in place for now (to go along with the style of the network stack since the initial commits). These are not put in for performance but to avoid an error scenario (even though it also will help performance at the moment as it avoid allocating an extra mbuf; not because of the unconditional function call).
The observed error case went like this: (1) an mbuf with M_EXT arrives and we call m_pullup() unconditionally on it. (2) m_pullup() will call m_get() unless the requested length is larger than MHLEN (in which case it'll m_freem() the perfectly fine mbuf) and migrate the requested length of data and pkthdr into the new mbuf. (3) If m_get() succeeds, a further m_pullup() call going over MHLEN will fail. This was observed with failing auto-configuration as an RA packet of 200 bytes exceeded MHLEN and the m_pullup() called from nd6_ra_input() dropped the mbuf. (Re-)adding the m_len checks before m_pullup() calls avoids this problems with mbufs using external storage for now.
MFC after: 3 weeks Sponsored by: Netflix
show more ...
|
#
32af08ec |
| 18-Nov-2019 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
icmpv6: Fix mbuf change in mld
After r354748 mld_input() can change the mbuf. The new pointer is never returned to icmp6_input() and when passed to icmp6_rip6_input() the mbuf may no longer valid l
icmpv6: Fix mbuf change in mld
After r354748 mld_input() can change the mbuf. The new pointer is never returned to icmp6_input() and when passed to icmp6_rip6_input() the mbuf may no longer valid leading to a panic. Pass a pointer to the mbuf to mld_input() so we can return an updated version in the non-error case.
Add a test sending an MLD packet case which will trigger this bug.
Pointyhat to: bz Reported by: gallatin, thj MFC After: 2 weeks X-MFC with: r354748 Sponsored by: Netflix
show more ...
|