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-09 06:27:34 +07:00
|
|
|
/* SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT */
|
|
|
|
/*
|
|
|
|
* Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
|
|
|
|
*
|
|
|
|
* Documentation
|
|
|
|
* =============
|
|
|
|
*
|
|
|
|
* The below enums and macros are for interfacing with WireGuard, using generic
|
|
|
|
* netlink, with family WG_GENL_NAME and version WG_GENL_VERSION. It defines two
|
|
|
|
* methods: get and set. Note that while they share many common attributes,
|
|
|
|
* these two functions actually accept a slightly different set of inputs and
|
|
|
|
* outputs.
|
|
|
|
*
|
|
|
|
* WG_CMD_GET_DEVICE
|
|
|
|
* -----------------
|
|
|
|
*
|
|
|
|
* May only be called via NLM_F_REQUEST | NLM_F_DUMP. The command should contain
|
|
|
|
* one but not both of:
|
|
|
|
*
|
|
|
|
* WGDEVICE_A_IFINDEX: NLA_U32
|
2019-12-16 04:08:02 +07:00
|
|
|
* WGDEVICE_A_IFNAME: NLA_NUL_STRING, maxlen IFNAMSIZ - 1
|
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-09 06:27:34 +07:00
|
|
|
*
|
|
|
|
* The kernel will then return several messages (NLM_F_MULTI) containing the
|
|
|
|
* following tree of nested items:
|
|
|
|
*
|
|
|
|
* WGDEVICE_A_IFINDEX: NLA_U32
|
2019-12-16 04:08:02 +07:00
|
|
|
* WGDEVICE_A_IFNAME: NLA_NUL_STRING, maxlen IFNAMSIZ - 1
|
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-09 06:27:34 +07:00
|
|
|
* WGDEVICE_A_PRIVATE_KEY: NLA_EXACT_LEN, len WG_KEY_LEN
|
|
|
|
* WGDEVICE_A_PUBLIC_KEY: NLA_EXACT_LEN, len WG_KEY_LEN
|
|
|
|
* WGDEVICE_A_LISTEN_PORT: NLA_U16
|
|
|
|
* WGDEVICE_A_FWMARK: NLA_U32
|
|
|
|
* WGDEVICE_A_PEERS: NLA_NESTED
|
|
|
|
* 0: NLA_NESTED
|
|
|
|
* WGPEER_A_PUBLIC_KEY: NLA_EXACT_LEN, len WG_KEY_LEN
|
|
|
|
* WGPEER_A_PRESHARED_KEY: NLA_EXACT_LEN, len WG_KEY_LEN
|
|
|
|
* WGPEER_A_ENDPOINT: NLA_MIN_LEN(struct sockaddr), struct sockaddr_in or struct sockaddr_in6
|
|
|
|
* WGPEER_A_PERSISTENT_KEEPALIVE_INTERVAL: NLA_U16
|
|
|
|
* WGPEER_A_LAST_HANDSHAKE_TIME: NLA_EXACT_LEN, struct __kernel_timespec
|
|
|
|
* WGPEER_A_RX_BYTES: NLA_U64
|
|
|
|
* WGPEER_A_TX_BYTES: NLA_U64
|
|
|
|
* WGPEER_A_ALLOWEDIPS: NLA_NESTED
|
|
|
|
* 0: NLA_NESTED
|
|
|
|
* WGALLOWEDIP_A_FAMILY: NLA_U16
|
|
|
|
* WGALLOWEDIP_A_IPADDR: NLA_MIN_LEN(struct in_addr), struct in_addr or struct in6_addr
|
|
|
|
* WGALLOWEDIP_A_CIDR_MASK: NLA_U8
|
|
|
|
* 0: NLA_NESTED
|
|
|
|
* ...
|
|
|
|
* 0: NLA_NESTED
|
|
|
|
* ...
|
|
|
|
* ...
|
|
|
|
* WGPEER_A_PROTOCOL_VERSION: NLA_U32
|
|
|
|
* 0: NLA_NESTED
|
|
|
|
* ...
|
|
|
|
* ...
|
|
|
|
*
|
|
|
|
* It is possible that all of the allowed IPs of a single peer will not
|
|
|
|
* fit within a single netlink message. In that case, the same peer will
|
|
|
|
* be written in the following message, except it will only contain
|
|
|
|
* WGPEER_A_PUBLIC_KEY and WGPEER_A_ALLOWEDIPS. This may occur several
|
|
|
|
* times in a row for the same peer. It is then up to the receiver to
|
|
|
|
* coalesce adjacent peers. Likewise, it is possible that all peers will
|
|
|
|
* not fit within a single message. So, subsequent peers will be sent
|
|
|
|
* in following messages, except those will only contain WGDEVICE_A_IFNAME
|
|
|
|
* and WGDEVICE_A_PEERS. It is then up to the receiver to coalesce these
|
|
|
|
* messages to form the complete list of peers.
|
|
|
|
*
|
|
|
|
* Since this is an NLA_F_DUMP command, the final message will always be
|
|
|
|
* NLMSG_DONE, even if an error occurs. However, this NLMSG_DONE message
|
|
|
|
* contains an integer error code. It is either zero or a negative error
|
|
|
|
* code corresponding to the errno.
|
|
|
|
*
|
|
|
|
* WG_CMD_SET_DEVICE
|
|
|
|
* -----------------
|
|
|
|
*
|
|
|
|
* May only be called via NLM_F_REQUEST. The command should contain the
|
|
|
|
* following tree of nested items, containing one but not both of
|
|
|
|
* WGDEVICE_A_IFINDEX and WGDEVICE_A_IFNAME:
|
|
|
|
*
|
|
|
|
* WGDEVICE_A_IFINDEX: NLA_U32
|
2019-12-16 04:08:02 +07:00
|
|
|
* WGDEVICE_A_IFNAME: NLA_NUL_STRING, maxlen IFNAMSIZ - 1
|
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-09 06:27:34 +07:00
|
|
|
* WGDEVICE_A_FLAGS: NLA_U32, 0 or WGDEVICE_F_REPLACE_PEERS if all current
|
|
|
|
* peers should be removed prior to adding the list below.
|
|
|
|
* WGDEVICE_A_PRIVATE_KEY: len WG_KEY_LEN, all zeros to remove
|
|
|
|
* WGDEVICE_A_LISTEN_PORT: NLA_U16, 0 to choose randomly
|
|
|
|
* WGDEVICE_A_FWMARK: NLA_U32, 0 to disable
|
|
|
|
* WGDEVICE_A_PEERS: NLA_NESTED
|
|
|
|
* 0: NLA_NESTED
|
|
|
|
* WGPEER_A_PUBLIC_KEY: len WG_KEY_LEN
|
|
|
|
* WGPEER_A_FLAGS: NLA_U32, 0 and/or WGPEER_F_REMOVE_ME if the
|
|
|
|
* specified peer should not exist at the end of the
|
|
|
|
* operation, rather than added/updated and/or
|
|
|
|
* WGPEER_F_REPLACE_ALLOWEDIPS if all current allowed
|
|
|
|
* IPs of this peer should be removed prior to adding
|
|
|
|
* the list below and/or WGPEER_F_UPDATE_ONLY if the
|
|
|
|
* peer should only be set if it already exists.
|
|
|
|
* WGPEER_A_PRESHARED_KEY: len WG_KEY_LEN, all zeros to remove
|
|
|
|
* WGPEER_A_ENDPOINT: struct sockaddr_in or struct sockaddr_in6
|
|
|
|
* WGPEER_A_PERSISTENT_KEEPALIVE_INTERVAL: NLA_U16, 0 to disable
|
|
|
|
* WGPEER_A_ALLOWEDIPS: NLA_NESTED
|
|
|
|
* 0: NLA_NESTED
|
|
|
|
* WGALLOWEDIP_A_FAMILY: NLA_U16
|
|
|
|
* WGALLOWEDIP_A_IPADDR: struct in_addr or struct in6_addr
|
|
|
|
* WGALLOWEDIP_A_CIDR_MASK: NLA_U8
|
|
|
|
* 0: NLA_NESTED
|
|
|
|
* ...
|
|
|
|
* 0: NLA_NESTED
|
|
|
|
* ...
|
|
|
|
* ...
|
|
|
|
* WGPEER_A_PROTOCOL_VERSION: NLA_U32, should not be set or used at
|
|
|
|
* all by most users of this API, as the
|
|
|
|
* most recent protocol will be used when
|
|
|
|
* this is unset. Otherwise, must be set
|
|
|
|
* to 1.
|
|
|
|
* 0: NLA_NESTED
|
|
|
|
* ...
|
|
|
|
* ...
|
|
|
|
*
|
|
|
|
* It is possible that the amount of configuration data exceeds that of
|
|
|
|
* the maximum message length accepted by the kernel. In that case, several
|
|
|
|
* messages should be sent one after another, with each successive one
|
|
|
|
* filling in information not contained in the prior. Note that if
|
|
|
|
* WGDEVICE_F_REPLACE_PEERS is specified in the first message, it probably
|
|
|
|
* should not be specified in fragments that come after, so that the list
|
2019-12-16 04:08:02 +07:00
|
|
|
* of peers is only cleared the first time but appended after. Likewise for
|
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-09 06:27:34 +07:00
|
|
|
* peers, if WGPEER_F_REPLACE_ALLOWEDIPS is specified in the first message
|
|
|
|
* of a peer, it likely should not be specified in subsequent fragments.
|
|
|
|
*
|
|
|
|
* If an error occurs, NLMSG_ERROR will reply containing an errno.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _WG_UAPI_WIREGUARD_H
|
|
|
|
#define _WG_UAPI_WIREGUARD_H
|
|
|
|
|
|
|
|
#define WG_GENL_NAME "wireguard"
|
|
|
|
#define WG_GENL_VERSION 1
|
|
|
|
|
|
|
|
#define WG_KEY_LEN 32
|
|
|
|
|
|
|
|
enum wg_cmd {
|
|
|
|
WG_CMD_GET_DEVICE,
|
|
|
|
WG_CMD_SET_DEVICE,
|
|
|
|
__WG_CMD_MAX
|
|
|
|
};
|
|
|
|
#define WG_CMD_MAX (__WG_CMD_MAX - 1)
|
|
|
|
|
|
|
|
enum wgdevice_flag {
|
|
|
|
WGDEVICE_F_REPLACE_PEERS = 1U << 0,
|
|
|
|
__WGDEVICE_F_ALL = WGDEVICE_F_REPLACE_PEERS
|
|
|
|
};
|
|
|
|
enum wgdevice_attribute {
|
|
|
|
WGDEVICE_A_UNSPEC,
|
|
|
|
WGDEVICE_A_IFINDEX,
|
|
|
|
WGDEVICE_A_IFNAME,
|
|
|
|
WGDEVICE_A_PRIVATE_KEY,
|
|
|
|
WGDEVICE_A_PUBLIC_KEY,
|
|
|
|
WGDEVICE_A_FLAGS,
|
|
|
|
WGDEVICE_A_LISTEN_PORT,
|
|
|
|
WGDEVICE_A_FWMARK,
|
|
|
|
WGDEVICE_A_PEERS,
|
|
|
|
__WGDEVICE_A_LAST
|
|
|
|
};
|
|
|
|
#define WGDEVICE_A_MAX (__WGDEVICE_A_LAST - 1)
|
|
|
|
|
|
|
|
enum wgpeer_flag {
|
|
|
|
WGPEER_F_REMOVE_ME = 1U << 0,
|
|
|
|
WGPEER_F_REPLACE_ALLOWEDIPS = 1U << 1,
|
|
|
|
WGPEER_F_UPDATE_ONLY = 1U << 2,
|
|
|
|
__WGPEER_F_ALL = WGPEER_F_REMOVE_ME | WGPEER_F_REPLACE_ALLOWEDIPS |
|
|
|
|
WGPEER_F_UPDATE_ONLY
|
|
|
|
};
|
|
|
|
enum wgpeer_attribute {
|
|
|
|
WGPEER_A_UNSPEC,
|
|
|
|
WGPEER_A_PUBLIC_KEY,
|
|
|
|
WGPEER_A_PRESHARED_KEY,
|
|
|
|
WGPEER_A_FLAGS,
|
|
|
|
WGPEER_A_ENDPOINT,
|
|
|
|
WGPEER_A_PERSISTENT_KEEPALIVE_INTERVAL,
|
|
|
|
WGPEER_A_LAST_HANDSHAKE_TIME,
|
|
|
|
WGPEER_A_RX_BYTES,
|
|
|
|
WGPEER_A_TX_BYTES,
|
|
|
|
WGPEER_A_ALLOWEDIPS,
|
|
|
|
WGPEER_A_PROTOCOL_VERSION,
|
|
|
|
__WGPEER_A_LAST
|
|
|
|
};
|
|
|
|
#define WGPEER_A_MAX (__WGPEER_A_LAST - 1)
|
|
|
|
|
|
|
|
enum wgallowedip_attribute {
|
|
|
|
WGALLOWEDIP_A_UNSPEC,
|
|
|
|
WGALLOWEDIP_A_FAMILY,
|
|
|
|
WGALLOWEDIP_A_IPADDR,
|
|
|
|
WGALLOWEDIP_A_CIDR_MASK,
|
|
|
|
__WGALLOWEDIP_A_LAST
|
|
|
|
};
|
|
|
|
#define WGALLOWEDIP_A_MAX (__WGALLOWEDIP_A_LAST - 1)
|
|
|
|
|
|
|
|
#endif /* _WG_UAPI_WIREGUARD_H */
|