aboutsummaryrefslogtreecommitdiffstats
path: root/src/vnet/crypto/crypto.h
AgeCommit message (Collapse)AuthorFilesLines
2024-03-12misc: remove GNU Indent directivesDamjan Marion1-2/+0
Type: refactor Change-Id: I5235bf3e9aff58af6ba2c14e8c6529c4fc9ec86c Signed-off-by: Damjan Marion <damarion@cisco.com>
2024-02-19wireguard: notify key changes to crypto engineLijian Zhang1-0/+1
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
2023-09-12crypto: allow changing dispatch modeVratko Polak1-1/+1
This change aims to affect crypto_sw_scheduler behavior, but all the edits end up in vnet/crypto. Previous release CSIT tests were testing async crypto in polling mode. After 9a9604b09f15691d7c4ddf29afd99a31e7e31eed introduced adaptive mode for crypto dispatch, the CSIT performance got way worse. Possibly, there is another VPP bug related to adaptive mode (it should not lose as many packets as seen in CSIT), but the next release is too close for trying to fix that. This change (instead of fixing adaptive mode) allows CSIT to continue testing polling mode (after explicit API call), while keeping the adaptive mode as default behavior. The deprecated crypto_set_async_dispatch always disable adaptive mode, crypto_set_async_dispatch_v2 has parameter to enable or disable it. The mode parameter is still used for the inital state of adaptive mode. Type: feature Change-Id: Ib98080eefb4be291207af543884f2c3837f92f59 Signed-off-by: Vratko Polak <vrpolak@cisco.com>
2023-08-08ipsec: add support for RFC-4543 ENCR_NULL_AUTH_AES_GMACBenoît Ganne1-5/+14
Type: improvement Change-Id: I830f7a2ea3ac0aff5185698b9fa7a278c45116b0 Signed-off-by: Benoît Ganne <bganne@cisco.com>
2023-06-08crypto: use fixed crypto frame poolgaoginskx1-6/+10
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
2023-06-01crypto: make crypto-dispatch node working in adaptive modeXiaoming Jiang1-15/+5
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
2023-03-06crypto: remove VNET_CRYPTO_OP_FLAG_INIT_IV flagBenoît Ganne1-3/+2
IV requirements vary wildly with the selected mode of operation. For example, for AES-CBC the IV must be unpredictable whereas for AES counter mode (CTR or GCM), it can be predictable but reusing an IV with the same key material is catastrophic. Because of that, it is hard to generate IV in a generic way, and it is better left to the crypto user (eg. IPsec). Type: improvement Change-Id: I32689c591d8c6572b8d37c4d24f175ea6132d3ec Signed-off-by: Benoît Ganne <bganne@cisco.com>
2023-02-08ipsec: fix AES CBC IV generation (CVE-2022-46397)Benoît Ganne1-2/+2
For AES-CBC, the IV must be unpredictable (see NIST SP800-38a Appendix C). Chaining IVs like is done by ipsecmb and native backends for the VNET_CRYPTO_OP_FLAG_INIT_IV is fully predictable. Encrypt a counter as part of the message, making the (predictable) counter-generated IV unpredictable. Fixes: VPP-2037 Type: fix Change-Id: If4f192d62bf97dda553e7573331c75efa11822ae Signed-off-by: Benoît Ganne <bganne@cisco.com>
2022-03-31crypto: drop the frame if there is no handlerDastin Wilski1-0/+6
If async engines are disbaled and async is turned on vpp tries to enqueue frame with nonexisting handler which leads to segfault. This patch checks for handler and drops the frame in case it doesn't exist. Type: fix Signed-off-by: Dastin Wilski <dastin.wilski@gmail.com> Change-Id: I67211867ee29dc41cc9f0733e8e0b3ea86677f85
2022-01-21wireguard: add async mode for encryption packetsGabriel Oginski1-9/+10
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
2022-01-05crypto: encrypt/decrypt queues sw_schedulerJakub Wysocki1-10/+10
Type: improvement Previously multiple sw crypto scheduler queues per core design caused unaverage frame processing rate for each async op ID – the lower the op ID is the highly likely they are processed first. For example, when a RX core is feeding both encryption and decryption jobs of the same crypto algorithm to the queues at a high rate, in the mean time the crypto cores have no enough cycles to process all: the jobs in the decryption queue are less likely being processed, causing packet drop. To improve the situation this patch makes every core only owning a two queues, one for encrypt operations and one for decrypt. The queue is changed either after checking each core or after founding a frame to process. All crypto jobs with different algorithm are pushed to thoses queues and are treated evenly. In addition, the crypto async infra now uses unified dequeue handler, one per engine. Only the active engine will be registered its dequeue handler in crypto main. Signed-off-by: DariuszX Kazimierski <dariuszx.kazimierski@intel.com> Signed-off-by: PiotrX Kleski <piotrx.kleski@intel.com> Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com> Signed-off-by: Jakub Wysocki <jakubx.wysocki@intel.com> Change-Id: I517ee8e31633980de5e0dd4b05e1d5db5dea760e
2021-05-05crypto crypto-openssl: support hashing operationsFilip Tehlar1-14/+26
Type: feature Change-Id: I36041fe5c5f0ff129aee42516189807e96f62123 Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2021-04-20crypto: support async handlers for 3des and md5Alexander Chernavin1-0/+9
With this change, add support for 3DES and MD5 in IPsec async mode. After changes in foreach_crypto_link_async_alg, the last combination in the list (aes-256-cbc-hmac-sha-512) started to fail during decription. That was also fixed by proper vector size validation. Type: improvement Signed-off-by: Alexander Chernavin <achernavin@netgate.com> Change-Id: I660657bdab62ea9cf031c3e43d99f2317e5f74d7
2021-04-09dpdk: selection of cryptodev engine data-pathFan Zhang1-0/+1
Type: improvement This patch combined cryptodev op and cryptodev raw API data paths into one and makes the engine run-timely select which data path is used: if all cryptodev devices support RTE_CRYPTODEV_FF_SYM_RAW_DP feature flag, the raw data path API is used, otherwise the traditional data path is used. Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com> Change-Id: Ibbd7c4405288bd9a48a34878954fd3040df7b4ad
2021-03-26vlib: introduce vlib_get_main_by_index(), vlib_get_n_threads()Damjan Marion1-1/+1
Type: improvement Change-Id: If3da7d4338470912f37ff1794620418d928fb77f Signed-off-by: Damjan Marion <damarion@cisco.com>
2021-03-05ipsec: Submit fuller async framesNeale Ranns1-53/+29
Type: improvement In the current scheme an async frame is submitted each time the crypto op changes. thus happens each time a different SA is used and thus potentially many times per-node. thi can lead to the submision of many partially filled frames. change the scheme to construct as many full frames as possible in the node and submit them all at the end. the frame owner ship is passed to the user so that there can be more than one open frame per-op at any given time. Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: Ic2305581d7b5aa26133f52115e0cd28ba956ed55
2021-03-04crypto: add support for aes-ctr+sha-1 chainsBenoît Ganne1-16/+19
Type: feature Change-Id: I9d4f90bc701d2b9b903a018f8d27cec5e129d7be Signed-off-by: Benoît Ganne <bganne@cisco.com>
2021-02-24crypto: A more memory efficient layout of the frame element structNeale Ranns1-14/+22
Type: improvement Also: - state as enum so my GDB life is easier - typo; s/indice/indices/; Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: I3320f5ef1ccd7d042071ef336488a41adfad7463
2020-12-04crypto: fixed vnet_crypto_async_reset_frame assertPiotrX Kleski1-1/+2
Type: fix Changed vnet_crypto_async_reset_frame assert to expect also ERROR state frames. Signed-off-by: PiotrX Kleski <piotrx.kleski@intel.com> Change-Id: I3abc29f3f9642027aee38a59a932e54c90da859d
2020-12-04crypto: fixed async frame enqueue race conditionPiotrX Kleski1-2/+8
Type: fix To avoid race condition happening in async crypto engines, async frame state and thread index set should happen before enqueue. In addition as the enqueue handler already returns the enqueue status, when an enqueue is failed, the async crypto engine shall not worry about setting the async frame state but let the submit_open_frame function to do just that. Signed-off-by: PiotrX Kleski <piotrx.kleski@intel.com> Reviewed-by: Fan Zhang <roy.fan.zhang@intel.com> Change-Id: Ic1b0c94478b3cfd5fab98657218bbd70c46a220a
2020-09-03crypto: Add async crypto APIsNathan Skrzypczak1-1/+0
Type: feature This adds api calls for the following CLIs: * set sw_scheuduler worker <N> crypto on|off * set crypto async dispatch polling|interrupt * set crypto handler * set crypto async handler Change-Id: Ic701d149c440e42ea4575da42b9f69e4c8759602 Signed-off-by: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
2020-09-03crypto: SW scheduler async crypto enginePiotrX Kleski1-10/+34
Type: feature This patch adds new sw_scheduler async crypto engine. The engine transforms async frames info sync crypto ops and delegates them to active sync engines. With the patch it is possible to increase the single worker crypto throughput by offloading the crypto workload to multiple workers. By default all workers in the system will attend the crypto workload processing. However a worker's available cycles are limited. To avail more cycles to one worker to process other workload (e.g. the worker core that handles the RX/TX and IPSec stack processing), a useful cli command is added to remove itself (or add it back later) from the heavy crypto workload but only let other workers to process the crypto. The command is: - set sw_scheduler worker <idx> crypto <on|off> It also adds new interrupt mode to async crypto dispatch node. This mode signals the node when new frames are enqueued as opposed to polling mode that continuously calls dispatch node. New cli commands: - set crypto async dispatch [polling|interrupt] - show crypto async status (displays mode and nodes' states) Signed-off-by: PiotrX Kleski <piotrx.kleski@intel.com> Signed-off-by: DariuszX Kazimierski <dariuszx.kazimierski@intel.com> Reviewed-by: Fan Zhang <roy.fan.zhang@intel.com> Change-Id: I332655f347bb9e3bc9c64166e86e393e911bdb39
2020-09-01crypto: add chacha20-poly1305 algoArtem Glazychev1-2/+5
Type: feature Signed-off-by: Artem Glazychev <artem.glazychev@xored.com> Change-Id: I3697cf7fab7abb7c3d2f61ef326c9116bc1eed66
2020-04-30crypto: introduce async crypto infraFan Zhang1-10/+317
Type: feature Signed-off-by: Damjan Marion <damarion@cisco.com> Signed-off-by: Filip Tehlar <ftehlar@cisco.com> Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com> Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com> Signed-off-by: Dariusz Kazimierski <dariuszx.kazimierski@intel.com> Signed-off-by: Piotr Kleski <piotrx.kleski@intel.com> Change-Id: I4c3fcccf55c36842b7b48aed260fef2802b5c54b
2020-02-11ipsec: add support for chained buffersFilip Tehlar1-10/+85
Type: feature Change-Id: Ie072a7c2bbb1e4a77f7001754f01897efd30fc53 Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2019-11-12crypto: not use vec api with opt_data[VNET_CRYPTO_N_OP_IDS]Lijian Zhang1-1/+2
opt_data is defined as a array, while in some code, e.g., function vnet_crypto_get_op_type, it's used as vec. vec api is not applicable to static arraies. src/vnet/crypto/crypto.h:234:70: error: address of array 'cm->opt_data' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion] vnet_crypto_op_data_t *od = ({ do { if ((0 > 0) && ! ((id) < ((cm->opt_data) ? (((vec_header_t *) (cm->opt_data) - 1)->len) : 0))) Type: fix Change-Id: I0b6754406e4216ca975bc1da4b5d4ce293a9bb45 Signed-off-by: Lijian Zhang <Lijian.Zhang@arm.com>
2019-07-24ipsec: GCM, Anti-replay and ESN fixessNeale Ranns1-2/+1
Type: fix Several Fixes: 1 - Anti-replay did not work with GCM becuase it overwrote the sequence number in the ESP header. To fix i added the seq num to the per-packet data so it is preserved 2 - The high sequence number was not byte swapped during ESP encrypt. 3 - openssl engine was the only one to return FAIL_DECRYPT for bad GCM the others return BAD_HMAC. removed the former 4 - improved tracing to show the low and high seq numbers 5 - documented the anti-replay window checks 6 - fixed scapy patch for ESN support for GCM 7 - tests for anti-reply (w/ and w/o ESN) for each crypto algo Change-Id: Id65d96b6d1d4dd821b2ab557e87468fff6d70e5b Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-06-25ipsec: return error if the engine backend has no handler for theNeale Ranns1-0/+1
requested alogrithm. Type: feature Change-Id: I19a9c14b2bb52ba2fc66246845b7ada73d5095d1 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-06-07ipsec: remove the set_key APINeale Ranns1-2/+0
there's no use case to just change the key of an SA. instead the SA should be renegociated and the new SA applied to the existing SPD entry or tunnel. the set_key functions were untested. Type: refactor Change-Id: Ib096eebaafb20be7b5501ece5a24aea038373002 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-06-05IPSEC: some CLI fixesNeale Ranns1-1/+1
Change-Id: I45618347e37440263270baf07b2f82f653f754a5 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-04-30crypto: enforce per-alg crypto key lengthBenoît Ganne1-14/+16
Crypto algorithms have different requirements on key length. As we do not support key stretching (eg. PBKDF2), user must provide the exact key length used by the algorithm. Failing that means low-level crypto functions might read garbage (eg. aes128_key_expand() will read 16-bytes, regardless of the key provided by the user). Change-Id: I347a1ea7a59720a1ed07ceaad8b00a31f78458c9 Signed-off-by: Benoît Ganne <bganne@cisco.com>
2019-04-26crypto, ipsec: change GCM IV handlingDamjan Marion1-1/+1
- nonce construction out of salt and iv is ipsec specific so it should be handled in ipsec code - fixes GCM unit tests - GCM IV is constructed out of simple counter, per RFC4106 section 3.1 Change-Id: Ib7712cc9612830daa737f5171d8384f1d361bb61 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-04-25crypto: AES GCM IV length is always 12Damjan Marion1-1/+1
... at least for use cases we are interested in Change-Id: I1156ff354635e8f990ce2664ebc8dcd3786ddca5 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-04-25crypto: improve key handlingDamjan Marion1-8/+43
Change-Id: If96f661d507305da4b96cac7b1a8f14ba90676ad Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-04-16IPSEC: support GCM in ESPNeale Ranns1-1/+1
Change-Id: Id2ddb77b4ec3dd543d6e638bc882923f2bac011d Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-04-14crypto: add support for AES-CTR cipherfituldo1-1/+4
Change-Id: I7d84bab7768421ed37813702c0413e52167f41ab Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2019-04-11crypto: add performace test to unittest pluginDamjan Marion1-0/+1
Change-Id: I49c710c5ace24a4c1f083120fd4c2972566a1695 Signed-off-by: Damjan Marion <damarion@cisco.com> Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2019-04-07crypto: add support for AEAD and AES-GCMDamjan Marion1-42/+74
Change-Id: Iff6f81a49b9cff5522fbb4914d47472423eac5db Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-03-29ipsec: esp-decrypt reworkDamjan Marion1-11/+7
Change-Id: Icf83c876d0880d1872b84e0a3d34be654b76149f Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-03-28crypto: add vnet_crypto_op_init (...)Damjan Marion1-0/+10
Change-Id: I2018d8367bb010e1ab30d9c7c23d9501fc38a2e5 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-03-27ipsec: compress ipsec_sa_t so data used by dataplane code fits in cachelineDamjan Marion1-4/+10
Change-Id: I81ecdf9fdcfcb017117b47dc031f93208e004d7c Signed-off-by: Damjan Marion <damarion@cisco.com> Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-03-26crypto: add set crypto handler CLIFilip Tehlar1-0/+5
Change-Id: I40124f8d6e529256b1ccc6eb78dda9c5119b8951 Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2019-03-26ipsec: esp-encrypt reworkDamjan Marion1-0/+1
Change-Id: Ibe7f806b9d600994e83c9f1be526fdb0a1ef1833 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-03-20crypto: add hmac truncate optionDamjan Marion1-1/+1
This reverts commit 785368e559dbdf50676f74f43f13423c817abb52. Change-Id: I782ac2be4e161790c73ccd4b08492e2188a6d79d Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-03-20tests: implement crypto tests per RFC2202Filip Tehlar1-0/+1
Change-Id: I18b30d5ee8aa60c34d52b7716b5feb7225cb0d59 Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2019-03-19crypto: introduce crypto infraDamjan Marion1-0/+163
Change-Id: Ibf320b3e7b054b686f3af9a55afd5d5bda9b1048 Signed-off-by: Damjan Marion <damarion@cisco.com> Signed-off-by: Filip Tehlar <ftehlar@cisco.com>