Commit Graph

8 Commits

Author SHA1 Message Date
Petr Oros ab39cead6a genetlink: remove linux/genetlink.h
JIRA: https://issues.redhat.com/browse/RHEL-57756

Upstream commit(s):
commit cd7209628cdb2a7edd7656c126d2455e7102e949
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Fri Mar 29 10:57:10 2024 -0700

    genetlink: remove linux/genetlink.h

    genetlink.h is a shell of what used to be a combined uAPI
    and kernel header over a decade ago. It has fewer than
    10 lines of code. Merge it into net/genetlink.h.
    In some ways it'd be better to keep the combined header
    under linux/ but it would make looking through git history
    harder.

    Acked-by: Sven Eckelmann <sven@narfation.org>
    Link: https://lore.kernel.org/r/20240329175710.291749-4-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Petr Oros <poros@redhat.com>
2024-12-10 10:37:53 +01:00
Hangbin Liu ede6025595 wireguard: main: rename 'mod_init' & 'mod_exit' functions to be module-specific
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2076974
Upstream Status: net.git commit b251b711a921

commit b251b711a92189d558b07fde5a7ccd5a7915ebdd
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Mon Nov 29 10:39:23 2021 -0500

    wireguard: main: rename 'mod_init' & 'mod_exit' functions to be module-specific

    Rename module_init & module_exit functions that are named
    "mod_init" and "mod_exit" so that they are unique in both the
    System.map file and in initcall_debug output instead of showing
    up as almost anonymous "mod_init".

    This is helpful for debugging and in determining how long certain
    module_init calls take to execute.

    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Hangbin Liu <haliu@redhat.com>
2022-04-22 15:40:58 +08:00
Hangbin Liu 840b99a9d9 wireguard: disable in FIPS mode
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1940794
Upstream: RHEL Only

The cryptos(BLAKE2S, Curve25519, CHACHA20POLY1305) in WireGuard are not
FIPS approved. Disable loading the cryptos is a better solution, but the
cryptos called by WireGuard are in lib/crypto/ instead of crypto/, which
is a little complex to disable. While disabling the WireGuard module is
more clear and easier.

So let's disable the WireGuard in FIPS mode first. When the issue that
loading the lib/crypto/ code in FIPS mode is fixed. We can revert this
internal patch.

Signed-off-by: Hangbin Liu <haliu@redhat.com>
2021-08-30 14:31:02 -04:00
Hangbin Liu 63c0f64e7d wireguard: mark as Tech Preview
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1613522
Upstream: RHEL only

WireGuard is Tech Preview in RHEL 9.0.

Signed-off-by: Hangbin Liu <haliu@redhat.com>
2021-08-30 14:30:46 -04:00
Jason A. Donenfeld dc680de28c wireguard: allowedips: allocate nodes in kmem_cache
The previous commit moved from O(n) to O(1) for removal, but in the
process introduced an additional pointer member to a struct that
increased the size from 60 to 68 bytes, putting nodes in the 128-byte
slab. With deployed systems having as many as 2 million nodes, this
represents a significant doubling in memory usage (128 MiB -> 256 MiB).
Fix this by using our own kmem_cache, that's sized exactly right. This
also makes wireguard's memory usage more transparent in tools like
slabtop and /proc/slabinfo.

Fixes: e7096c131e ("net: WireGuard secure network tunnel")
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Matthew Wilcox <willy@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-04 14:25:14 -07:00
Jason A. Donenfeld a4e9f8e328 wireguard: peer: allocate in kmem_cache
With deployments having upwards of 600k peers now, this somewhat heavy
structure could benefit from more fine-grained allocations.
Specifically, instead of using a 2048-byte slab for a 1544-byte object,
we can now use 1544-byte objects directly, thus saving almost 25%
per-peer, or with 600k peers, that's a savings of 303 MiB. This also
makes wireguard's memory usage more transparent in tools like slabtop
and /proc/slabinfo.

Fixes: 8b5553ace8 ("wireguard: queueing: get rid of per-peer ring buffers")
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Matthew Wilcox <willy@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-04 14:25:14 -07:00
YueHaibing 43967b6ff9 wireguard: main: remove unused include <linux/version.h>
Remove <linux/version.h> from the includes for main.c, which is unused.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
[Jason: reworded commit message]
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-16 19:22:22 -08:00
Jason A. Donenfeld e7096c131e net: WireGuard secure network tunnel
WireGuard is a layer 3 secure networking tunnel made specifically for
the kernel, that aims to be much simpler and easier to audit than IPsec.
Extensive documentation and description of the protocol and
considerations, along with formal proofs of the cryptography, are
available at:

  * https://www.wireguard.com/
  * https://www.wireguard.com/papers/wireguard.pdf

This commit implements WireGuard as a simple network device driver,
accessible in the usual RTNL way used by virtual network drivers. It
makes use of the udp_tunnel APIs, GRO, GSO, NAPI, and the usual set of
networking subsystem APIs. It has a somewhat novel multicore queueing
system designed for maximum throughput and minimal latency of encryption
operations, but it is implemented modestly using workqueues and NAPI.
Configuration is done via generic Netlink, and following a review from
the Netlink maintainer a year ago, several high profile userspace tools
have already implemented the API.

This commit also comes with several different tests, both in-kernel
tests and out-of-kernel tests based on network namespaces, taking profit
of the fact that sockets used by WireGuard intentionally stay in the
namespace the WireGuard interface was originally created, exactly like
the semantics of userspace tun devices. See wireguard.com/netns/ for
pictures and examples.

The source code is fairly short, but rather than combining everything
into a single file, WireGuard is developed as cleanly separable files,
making auditing and comprehension easier. Things are laid out as
follows:

  * noise.[ch], cookie.[ch], messages.h: These implement the bulk of the
    cryptographic aspects of the protocol, and are mostly data-only in
    nature, taking in buffers of bytes and spitting out buffers of
    bytes. They also handle reference counting for their various shared
    pieces of data, like keys and key lists.

  * ratelimiter.[ch]: Used as an integral part of cookie.[ch] for
    ratelimiting certain types of cryptographic operations in accordance
    with particular WireGuard semantics.

  * allowedips.[ch], peerlookup.[ch]: The main lookup structures of
    WireGuard, the former being trie-like with particular semantics, an
    integral part of the design of the protocol, and the latter just
    being nice helper functions around the various hashtables we use.

  * device.[ch]: Implementation of functions for the netdevice and for
    rtnl, responsible for maintaining the life of a given interface and
    wiring it up to the rest of WireGuard.

  * peer.[ch]: Each interface has a list of peers, with helper functions
    available here for creation, destruction, and reference counting.

  * socket.[ch]: Implementation of functions related to udp_socket and
    the general set of kernel socket APIs, for sending and receiving
    ciphertext UDP packets, and taking care of WireGuard-specific sticky
    socket routing semantics for the automatic roaming.

  * netlink.[ch]: Userspace API entry point for configuring WireGuard
    peers and devices. The API has been implemented by several userspace
    tools and network management utility, and the WireGuard project
    distributes the basic wg(8) tool.

  * queueing.[ch]: Shared function on the rx and tx path for handling
    the various queues used in the multicore algorithms.

  * send.c: Handles encrypting outgoing packets in parallel on
    multiple cores, before sending them in order on a single core, via
    workqueues and ring buffers. Also handles sending handshake and cookie
    messages as part of the protocol, in parallel.

  * receive.c: Handles decrypting incoming packets in parallel on
    multiple cores, before passing them off in order to be ingested via
    the rest of the networking subsystem with GRO via the typical NAPI
    poll function. Also handles receiving handshake and cookie messages
    as part of the protocol, in parallel.

  * timers.[ch]: Uses the timer wheel to implement protocol particular
    event timeouts, and gives a set of very simple event-driven entry
    point functions for callers.

  * main.c, version.h: Initialization and deinitialization of the module.

  * selftest/*.h: Runtime unit tests for some of the most security
    sensitive functions.

  * tools/testing/selftests/wireguard/netns.sh: Aforementioned testing
    script using network namespaces.

This commit aims to be as self-contained as possible, implementing
WireGuard as a standalone module not needing much special handling or
coordination from the network subsystem. I expect for future
optimizations to the network stack to positively improve WireGuard, and
vice-versa, but for the time being, this exists as intentionally
standalone.

We introduce a menu option for CONFIG_WIREGUARD, as well as providing a
verbose debug log and self-tests via CONFIG_WIREGUARD_DEBUG.

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: David Miller <davem@davemloft.net>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-08 17:48:42 -08:00