| d15d610f | 26-Jun-2025 |
Kyle Evans <kevans@FreeBSD.org> |
kern: wg: add support for removing Allowed-IPs
This was recently added to Linux to improve incremental update support,
as you could previously add Allowed-IPs but not remove without replacing
the wh
kern: wg: add support for removing Allowed-IPs
This was recently added to Linux to improve incremental update support,
as you could previously add Allowed-IPs but not remove without replacing
the whole set (and thus, potentially disrupting existing traffic).
Removal is incredibly straightforward; we'll find it in p_aips first
to ensure that it's actually valid for this peer, then we'll delete it
from the radix tree before we remove the corresponding p_aips entry.
Reviewed by: Jason A. Donenfeld, jhb
Differential Revision: https://reviews.freebsd.org/D50448
show more ...
|
| 2475a3da | 26-Jun-2025 |
Kyle Evans <kevans@FreeBSD.org> |
kern: wg: split address/mask construction out of wg_aip_add()
We'll re-use these in a future wg_aip_del() to perfectly reconstruct
what we expect to find in a_addr/a_mask.
Reviewed by: ivy, markj (
kern: wg: split address/mask construction out of wg_aip_add()
We'll re-use these in a future wg_aip_del() to perfectly reconstruct
what we expect to find in a_addr/a_mask.
Reviewed by: ivy, markj (both earlier version), Aaron LI, jhb
Differential Revision: https://reviews.freebsd.org/D50447
show more ...
|
| 7a4d1d1d | 18-Jan-2024 |
Aaron LI <aly@aaronly.me> |
if_wg: fix access to noise_local->l_has_identity and l_private
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 exte
if_wg: fix access to noise_local->l_has_identity and l_private
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
show more ...
|
| b08ee10c | 21-Jun-2023 |
Kyle Evans <kevans@FreeBSD.org> |
wg: fix a number of issues with module load failure handling
If MOD_LOAD fails, then MOD_UNLOAD will be called to unwind module
state, but wg_module_init() will have already deinitialized everything
wg: fix a number of issues with module load failure handling
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
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D40708
show more ...
|