src/sys/dev/wg, branch release/13.4.0FreeBSD source treehttps://cgit-dev.freebsd.org/src/atom?h=release%2F13.4.02024-04-16T16:08:54Zwg: Use ENETUNREACH when transmitting to a non-existent peer2024-04-16T16:08:54ZMark Johnstonmarkj@FreeBSD.org2024-04-01T17:20:55Zurn:sha1:894bf6bd7d1dcdb2869cf065bea697e1dda07cb0
The old errno value used is specifically for Capsicum and shouldn't be
co-opted in this way. It has special handling in the generic syscall
layer (see syscallret()). OpenBSD returns ENETUNREACH in this case;
let's do the same thing.
PR: 266712
Reviewed by: kevans, imp
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D44582
(cherry picked from commit 63613e3ba1e188e9fece43e1613bd697f04b345e)
if_wg: use proper barriers around pkt->p_state2024-03-22T15:21:42ZKyle Evanskevans@FreeBSD.org2024-03-15T01:19:18Zurn:sha1:806e51f81dbae21feb6e7ddd95d2ed2a28b04f8f
Without appropriate load-synchronization to pair with store barriers in
wg_encrypt() and wg_decrypt(), the compiler and hardware are often
allowed to reorder these loads in wg_deliver_out() and wg_deliver_in()
such that we end up with a garbage or intermediate mbuf that we try to
pass on. The issue is particularly prevalent with the weaker
memory models of !x86 platforms.
Switch from the big-hammer wmb() to more explicit acq/rel atomics to
both make it obvious what we're syncing up with, and to avoid somewhat
hefty fences on platforms that don't necessarily need this.
With this patch, my dual-iperf3 reproducer is dramatically more stable
than it is without on aarch64.
PR: 264115
Reviewed by: andrew, zlei
(cherry picked from commit 3705d679a6344c957cae7a1b6372a8bfb8c44f0e)
wg: detach bpf upon destroy as well2024-01-30T05:38:01ZAaron LIaly@aaronly.me2024-01-22T16:18:56Zurn:sha1:3deeb70f7f70e5fbabde85efc7ea603cde915f6a
bpfattach() is called in wg_clone_create(), but the bpfdetach() is
missing from wg_close_destroy(). Add the missing bpfdetach() to avoid
leaking both the associated bpf bits as well as the ifnet that bpf will
hold a reference to.
PR: 276526
(cherry picked from commit 43be2d7aaf25b719aec8f49aab110c0061f1edec)
if_wg: fix access to noise_local->l_has_identity and l_private2024-01-30T05:37:57ZAaron LIaly@aaronly.me2024-01-17T23:29:23Zurn:sha1:ce2d249b207045f27ec03719997168c92d0f6104
These members are protected by the identity lock, so rlock it in
noise_remote_alloc() and then assert that we have it held to some extent
in noise_precompute_ss().
PR: 276392
(cherry picked from commit 7a4d1d1df0b2e369adcb32aea9ef8c180f885751)
if_wg: fix erroneous calculation in calculate_padding() for p_mtu == 02024-01-30T05:37:46ZAaron LIaly@aaronly.me2024-01-17T23:29:23Zurn:sha1:bbda52e814e0c760b2beaeae40a2c76ff43d1975
In practice this is harmless; only keepalive packets may realistically have
p_mtu == 0, and they'll also have no payload so the math works out the same
either way. Still, let's prefer technical accuracy and calculate the amount
of padding needed rather than the padded length...
PR: 276363
(cherry picked from commit b891f61ef538a4e9b4658b4b756635c8036a5788)
if_wg: Missing radix unlock can cause deadlock2023-11-19T19:29:35ZAaron LIaly@aaronly.me2023-11-11T13:13:08Zurn:sha1:16c65f7ae15e6ca8b36fc546e038c59270c87ccc
In function 'wg_aip_add()', the error path of returning ENOMEM when
(node == NULL) is forgetting to unlock the radix tree, and thus may lead
to a deadlock.
PR: 275001
Reviewed by: kp
MFC after: 1 week
(cherry picked from commit dcc4d2939f789a6d1f272ffeab2068ba2b7525ea)
sys: Remove $FreeBSD$: two-line .h pattern2023-08-23T17:43:20ZWarner Loshimp@FreeBSD.org2023-08-22T01:31:02Zurn:sha1:f8167e0404dab9ffeaca95853dd237ab7c587f82
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
Similar commit in current:
(cherry picked from commit 95ee2897e98f)
wg: fix a number of issues with module load failure handling2023-07-11T15:05:45ZKyle Evanskevans@FreeBSD.org2023-06-21T18:56:58Zurn:sha1:b39545f7bc38ec9865ac9cb4e703a6344ad8310b
If MOD_LOAD fails, then MOD_UNLOAD will be called to unwind module
state, but wg_module_init() will have already deinitialized everything
it needs to in a manner that renders it unsafe to call MOD_UNLOAD
after (e.g., freed zone not reset to NULL, wg_osd_jail_slot not reset
to 0). Let's simply stop trying to handle freeing everything in
wg_module_init() to simplify it; let the subsequent MOD_UNLOAD deal with
it, and let's make that robust against partially-constructed state.
jhb@ notes that MOD_UNLOAD being called if MOD_LOAD fails is kind of an
anomaly that doesn't match other paradigms in the kernel; e.g., if
device_attach() fails, we don't invoke device_detach(). It's likely
that a future commit will revert this and instead stop calling
MOD_UNLOAD if MOD_LOAD fails, expecting modules to clean up after
themselves in MOD_LOAD upon failure. Some other modules already do this
and may see similar problems to the wg module (see: carp). The proper
fix is decidedly a bit too invasive to do this close to 14 branching,
and it requires auditing all kmods (base + ports) for potential leaks.
PR: 272089
Reviewed by: emaste
(cherry picked from commit b08ee10c0646e683cd03c9e28f537d9a7ba306af)
wg: fix MOD_LOAD to fail properly if cookie_init() fails2023-07-11T15:05:38ZKyle Evanskevans@FreeBSD.org2023-06-23T16:41:07Zurn:sha1:ea2a3ed3bcf7e792ba0c0625602ada29424c337c
Previously we'd jump to the `free_crypto` label, but never set `ret` to
a failure value -- it would retain success from the call just prior.
Set ret up properly.
(cherry picked from commit ad9f4e6351fb23ee81bc940638d20af3ca7c278d)
Switch wg(4) to the new if_clone KPI2023-01-27T19:27:47ZAlan Somersasomers@FreeBSD.org2022-12-18T20:12:02Zurn:sha1:8b7b81fd64ec054e6cbe0f1a817bad44aa355669
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D37740
(cherry picked from commit eb3f9a7aece9473d678adddcf6aefe6c1eec0ac4)