Age | Commit message (Collapse) | Author | Files | Lines |
|
In some cases, the Linux helpers for endianness conversion are not
present. We use clib helpers to fix this.
Type: fix
Signed-off-by: Guillaume Solignac <gsoligna@cisco.com>
Change-Id: I4d21fb5edae6fa6413b10f298a84ff4b88bda5db
Signed-off-by: Pierre Pfister <ppfister@cisco.com>
Signed-off-by: Dave Wallace <dwallacelf@gmail.com>
|
|
Type: refactor
Change-Id: I5235bf3e9aff58af6ba2c14e8c6529c4fc9ec86c
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
This is a prerequisite patch for the following openssl API optimization
patch, which tries to offload openssl ctx init and key expansion work to
the initialization stage.
Wireguard adds crypto keys via vnet_crypto_key_add (), and whenever it
modifies the keys, the underneath openssl crypto engine shoud be informed
of the changes to update the openssl ctx.
Type: feature
Signed-off-by: Lijian Zhang <Lijian.Zhang@arm.com>
Change-Id: I3e8f033f3f77eebcecfbd06e8e3bbbfdc95a50e2
|
|
Type: improvement
Change-Id: I4591fcb31dd28d1771b3d6e5afdaa14f29efe6ef
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
As per discussion on VPP call - since the APIs are used in CSIT tests,
and there has not been changes in a while, mark them as stable from
the API change process PoV.
Type: improvement
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
Change-Id: Ia644e1dfcd9d182cc6f10089fc44397a61e8aaf6
|
|
The async frames pool may be resized once drained. This will cause 2 problems: original pool pointer is invalidated and pool size changed, both problems will confuse the crypto infra user graph nodes (like IPsec and Wireguard) and crypto engines if they expect the pool pointers always valid and the pool size never changed (for performance reason).
This patch introduces fixed size of the async frames pool. This helps zeroing surprise to the components shown above and avoiding segmentation fault when pool resizing happened. In addition, the crypto engine may take advantage of the feature to sync its own pool/vector with crypto infra.
Type: improvement
Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com>
Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com>
Change-Id: I2a71783b90149fa376848b9c4f84ce8c6c034bef
|
|
Type: feature
With this change, packets that are larger than a single buffer can fit
will be able to be sent and received over a Wireguard tunnel. Also,
cover this with tests.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: Ifaf7325676d728580097bc389b51a9be39e44d88
|
|
This patch can make crypto dispatch node adaptively switching
between pooling and interrupt mode, and improve vpp overall
performance.
Type: improvement
Signed-off-by: Xiaoming Jiang <jiangxiaoming@outlook.com>
Change-Id: I845ed1d29ba9f3c507ea95a337f6dca7f8d6e24e
|
|
Type: fix
API clients can register for peer events (e.g. to be notified when
connection is established). In a multi-worker setup, peer events might
be triggered from a worker thread. In order to send a peer event to the
clients, an API message needs to be allocated and populated.
API messages allocation is only allowed from the main thread. Currently,
the code does not handle the case when a peer event is trying to be sent
from a worker thread. In debug builds, when this happens, it causes
SIGABRT in vl_msg_api_alloc_internal() because assertion "pool == 0 ||
vlib_get_thread_index () == 0" fails. In production builds, when this
happens, it might cause unexplained behavior.
There is a test that is supposed to catch this but all multi-worker
Wireguard tests are currently disabled. This problem is likely to be one
of the reasons they were disabled.
With this fix, when a peer event is triggered from a worker thread,
allocate and send corresponding API message from the main thread using
RPC.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: Ib3fe19f8070563b35732afd16c017411c089437e
|
|
The current implmentation of the hash table is not thread-safe.
This design leads to a segfault when VPP is handling a lot of tunnels
for Wireguard, where one thread modifies the hash table and other
threads start the lookup at the same time.
This fix adds a barrier sync to the hash table access when Wireguard
adds or deletes an element.
Type: fix
Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com>
Change-Id: Id460dfcd46ace17c7bdcd23bd9687d26cecf0a39
|
|
The current implementation can cause memory leaks of async frames
and exhaust the async frames pool. Wireguard can early get async frame,
even when later it turns out it is not needed. Then such frame won't
be freed.
This fix changes the moment of acquiring async frame from the pool, so
it doesn't leak.
Type: fix
Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com>
Change-Id: If7696de6a6f5db84e0dffef60caa31d4a5e6280e
|
|
Currently wg-output-tun() doesn't check if a buffer has enough space for
prepending an ethernet header (wg header over ipv6 vxlan header case
leaves only 8 bytes free).
In such a case move buffer's content.
Type: fix
Change-Id: Iad18860e6b86a3d81f3d96d782de7c59556152d0
Signed-off-by: Alexander Skorichenko <askorichenko@netgate.com>
|
|
We cannot confidently say that if we have received and processed
the handshake_initiation message, then the connection has been established.
Because we also send a response.
The fact that the connection is established can only be considered if a keepalive packet was received.
Type: fix
Signed-off-by: Artem Glazychev <artem.glazychev@xored.com>
Change-Id: I61731916071990f28cdebcd1d0e4d302fa1dee15
|
|
After creating a peer, we send a handshake request. But it's not quite right
to call wg_send_keepalive() directly.
According to documentation, handshake initiation is sent after (REKEY_TIMEOUT + jitter) ms.
Since it's the first one - we don't need to take REKEY_TIMEOUT into account,
but we still have jitter.
It also makes no sense to immediately send keepalives,
because the connection is not created yet.
Type: fix
Signed-off-by: Artem Glazychev <artem.glazychev@xored.com>
Change-Id: I61707e4be79be65abc3396b5f1dbd48ecbf7ba60
|
|
The current implementation of wireguard use dereference value from
pointer, but between get and dereference the value from pointer can be
occur change in pool memory, which means that this pointer can be
invalid. Since current implementation doesn't handle with invalid
pointers, segfault can occur.
The fix add a local variable to keep index of peer from pool and also
handle with null pointers from get pointer from pool.
Type: fix
Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com>
Change-Id: Ic161ab08266e584493338c682d827ea1fd754b98
|
|
In most cases we only need OpenSSL libcrypto (crypto primitives) but
not libssl (tls).
Type: improvement
Change-Id: I9dce27d23d65bf46aea2d0f8aaf417240701efcc
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
The initiate handshake process can be called a numbers times for each
peers, then the main VPP thread called by Wireguard starting to
allocate memory. This behaviour can lead to out of memory when VPP has
a lot of Wireguard tunnels concurrently.
This fix add mutex to send only once handshake initiate at time for
each peers.
Type: fix
Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com>
Change-Id: I13b4b2d47021753926d42a38ccadb36a411c5b79
|
|
Type: fix
Signed-off-by: Artem Glazychev <artem.glazychev@xored.com>
Change-Id: I477e92712e441c91789afdf9be389d967acfa799
|
|
Type: fix
Currently, when a wg interface is administratively disabled initially or
during operation, handshake packets continue to be sent. Data packets
stop being sent because routes pointing to the wg interface will not be
used. But data keys remain.
With this fix, when a wg interface is administratively disabled during
peer creation, avoid connection initialization to the peer. Data keys
and timers should be empty at this point. When a wg interface is
disabled during operation, disable all peers (i.e. stop all timers,
clear data keys, etc.). Thus, state should be identical in both cases.
When a wg interface is administratively enabled, enable all peers (i.e.
get ready to exchange data packets and initiate a connection). Also,
cover these scenarios with tests.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: Ie9a620077e55d519d21b0abc8c0d3c87b378bca3
|
|
Type: fix
As per the protocol:
A handshake initiation is retried after "REKEY_TIMEOUT + jitter" ms,
if a response has not been received...
Currently, if retransmit handshake timer is started, it will trigger
after "REKEY_TIMEOUT + jitter" ms and will try to send a handshake
initiation via wg_send_handshake() given that no responses have been
received. wg_send_handshake() will verify that time stored in
REKEY_TIMEOUT has passed since last handshake initiation sending and if
has, will send a handshake initiation. Time when a handshake initiation
was last sent is stored in last_sent_handshake.
The problem is that last_sent_handshake is not only updated in
wg_send_handshake() when sending handshake initiations but also in
wg_send_handshake_response() when sending handshake responses. When
retransmit handshake timer triggers and a handshake response has been
sent recently, a handshake initiation will not be sent because for
wg_send_handshake() it will look like that time stored in REKEY_TIMEOUT
has not passed yet. Also, the timer will not be restarted.
wg_send_handshake_response() must not update last_sent_handshake,
because this time is used only when sending handshake intitiations. And
the protocol does not say that handshake initiation retransmission and
handshake response sending (i.e. replying to authenticated handshake
initiations) must coordinate.
With this fix, stop updating last_sent_handshake in
wg_send_handshake_response().
Also, this fixes tests that used to wait for "REKEY_TIMEOUT + 1" seconds
and did not receive any handshake initiations. Then they fail.
Also, long-running tests that send wrong packets and do not expect
anything in reply may now receive handshake intiations, consider them as
replies to the wrond packets, and fail. Those are updated to filter out
handshake initiations in such verifications. Moreover, after sending
wrong packets, error counters are already inspected there to confirm
packet processing was unsuccessful.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: I43c428c97ce06cb8a79d239453cb5f6d1ed609d6
|
|
Type: improvement
Roaming functionality allows the peer address to change. The main thread
was being called to update a peer's address if necessary after
processing a received packet. Check in the worker whether this is
necessary before incurring the overhead of the RPC to the main thread.
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
Change-Id: I02184b92dc658e0f57dd39993a3b2f9944187b45
|
|
The ipv6 header length should not be counted in the ipv6 payload length.
This is similar to https://gerrit.fd.io/r/c/vpp/+/36945.
Type: fix
Change-Id: I22de0ff828175829102a85288513ee3f55709108
Signed-off-by: Aloys Augustin <aloaugus@cisco.com>
|
|
Crypto backend errors should not be using the same error as missing
keypair.
Type: fix
Change-Id: I78c2b3df3f08a354463b7824349b08627f2b023c
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
IPv6 payload length should not include the size of the IPv6 header.
Type: fix
Change-Id: Iedcd17d0af8d72d9b5f8f9b605da7c99e151bc9d
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
Type: fix
After peers roaming support addition, FIB entry tracking stopped
working. For example, it can be observed when an adjacency is stacked on
a FIB entry by the plugin and the FIB entry hasn't got ARP resolution
yet. Once the FIB entry gets ARP resolution, the adjacency is not
re-stacked as it used to. This results in endless ARP requests when a
traffic is sent via the adjacency.
This is broken because the plugin stopped using "midchain delegate" with
peers roaming support addition. The reason is that "midchain delegate"
didn't support stacking on a different FIB entry which is needed when
peer's endpoint changes. Now it is supported there (added in 36892).
With this fix, start using "midchane delegate" again and thus, fix FIB
entry tracking. Also, cover this in tests.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: Iea91f38739ab129e601fd6567b52565dbd649371
|
|
Type: feature
With this change, peers are able to roam between different external
endpoints. Successfully authenticated handshake or data packet that is
received from a new endpoint will cause the peer's endpoint to be
updated accordingly.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: Ib4eb7dfa3403f3fb9e8bbe19ba6237c4960c764c
|
|
Type: feature
With this change, if being under load a handshake message with both
valid mac1 and mac2 is received, the peer will be rate limited. Cover
this with tests.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: Id8d58bb293a7975c3d922c48b4948fd25e20af4b
|
|
Type: feature
With this change:
- if the number of received handshake messages exceeds the limit
calculated based on the peers number, under load state will activate;
- if being under load a handshake message with a valid mac1 is
received, but mac2 is invalid, a cookie reply will be sent.
Also, cover these with tests.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: I3003570a9cf807cfb0b5145b89a085455c30e717
|
|
Type: feature
Currently, if a handshake message is sent and a cookie message is
received in reply, the cookie message will be ignored. Thus, further
handshake messages will not have valid mac2 and handshake will not be
able to be completed.
With this change, process received cookie messages to be able to
calculate mac2 for further handshake messages sent. Cover this with
tests.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: I6d51459778b7145be7077badec479b2aa85960b9
|
|
Type: fix
Signed-off-by: Artem Glazychev <artem.glazychev@xored.com>
Change-Id: I62f13ee8cb9b86f8106505fd32a03d66c1a73bce
|
|
Type: improvement
When packets were received and processed successfully, increment the
byte/packet counters for the tunnel interface.
Change-Id: I42855607ac6916de641be42aac86c9942cc97140
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
|
|
Type: fix
Currently, neighbor adjacencies on a wg interface are converted into a
midchain only if one of the peers has a matching allowed prefix
configured. If create a route that goes through a wg interface but the
next-hop address does not match any allowed prefixes, an ARP/ND request
will try to be sent via the wg interface to resolve the next-hop address
when matching traffic occurs. And sending an ARP request will cause VPP
to crash while copying hardware address of the wg interface which is
NULL. Sending an ND message will not cause VPP to crash but the error
logged will be unclear (no source address).
With this fix, convert all neighbor adjacencies on a wg interface into a
midchain and update tests to cover the case. If there is no matching
allowed prefix configured, traffic going such routes will be dropped
because of "Peer error". No changes if there is matching allowed prefix
configured.
Also, fix getting peer by adjacency index.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: I15bc1e1f83de719e97edf3f7210a5359a35bddbd
|
|
Type: improvement
Signed-off-by: Jon Loeliger <jdl@netgate.com>
Change-Id: I446eb86c097d1bf99f05ee47f1c550689d70ced2
|
|
An unexpected packet that shows up on a Wireguard interace
that happens not to have a forwarding peer will cause a
segfault trying to index the vector of peers by adjacency.
Rather than segfaulting, recognize a non-adjacent packet
and drop it instead.
This leaves open the question of what _should_ be
happening to, say, IPv6 multicast packets.
Signed-off-by: Jon Loeliger <jdl@netgate.com>
Type: fix
Fixes: edca1325cf296bd0f5ff422fc12de2ce7a7bad88
Change-Id: Ic0a29e6cf6fe812a4895ec11bedcca86c62e590b
|
|
Just like commit 252647482b24bb3474e8f13bc86100718176832f
did for Wireguard interface keys, prevent stack smashing
the peer keys.
Integer math on 32 bytes of base64 data might yield 33 bytes
of data in some poorly formed user input of private key values.
Rather than smashing the stack (detected) and aborting, simply
allow for the possible yet irrelevant 33-rd byte of data.
Type: fix
Fixes: edca1325cf296bd0f5ff422fc12de2ce7a7bad88
Signed-off-by: Jon Loeliger <jdl@netgate.com>
Change-Id: I9f77b3faaaa01d3123b356c958db60c87238db9c
|
|
- Add peer_index, table_id, and keep-alive.
- Fix some lingering cut-n-paste issues in the API file.
Type: improvement
Signed-off-by: Jon Loeliger <jdl@netgate.com>
Change-Id: I6fc0729ba0268bbcda0248f680979c44e68b6b0c
|
|
Include the user_instance in wireguard interface details.
In addition to dumping all wireguard interface details,
also allow selective dumping of just one interface.
Type: improvement
Signed-off-by: Jon Loeliger <jdl@netgate.com>
Change-Id: Iaf1093c6ae3eb00a685f34b2e0171285b02fae2b
|
|
Type: fix
Fixed coverity-issue CID 248517.
Originally possible passing null pointer to one function and directly
dereferences it.
This patch fixes the issue by add a new condition to check this
pointer.
Change-Id: If506abaf08c9f003860b641971af291f68613c18
Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com>
|
|
Integer math on 32 bytes of base64 data might yield 33 bytes
of data in some poorly formed user input of private key values.
Rather than smashing the stack (detected) and aborting, simply
allow for the possible yet irrelevant 33-rd byte of data.
Type: fix
Fixes: edca1325cf296bd0f5ff422fc12de2ce7a7bad88
Change-Id: I42acfbf3e8fbb3d517e21c53d4f80459d4800e9d
Signed-off-by: Jon Loeliger <jdl@netgate.com>
|
|
Type: fix
Fixed coverity-issue CID 248517.
Originally possibly passing null pointer to one function and
directly dereferences it.
This patch fixes the problem by add a new condition.
Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com>
Change-Id: I02fc6fb5d1cfd6138ea4ba2b1946fd8a7ef34d3b
|
|
If the user supplies an instance number when creating a wireguard
interface, it should be used in the device name. If no user-instance
is given, the device instnce (tunnel number) is used.
For example:
vpp# wireguard create instance 17 listen-port 23023 src 1.2.3.4
private-key MDEwMjAzMDQwNTA2MDcwODA5MTAxMTEyMTMxNDE1MTY=
wg17
Type: fix
Fixes: edca1325cf296bd0f5ff422fc12de2ce7a7bad88
Signed-off-by: Jon Loeliger <jdl@netgate.com>
Change-Id: Ibf51868bf7b4b9e8a3f85557d05667207873bc91
|
|
Type: refactor
IP4 does not depend on TCP (it's the other way around).
This upside down dependency leads to some nasty circular includes when trying to use ip46_address.h in interface.h
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: I4a1bd21543b08b9c1cf1e5563da738414734a878
|
|
Fixed coverity-issue CID 248456.
Originally passing argument of type "uint64_t *" to function:
"memcopy_s_inline".
This patch fixes the problem by changing type of passing argument and
make a portable assumption.
Type: fix
Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com>
Change-Id: I17e4583a05ea1263e4d8a4acc9949454e5fd92c0
|
|
Originally wireguard doesn't support async mode for decryption packets.
This patch add async mode for decryption in wireguard.
In addition, it contains some performance improvement such as
prefetching packet header and reducing the number of current time
function calls.
Type: improvement
Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com>
Change-Id: Ieba6ae0078f3ff140c05b517891afb57232b3b7d
|
|
Originally wireguard doesn't support async mode for encryption packets.
This patch add async mode for encryption in wireguard and also adds
support chacha20-poly1305 algorithm in cryptodev for async handler.
In addition it contains new command line to activate async mode for wireguard:
set wireguard async mode on|off
and also add new command to check active mode for wireguard:
show wireguard mode
Type: improvement
Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com>
Change-Id: I141d48b42ee8dbff0112b8542ab5205268089da6
|
|
Originally wireguard does packet by packet encryption and decryption.
This patch adds burst mode for encryption and decryption packets. In
addition, it contains some performance improvement such as prefetching
packet header and reducing the number of current time function calls.
Type: improvement
Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com>
Change-Id: I04c7daa9b6dc56cd15c789661a64ec642b35aa3f
|
|
- change 'port' to 'dst-port' to make the input self-explanatory
- add empty spaces to short help
Type: fix
Signed-off-by: Miroslav Miklus <miroslav.miklus@pantheon.tech>
Change-Id: I74c783e6e8629e61b1c100e9355d09cf5e35a750
|
|
Originally handshake process gets pointer to value of index peer.
In the meantime this pointer can be invalid due to resize hash table
for wireguard and passed poison value to another function.
The fixes add local variable to keep index of peer instead of value
from pointer.
Type: fix
Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com>
Change-Id: I1b2535c44b4f987d19077c75c778aaa5ed71a457
|
|
Type: fix
Using the adjacency to modify the interface's feature arc doesn't work, since there are potentially more than one adj per-interface.
Instead have the interface, when it is created, register what the end node of the feature arc is. This end node is then also used as the interface's tx node (i.e. it is used as the adjacency's next-node).
rename adj-midhcain-tx as 'tunnel-output', that's a bit more intuitive.
There's also a fix in config string handling to:
1- prevent false sharing of strings when the end node of the arc is different.
2- call registered listeners when the end node is changed
For IPSec the consequences are that one cannot provide per-adjacency behaviour using different end-nodes - this was previously done for the no-SA and an SA with no protection. These cases are no handled in the esp-encrypt node.
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: If3a83d03a3000f28820d9a9cb4101d244803d084
|
|
Originally wireguard implementation does memory copy of the whole
packet in encryption and decryption.
This patch removes unnecessary packet copy in wireguard. In addition,
it contains some performance improvement such as prefetching header
and deleting unnecessary lock and unlock for decryption.
Type: improvement
Signed-off-by: Gabriel Oginski <gabrielx.oginski@intel.com>
Change-Id: I1fe8e54d749e6922465341083b448c842e2b670f
|