2017-06-14 21:37:39 +03:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2016-2017, Mellanox Technologies. All rights reserved.
|
|
|
|
* Copyright (c) 2016-2017, Dave Watson <davejwatson@fb.com>. All rights reserved.
|
|
|
|
*
|
|
|
|
* This software is available to you under a choice of one of two
|
|
|
|
* licenses. You may choose to be licensed under the terms of the GNU
|
|
|
|
* General Public License (GPL) Version 2, available from the file
|
|
|
|
* COPYING in the main directory of this source tree, or the
|
|
|
|
* OpenIB.org BSD license below:
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or
|
|
|
|
* without modification, are permitted provided that the following
|
|
|
|
* conditions are met:
|
|
|
|
*
|
|
|
|
* - Redistributions of source code must retain the above
|
|
|
|
* copyright notice, this list of conditions and the following
|
|
|
|
* disclaimer.
|
|
|
|
*
|
|
|
|
* - Redistributions in binary form must reproduce the above
|
|
|
|
* copyright notice, this list of conditions and the following
|
|
|
|
* disclaimer in the documentation and/or other materials
|
|
|
|
* provided with the distribution.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
|
|
|
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
|
|
|
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
|
|
|
|
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
|
|
|
|
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
|
|
|
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
|
|
* SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _TLS_OFFLOAD_H
|
|
|
|
#define _TLS_OFFLOAD_H
|
|
|
|
|
|
|
|
#include <linux/types.h>
|
2017-11-14 06:30:11 +03:00
|
|
|
#include <asm/byteorder.h>
|
2018-01-31 19:04:37 +03:00
|
|
|
#include <linux/crypto.h>
|
2017-11-14 06:30:11 +03:00
|
|
|
#include <linux/socket.h>
|
|
|
|
#include <linux/tcp.h>
|
2018-10-13 03:45:59 +03:00
|
|
|
#include <linux/skmsg.h>
|
2019-11-06 01:24:35 +03:00
|
|
|
#include <linux/mutex.h>
|
2019-06-06 00:11:39 +03:00
|
|
|
#include <linux/netdevice.h>
|
2019-08-30 13:25:47 +03:00
|
|
|
#include <linux/rcupdate.h>
|
2018-10-13 03:45:59 +03:00
|
|
|
|
2019-10-05 02:19:24 +03:00
|
|
|
#include <net/net_namespace.h>
|
2017-11-14 06:30:11 +03:00
|
|
|
#include <net/tcp.h>
|
tls: RX path for ktls
Add rx path for tls software implementation.
recvmsg, splice_read, and poll implemented.
An additional sockopt TLS_RX is added, with the same interface as
TLS_TX. Either TLX_RX or TLX_TX may be provided separately, or
together (with two different setsockopt calls with appropriate keys).
Control messages are passed via CMSG in a similar way to transmit.
If no cmsg buffer is passed, then only application data records
will be passed to userspace, and EIO is returned for other types of
alerts.
EBADMSG is passed for decryption errors, and EMSGSIZE is passed for
framing too big, and EBADMSG for framing too small (matching openssl
semantics). EINVAL is returned for TLS versions that do not match the
original setsockopt call. All are unrecoverable.
strparser is used to parse TLS framing. Decryption is done directly
in to userspace buffers if they are large enough to support it, otherwise
sk_cow_data is called (similar to ipsec), and buffers are decrypted in
place and copied. splice_read always decrypts in place, since no
buffers are provided to decrypt in to.
sk_poll is overridden, and only returns POLLIN if a full TLS message is
received. Otherwise we wait for strparser to finish reading a full frame.
Actual decryption is only done during recvmsg or splice_read calls.
Signed-off-by: Dave Watson <davejwatson@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 20:10:35 +03:00
|
|
|
#include <net/strparser.h>
|
2018-09-21 07:16:13 +03:00
|
|
|
#include <crypto/aead.h>
|
2017-06-14 21:37:39 +03:00
|
|
|
#include <uapi/linux/tls.h>
|
|
|
|
|
|
|
|
|
|
|
|
/* Maximum data size carried in a TLS record */
|
|
|
|
#define TLS_MAX_PAYLOAD_SIZE ((size_t)1 << 14)
|
|
|
|
|
|
|
|
#define TLS_HEADER_SIZE 5
|
|
|
|
#define TLS_NONCE_OFFSET TLS_HEADER_SIZE
|
|
|
|
|
|
|
|
#define TLS_CRYPTO_INFO_READY(info) ((info)->cipher_type)
|
|
|
|
|
|
|
|
#define TLS_RECORD_TYPE_DATA 0x17
|
|
|
|
|
|
|
|
#define TLS_AAD_SPACE_SIZE 13
|
2018-03-31 19:11:52 +03:00
|
|
|
|
2019-03-20 05:03:36 +03:00
|
|
|
#define MAX_IV_SIZE 16
|
2019-06-11 07:40:00 +03:00
|
|
|
#define TLS_MAX_REC_SEQ_SIZE 8
|
2019-03-20 05:03:36 +03:00
|
|
|
|
|
|
|
/* For AES-CCM, the full 16-bytes of IV is made of '4' fields of given sizes.
|
|
|
|
*
|
|
|
|
* IV[16] = b0[1] || implicit nonce[4] || explicit nonce[8] || length[3]
|
|
|
|
*
|
|
|
|
* The field 'length' is encoded in field 'b0' as '(length width - 1)'.
|
|
|
|
* Hence b0 contains (3 - 1) = 2.
|
|
|
|
*/
|
|
|
|
#define TLS_AES_CCM_IV_B0_BYTE 2
|
|
|
|
|
2019-10-05 02:19:24 +03:00
|
|
|
#define __TLS_INC_STATS(net, field) \
|
|
|
|
__SNMP_INC_STATS((net)->mib.tls_statistics, field)
|
|
|
|
#define TLS_INC_STATS(net, field) \
|
|
|
|
SNMP_INC_STATS((net)->mib.tls_statistics, field)
|
|
|
|
#define __TLS_DEC_STATS(net, field) \
|
|
|
|
__SNMP_DEC_STATS((net)->mib.tls_statistics, field)
|
|
|
|
#define TLS_DEC_STATS(net, field) \
|
|
|
|
SNMP_DEC_STATS((net)->mib.tls_statistics, field)
|
|
|
|
|
2018-07-13 14:33:43 +03:00
|
|
|
enum {
|
|
|
|
TLS_BASE,
|
|
|
|
TLS_SW,
|
|
|
|
TLS_HW,
|
|
|
|
TLS_HW_RECORD,
|
|
|
|
TLS_NUM_CONFIG,
|
|
|
|
};
|
|
|
|
|
2018-09-21 07:16:13 +03:00
|
|
|
/* TLS records are maintained in 'struct tls_rec'. It stores the memory pages
|
|
|
|
* allocated or mapped for each TLS record. After encryption, the records are
|
|
|
|
* stores in a linked list.
|
|
|
|
*/
|
|
|
|
struct tls_rec {
|
|
|
|
struct list_head list;
|
net/tls: Fixed race condition in async encryption
On processors with multi-engine crypto accelerators, it is possible that
multiple records get encrypted in parallel and their encryption
completion is notified to different cpus in multicore processor. This
leads to the situation where tls_encrypt_done() starts executing in
parallel on different cores. In current implementation, encrypted
records are queued to tx_ready_list in tls_encrypt_done(). This requires
addition to linked list 'tx_ready_list' to be protected. As
tls_decrypt_done() could be executing in irq content, it is not possible
to protect linked list addition operation using a lock.
To fix the problem, we remove linked list addition operation from the
irq context. We do tx_ready_list addition/removal operation from
application context only and get rid of possible multiple access to
the linked list. Before starting encryption on the record, we add it to
the tail of tx_ready_list. To prevent tls_tx_records() from transmitting
it, we mark the record with a new flag 'tx_ready' in 'struct tls_rec'.
When record encryption gets completed, tls_encrypt_done() has to only
update the 'tx_ready' flag to true & linked list add operation is not
required.
The changed logic brings some other side benefits. Since the records
are always submitted in tls sequence number order for encryption, the
tx_ready_list always remains sorted and addition of new records to it
does not have to traverse the linked list.
Lastly, we renamed tx_ready_list in 'struct tls_sw_context_tx' to
'tx_list'. This is because now, the some of the records at the tail are
not ready to transmit.
Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption")
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-09-24 13:05:56 +03:00
|
|
|
int tx_ready;
|
2018-09-21 07:16:13 +03:00
|
|
|
int tx_flags;
|
2017-06-14 21:37:39 +03:00
|
|
|
|
2018-10-13 03:45:59 +03:00
|
|
|
struct sk_msg msg_plaintext;
|
|
|
|
struct sk_msg msg_encrypted;
|
2018-09-21 07:16:13 +03:00
|
|
|
|
2018-10-13 03:45:59 +03:00
|
|
|
/* AAD | msg_plaintext.sg.data | sg_tag */
|
|
|
|
struct scatterlist sg_aead_in[2];
|
|
|
|
/* AAD | msg_encrypted.sg.data (data contains overhead for hdr & iv & tag) */
|
|
|
|
struct scatterlist sg_aead_out[2];
|
2018-09-21 07:16:13 +03:00
|
|
|
|
2019-01-31 00:58:31 +03:00
|
|
|
char content_type;
|
|
|
|
struct scatterlist sg_content_type;
|
|
|
|
|
2018-09-21 07:16:13 +03:00
|
|
|
char aad_space[TLS_AAD_SPACE_SIZE];
|
2019-03-20 05:03:36 +03:00
|
|
|
u8 iv_data[MAX_IV_SIZE];
|
2018-09-21 07:16:13 +03:00
|
|
|
struct aead_request aead_req;
|
|
|
|
u8 aead_req_ctx[];
|
|
|
|
};
|
|
|
|
|
2019-02-23 11:42:37 +03:00
|
|
|
struct tls_msg {
|
|
|
|
struct strp_msg rxm;
|
|
|
|
u8 control;
|
|
|
|
};
|
|
|
|
|
2018-09-21 07:16:13 +03:00
|
|
|
struct tx_work {
|
|
|
|
struct delayed_work work;
|
|
|
|
struct sock *sk;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct tls_sw_context_tx {
|
|
|
|
struct crypto_aead *aead_send;
|
|
|
|
struct crypto_wait async_wait;
|
|
|
|
struct tx_work tx_work;
|
|
|
|
struct tls_rec *open_rec;
|
net/tls: Fixed race condition in async encryption
On processors with multi-engine crypto accelerators, it is possible that
multiple records get encrypted in parallel and their encryption
completion is notified to different cpus in multicore processor. This
leads to the situation where tls_encrypt_done() starts executing in
parallel on different cores. In current implementation, encrypted
records are queued to tx_ready_list in tls_encrypt_done(). This requires
addition to linked list 'tx_ready_list' to be protected. As
tls_decrypt_done() could be executing in irq content, it is not possible
to protect linked list addition operation using a lock.
To fix the problem, we remove linked list addition operation from the
irq context. We do tx_ready_list addition/removal operation from
application context only and get rid of possible multiple access to
the linked list. Before starting encryption on the record, we add it to
the tail of tx_ready_list. To prevent tls_tx_records() from transmitting
it, we mark the record with a new flag 'tx_ready' in 'struct tls_rec'.
When record encryption gets completed, tls_encrypt_done() has to only
update the 'tx_ready' flag to true & linked list add operation is not
required.
The changed logic brings some other side benefits. Since the records
are always submitted in tls sequence number order for encryption, the
tx_ready_list always remains sorted and addition of new records to it
does not have to traverse the linked list.
Lastly, we renamed tx_ready_list in 'struct tls_sw_context_tx' to
'tx_list'. This is because now, the some of the records at the tail are
not ready to transmit.
Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption")
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-09-24 13:05:56 +03:00
|
|
|
struct list_head tx_list;
|
2018-09-21 07:16:13 +03:00
|
|
|
atomic_t encrypt_pending;
|
2020-05-22 23:10:31 +03:00
|
|
|
/* protect crypto_wait with encrypt_pending */
|
|
|
|
spinlock_t encrypt_compl_lock;
|
2018-09-21 07:16:13 +03:00
|
|
|
int async_notify;
|
2019-10-07 07:09:31 +03:00
|
|
|
u8 async_capable:1;
|
2018-09-21 07:16:13 +03:00
|
|
|
|
|
|
|
#define BIT_TX_SCHEDULED 0
|
2019-07-19 20:29:16 +03:00
|
|
|
#define BIT_TX_CLOSING 1
|
2018-09-21 07:16:13 +03:00
|
|
|
unsigned long tx_bitmask;
|
2017-06-14 21:37:39 +03:00
|
|
|
};
|
|
|
|
|
2018-04-30 10:16:15 +03:00
|
|
|
struct tls_sw_context_rx {
|
|
|
|
struct crypto_aead *aead_recv;
|
|
|
|
struct crypto_wait async_wait;
|
|
|
|
struct strparser strp;
|
2019-01-16 13:40:16 +03:00
|
|
|
struct sk_buff_head rx_list; /* list of decrypted 'data' records */
|
2018-04-30 10:16:15 +03:00
|
|
|
void (*saved_data_ready)(struct sock *sk);
|
2018-10-13 03:46:00 +03:00
|
|
|
|
2018-04-30 10:16:15 +03:00
|
|
|
struct sk_buff *recv_pkt;
|
|
|
|
u8 control;
|
2019-10-07 07:09:31 +03:00
|
|
|
u8 async_capable:1;
|
2019-10-07 07:09:32 +03:00
|
|
|
u8 decrypted:1;
|
2018-08-29 12:56:55 +03:00
|
|
|
atomic_t decrypt_pending;
|
2020-05-22 23:10:31 +03:00
|
|
|
/* protect crypto_wait with decrypt_pending*/
|
|
|
|
spinlock_t decrypt_compl_lock;
|
2018-08-29 12:56:55 +03:00
|
|
|
bool async_notify;
|
|
|
|
};
|
|
|
|
|
2018-04-30 10:16:16 +03:00
|
|
|
struct tls_record_info {
|
|
|
|
struct list_head list;
|
|
|
|
u32 end_seq;
|
|
|
|
int len;
|
|
|
|
int num_frags;
|
|
|
|
skb_frag_t frags[MAX_SKB_FRAGS];
|
|
|
|
};
|
|
|
|
|
2018-07-13 14:33:39 +03:00
|
|
|
struct tls_offload_context_tx {
|
2018-04-30 10:16:16 +03:00
|
|
|
struct crypto_aead *aead_send;
|
|
|
|
spinlock_t lock; /* protects records list */
|
|
|
|
struct list_head records_list;
|
|
|
|
struct tls_record_info *open_record;
|
|
|
|
struct tls_record_info *retransmit_hint;
|
|
|
|
u64 hint_record_sn;
|
|
|
|
u64 unacked_record_sn;
|
|
|
|
|
|
|
|
struct scatterlist sg_tx_data[MAX_SKB_FRAGS];
|
|
|
|
void (*sk_destruct)(struct sock *sk);
|
2019-06-06 00:11:39 +03:00
|
|
|
u8 driver_state[] __aligned(8);
|
2018-04-30 10:16:16 +03:00
|
|
|
/* The TLS layer reserves room for driver specific state
|
|
|
|
* Currently the belief is that there is not enough
|
|
|
|
* driver specific state to justify another layer of indirection
|
|
|
|
*/
|
2019-06-06 00:11:38 +03:00
|
|
|
#define TLS_DRIVER_STATE_SIZE_TX 16
|
2018-04-30 10:16:16 +03:00
|
|
|
};
|
|
|
|
|
2018-07-13 14:33:39 +03:00
|
|
|
#define TLS_OFFLOAD_CONTEXT_SIZE_TX \
|
2019-06-06 00:11:39 +03:00
|
|
|
(sizeof(struct tls_offload_context_tx) + TLS_DRIVER_STATE_SIZE_TX)
|
2018-04-30 10:16:16 +03:00
|
|
|
|
2019-06-04 22:00:12 +03:00
|
|
|
enum tls_context_flags {
|
|
|
|
TLS_RX_SYNC_RUNNING = 0,
|
2019-06-11 07:40:09 +03:00
|
|
|
/* Unlike RX where resync is driven entirely by the core in TX only
|
|
|
|
* the driver knows when things went out of sync, so we need the flag
|
|
|
|
* to be atomic.
|
|
|
|
*/
|
|
|
|
TLS_TX_SYNC_SCHED = 1,
|
2020-11-26 01:18:10 +03:00
|
|
|
/* tls_dev_del was called for the RX side, device state was released,
|
|
|
|
* but tls_ctx->netdev might still be kept, because TX-side driver
|
|
|
|
* resources might not be released yet. Used to prevent the second
|
|
|
|
* tls_dev_del call in tls_device_down if it happens simultaneously.
|
|
|
|
*/
|
|
|
|
TLS_RX_DEV_CLOSED = 2,
|
2019-06-04 22:00:12 +03:00
|
|
|
};
|
|
|
|
|
2018-03-22 20:10:06 +03:00
|
|
|
struct cipher_context {
|
|
|
|
char *iv;
|
|
|
|
char *rec_seq;
|
|
|
|
};
|
|
|
|
|
2018-09-12 18:44:42 +03:00
|
|
|
union tls_crypto_context {
|
|
|
|
struct tls_crypto_info info;
|
2019-01-31 00:58:05 +03:00
|
|
|
union {
|
|
|
|
struct tls12_crypto_info_aes_gcm_128 aes_gcm_128;
|
|
|
|
struct tls12_crypto_info_aes_gcm_256 aes_gcm_256;
|
2020-11-24 18:24:47 +03:00
|
|
|
struct tls12_crypto_info_chacha20_poly1305 chacha20_poly1305;
|
2019-01-31 00:58:05 +03:00
|
|
|
};
|
2018-09-12 18:44:42 +03:00
|
|
|
};
|
|
|
|
|
2019-02-14 10:11:35 +03:00
|
|
|
struct tls_prot_info {
|
|
|
|
u16 version;
|
|
|
|
u16 cipher_type;
|
|
|
|
u16 prepend_size;
|
|
|
|
u16 tag_size;
|
|
|
|
u16 overhead_size;
|
|
|
|
u16 iv_size;
|
2019-03-20 05:03:36 +03:00
|
|
|
u16 salt_size;
|
2019-02-14 10:11:35 +03:00
|
|
|
u16 rec_seq_size;
|
|
|
|
u16 aad_size;
|
|
|
|
u16 tail_size;
|
|
|
|
};
|
|
|
|
|
2017-06-14 21:37:39 +03:00
|
|
|
struct tls_context {
|
2019-06-04 01:17:04 +03:00
|
|
|
/* read-only cache line */
|
2019-02-14 10:11:35 +03:00
|
|
|
struct tls_prot_info prot_info;
|
|
|
|
|
2019-06-04 01:17:04 +03:00
|
|
|
u8 tx_conf:3;
|
|
|
|
u8 rx_conf:3;
|
2017-06-14 21:37:39 +03:00
|
|
|
|
2019-06-04 01:17:04 +03:00
|
|
|
int (*push_pending_record)(struct sock *sk, int flags);
|
|
|
|
void (*sk_write_space)(struct sock *sk);
|
2018-04-30 10:16:15 +03:00
|
|
|
|
|
|
|
void *priv_ctx_tx;
|
|
|
|
void *priv_ctx_rx;
|
2017-06-14 21:37:39 +03:00
|
|
|
|
2019-06-04 01:17:04 +03:00
|
|
|
struct net_device *netdev;
|
2017-11-13 11:22:45 +03:00
|
|
|
|
2019-06-04 01:17:04 +03:00
|
|
|
/* rw cache line */
|
2018-03-22 20:10:06 +03:00
|
|
|
struct cipher_context tx;
|
tls: RX path for ktls
Add rx path for tls software implementation.
recvmsg, splice_read, and poll implemented.
An additional sockopt TLS_RX is added, with the same interface as
TLS_TX. Either TLX_RX or TLX_TX may be provided separately, or
together (with two different setsockopt calls with appropriate keys).
Control messages are passed via CMSG in a similar way to transmit.
If no cmsg buffer is passed, then only application data records
will be passed to userspace, and EIO is returned for other types of
alerts.
EBADMSG is passed for decryption errors, and EMSGSIZE is passed for
framing too big, and EBADMSG for framing too small (matching openssl
semantics). EINVAL is returned for TLS versions that do not match the
original setsockopt call. All are unrecoverable.
strparser is used to parse TLS framing. Decryption is done directly
in to userspace buffers if they are large enough to support it, otherwise
sk_cow_data is called (similar to ipsec), and buffers are decrypted in
place and copied. splice_read always decrypts in place, since no
buffers are provided to decrypt in to.
sk_poll is overridden, and only returns POLLIN if a full TLS message is
received. Otherwise we wait for strparser to finish reading a full frame.
Actual decryption is only done during recvmsg or splice_read calls.
Signed-off-by: Dave Watson <davejwatson@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 20:10:35 +03:00
|
|
|
struct cipher_context rx;
|
2017-06-14 21:37:39 +03:00
|
|
|
|
|
|
|
struct scatterlist *partially_sent_record;
|
|
|
|
u16 partially_sent_offset;
|
2018-09-21 07:16:13 +03:00
|
|
|
|
2018-05-01 23:05:39 +03:00
|
|
|
bool in_tcp_sendpages;
|
2018-10-13 03:45:59 +03:00
|
|
|
bool pending_open_record_frags;
|
2019-11-06 01:24:35 +03:00
|
|
|
|
|
|
|
struct mutex tx_lock; /* protects partially_sent_* fields and
|
|
|
|
* per-type TX fields
|
|
|
|
*/
|
2019-06-04 01:17:04 +03:00
|
|
|
unsigned long flags;
|
2017-06-14 21:37:39 +03:00
|
|
|
|
2019-06-04 01:17:04 +03:00
|
|
|
/* cache cold stuff */
|
2019-07-19 20:29:18 +03:00
|
|
|
struct proto *sk_proto;
|
|
|
|
|
2018-07-13 14:33:43 +03:00
|
|
|
void (*sk_destruct)(struct sock *sk);
|
2019-06-04 01:17:04 +03:00
|
|
|
|
|
|
|
union tls_crypto_context crypto_send;
|
|
|
|
union tls_crypto_context crypto_recv;
|
|
|
|
|
|
|
|
struct list_head list;
|
|
|
|
refcount_t refcount;
|
2019-08-30 13:25:47 +03:00
|
|
|
struct rcu_head rcu;
|
2017-06-14 21:37:39 +03:00
|
|
|
};
|
|
|
|
|
2019-04-25 22:32:03 +03:00
|
|
|
enum tls_offload_ctx_dir {
|
|
|
|
TLS_OFFLOAD_CTX_DIR_RX,
|
|
|
|
TLS_OFFLOAD_CTX_DIR_TX,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct tlsdev_ops {
|
|
|
|
int (*tls_dev_add)(struct net_device *netdev, struct sock *sk,
|
|
|
|
enum tls_offload_ctx_dir direction,
|
|
|
|
struct tls_crypto_info *crypto_info,
|
|
|
|
u32 start_offload_tcp_sn);
|
|
|
|
void (*tls_dev_del)(struct net_device *netdev,
|
|
|
|
struct tls_context *ctx,
|
|
|
|
enum tls_offload_ctx_dir direction);
|
2019-07-09 05:53:13 +03:00
|
|
|
int (*tls_dev_resync)(struct net_device *netdev,
|
|
|
|
struct sock *sk, u32 seq, u8 *rcd_sn,
|
|
|
|
enum tls_offload_ctx_dir direction);
|
2019-04-25 22:32:03 +03:00
|
|
|
};
|
|
|
|
|
2019-06-11 07:40:02 +03:00
|
|
|
enum tls_offload_sync_type {
|
|
|
|
TLS_OFFLOAD_SYNC_TYPE_DRIVER_REQ = 0,
|
|
|
|
TLS_OFFLOAD_SYNC_TYPE_CORE_NEXT_HINT = 1,
|
net/tls: Add asynchronous resync
This patch adds support for asynchronous resynchronization in tls_device.
Async resync follows two distinct stages:
1. The NIC driver indicates that it would like to resync on some TLS
record within the received packet (P), but the driver does not
know (yet) which of the TLS records within the packet.
At this stage, the NIC driver will query the device to find the exact
TCP sequence for resync (tcpsn), however, the driver does not wait
for the device to provide the response.
2. Eventually, the device responds, and the driver provides the tcpsn
within the resync packet to KTLS. Now, KTLS can check the tcpsn against
any processed TLS records within packet P, and also against any record
that is processed in the future within packet P.
The asynchronous resync path simplifies the device driver, as it can
save bits on the packet completion (32-bit TCP sequence), and pass this
information on an asynchronous command instead.
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2020-06-08 19:11:38 +03:00
|
|
|
TLS_OFFLOAD_SYNC_TYPE_DRIVER_REQ_ASYNC = 2,
|
2019-06-11 07:40:02 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
#define TLS_DEVICE_RESYNC_NH_START_IVAL 2
|
|
|
|
#define TLS_DEVICE_RESYNC_NH_MAX_IVAL 128
|
|
|
|
|
net/tls: Add asynchronous resync
This patch adds support for asynchronous resynchronization in tls_device.
Async resync follows two distinct stages:
1. The NIC driver indicates that it would like to resync on some TLS
record within the received packet (P), but the driver does not
know (yet) which of the TLS records within the packet.
At this stage, the NIC driver will query the device to find the exact
TCP sequence for resync (tcpsn), however, the driver does not wait
for the device to provide the response.
2. Eventually, the device responds, and the driver provides the tcpsn
within the resync packet to KTLS. Now, KTLS can check the tcpsn against
any processed TLS records within packet P, and also against any record
that is processed in the future within packet P.
The asynchronous resync path simplifies the device driver, as it can
save bits on the packet completion (32-bit TCP sequence), and pass this
information on an asynchronous command instead.
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2020-06-08 19:11:38 +03:00
|
|
|
#define TLS_DEVICE_RESYNC_ASYNC_LOGMAX 13
|
|
|
|
struct tls_offload_resync_async {
|
|
|
|
atomic64_t req;
|
2020-11-15 16:14:48 +03:00
|
|
|
u16 loglen;
|
|
|
|
u16 rcd_delta;
|
net/tls: Add asynchronous resync
This patch adds support for asynchronous resynchronization in tls_device.
Async resync follows two distinct stages:
1. The NIC driver indicates that it would like to resync on some TLS
record within the received packet (P), but the driver does not
know (yet) which of the TLS records within the packet.
At this stage, the NIC driver will query the device to find the exact
TCP sequence for resync (tcpsn), however, the driver does not wait
for the device to provide the response.
2. Eventually, the device responds, and the driver provides the tcpsn
within the resync packet to KTLS. Now, KTLS can check the tcpsn against
any processed TLS records within packet P, and also against any record
that is processed in the future within packet P.
The asynchronous resync path simplifies the device driver, as it can
save bits on the packet completion (32-bit TCP sequence), and pass this
information on an asynchronous command instead.
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2020-06-08 19:11:38 +03:00
|
|
|
u32 log[TLS_DEVICE_RESYNC_ASYNC_LOGMAX];
|
|
|
|
};
|
|
|
|
|
2018-07-13 14:33:43 +03:00
|
|
|
struct tls_offload_context_rx {
|
|
|
|
/* sw must be the first member of tls_offload_context_rx */
|
|
|
|
struct tls_sw_context_rx sw;
|
2019-06-11 07:40:02 +03:00
|
|
|
enum tls_offload_sync_type resync_type;
|
|
|
|
/* this member is set regardless of resync_type, to avoid branches */
|
|
|
|
u8 resync_nh_reset:1;
|
|
|
|
/* CORE_NEXT_HINT-only member, but use the hole here */
|
|
|
|
u8 resync_nh_do_now:1;
|
|
|
|
union {
|
|
|
|
/* TLS_OFFLOAD_SYNC_TYPE_DRIVER_REQ */
|
|
|
|
struct {
|
|
|
|
atomic64_t resync_req;
|
|
|
|
};
|
|
|
|
/* TLS_OFFLOAD_SYNC_TYPE_CORE_NEXT_HINT */
|
|
|
|
struct {
|
|
|
|
u32 decrypted_failed;
|
|
|
|
u32 decrypted_tgt;
|
|
|
|
} resync_nh;
|
net/tls: Add asynchronous resync
This patch adds support for asynchronous resynchronization in tls_device.
Async resync follows two distinct stages:
1. The NIC driver indicates that it would like to resync on some TLS
record within the received packet (P), but the driver does not
know (yet) which of the TLS records within the packet.
At this stage, the NIC driver will query the device to find the exact
TCP sequence for resync (tcpsn), however, the driver does not wait
for the device to provide the response.
2. Eventually, the device responds, and the driver provides the tcpsn
within the resync packet to KTLS. Now, KTLS can check the tcpsn against
any processed TLS records within packet P, and also against any record
that is processed in the future within packet P.
The asynchronous resync path simplifies the device driver, as it can
save bits on the packet completion (32-bit TCP sequence), and pass this
information on an asynchronous command instead.
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2020-06-08 19:11:38 +03:00
|
|
|
/* TLS_OFFLOAD_SYNC_TYPE_DRIVER_REQ_ASYNC */
|
|
|
|
struct {
|
|
|
|
struct tls_offload_resync_async *resync_async;
|
|
|
|
};
|
2019-06-11 07:40:02 +03:00
|
|
|
};
|
2019-06-06 00:11:39 +03:00
|
|
|
u8 driver_state[] __aligned(8);
|
2018-07-13 14:33:43 +03:00
|
|
|
/* The TLS layer reserves room for driver specific state
|
|
|
|
* Currently the belief is that there is not enough
|
|
|
|
* driver specific state to justify another layer of indirection
|
|
|
|
*/
|
2019-06-06 00:11:38 +03:00
|
|
|
#define TLS_DRIVER_STATE_SIZE_RX 8
|
2018-07-13 14:33:43 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
#define TLS_OFFLOAD_CONTEXT_SIZE_RX \
|
2019-06-06 00:11:39 +03:00
|
|
|
(sizeof(struct tls_offload_context_rx) + TLS_DRIVER_STATE_SIZE_RX)
|
2018-07-13 14:33:43 +03:00
|
|
|
|
2019-10-03 21:18:57 +03:00
|
|
|
struct tls_context *tls_ctx_create(struct sock *sk);
|
2019-08-30 13:25:47 +03:00
|
|
|
void tls_ctx_free(struct sock *sk, struct tls_context *ctx);
|
2019-10-03 21:18:57 +03:00
|
|
|
void update_sk_prot(struct sock *sk, struct tls_context *ctx);
|
|
|
|
|
2017-06-14 21:37:39 +03:00
|
|
|
int wait_on_pending_writer(struct sock *sk, long *timeo);
|
|
|
|
int tls_sk_query(struct sock *sk, int optname, char __user *optval,
|
|
|
|
int __user *optlen);
|
|
|
|
int tls_sk_attach(struct sock *sk, int optname, char __user *optval,
|
|
|
|
unsigned int optlen);
|
|
|
|
|
tls: RX path for ktls
Add rx path for tls software implementation.
recvmsg, splice_read, and poll implemented.
An additional sockopt TLS_RX is added, with the same interface as
TLS_TX. Either TLX_RX or TLX_TX may be provided separately, or
together (with two different setsockopt calls with appropriate keys).
Control messages are passed via CMSG in a similar way to transmit.
If no cmsg buffer is passed, then only application data records
will be passed to userspace, and EIO is returned for other types of
alerts.
EBADMSG is passed for decryption errors, and EMSGSIZE is passed for
framing too big, and EBADMSG for framing too small (matching openssl
semantics). EINVAL is returned for TLS versions that do not match the
original setsockopt call. All are unrecoverable.
strparser is used to parse TLS framing. Decryption is done directly
in to userspace buffers if they are large enough to support it, otherwise
sk_cow_data is called (similar to ipsec), and buffers are decrypted in
place and copied. splice_read always decrypts in place, since no
buffers are provided to decrypt in to.
sk_poll is overridden, and only returns POLLIN if a full TLS message is
received. Otherwise we wait for strparser to finish reading a full frame.
Actual decryption is only done during recvmsg or splice_read calls.
Signed-off-by: Dave Watson <davejwatson@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 20:10:35 +03:00
|
|
|
int tls_set_sw_offload(struct sock *sk, struct tls_context *ctx, int tx);
|
2019-07-19 20:29:14 +03:00
|
|
|
void tls_sw_strparser_arm(struct sock *sk, struct tls_context *ctx);
|
2019-07-19 20:29:17 +03:00
|
|
|
void tls_sw_strparser_done(struct tls_context *tls_ctx);
|
2017-06-14 21:37:39 +03:00
|
|
|
int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size);
|
2019-11-18 18:40:51 +03:00
|
|
|
int tls_sw_sendpage_locked(struct sock *sk, struct page *page,
|
|
|
|
int offset, size_t size, int flags);
|
2017-06-14 21:37:39 +03:00
|
|
|
int tls_sw_sendpage(struct sock *sk, struct page *page,
|
|
|
|
int offset, size_t size, int flags);
|
2019-07-19 20:29:16 +03:00
|
|
|
void tls_sw_cancel_work_tx(struct tls_context *tls_ctx);
|
2019-07-19 20:29:17 +03:00
|
|
|
void tls_sw_release_resources_tx(struct sock *sk);
|
|
|
|
void tls_sw_free_ctx_tx(struct tls_context *tls_ctx);
|
2018-04-30 10:16:15 +03:00
|
|
|
void tls_sw_free_resources_rx(struct sock *sk);
|
2018-07-13 14:33:41 +03:00
|
|
|
void tls_sw_release_resources_rx(struct sock *sk);
|
2019-07-19 20:29:17 +03:00
|
|
|
void tls_sw_free_ctx_rx(struct tls_context *tls_ctx);
|
tls: RX path for ktls
Add rx path for tls software implementation.
recvmsg, splice_read, and poll implemented.
An additional sockopt TLS_RX is added, with the same interface as
TLS_TX. Either TLX_RX or TLX_TX may be provided separately, or
together (with two different setsockopt calls with appropriate keys).
Control messages are passed via CMSG in a similar way to transmit.
If no cmsg buffer is passed, then only application data records
will be passed to userspace, and EIO is returned for other types of
alerts.
EBADMSG is passed for decryption errors, and EMSGSIZE is passed for
framing too big, and EBADMSG for framing too small (matching openssl
semantics). EINVAL is returned for TLS versions that do not match the
original setsockopt call. All are unrecoverable.
strparser is used to parse TLS framing. Decryption is done directly
in to userspace buffers if they are large enough to support it, otherwise
sk_cow_data is called (similar to ipsec), and buffers are decrypted in
place and copied. splice_read always decrypts in place, since no
buffers are provided to decrypt in to.
sk_poll is overridden, and only returns POLLIN if a full TLS message is
received. Otherwise we wait for strparser to finish reading a full frame.
Actual decryption is only done during recvmsg or splice_read calls.
Signed-off-by: Dave Watson <davejwatson@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 20:10:35 +03:00
|
|
|
int tls_sw_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
|
|
|
|
int nonblock, int flags, int *addr_len);
|
2018-10-13 03:46:00 +03:00
|
|
|
bool tls_sw_stream_read(const struct sock *sk);
|
tls: RX path for ktls
Add rx path for tls software implementation.
recvmsg, splice_read, and poll implemented.
An additional sockopt TLS_RX is added, with the same interface as
TLS_TX. Either TLX_RX or TLX_TX may be provided separately, or
together (with two different setsockopt calls with appropriate keys).
Control messages are passed via CMSG in a similar way to transmit.
If no cmsg buffer is passed, then only application data records
will be passed to userspace, and EIO is returned for other types of
alerts.
EBADMSG is passed for decryption errors, and EMSGSIZE is passed for
framing too big, and EBADMSG for framing too small (matching openssl
semantics). EINVAL is returned for TLS versions that do not match the
original setsockopt call. All are unrecoverable.
strparser is used to parse TLS framing. Decryption is done directly
in to userspace buffers if they are large enough to support it, otherwise
sk_cow_data is called (similar to ipsec), and buffers are decrypted in
place and copied. splice_read always decrypts in place, since no
buffers are provided to decrypt in to.
sk_poll is overridden, and only returns POLLIN if a full TLS message is
received. Otherwise we wait for strparser to finish reading a full frame.
Actual decryption is only done during recvmsg or splice_read calls.
Signed-off-by: Dave Watson <davejwatson@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-22 20:10:35 +03:00
|
|
|
ssize_t tls_sw_splice_read(struct socket *sock, loff_t *ppos,
|
|
|
|
struct pipe_inode_info *pipe,
|
|
|
|
size_t len, unsigned int flags);
|
2017-06-14 21:37:39 +03:00
|
|
|
|
2018-04-30 10:16:16 +03:00
|
|
|
int tls_device_sendmsg(struct sock *sk, struct msghdr *msg, size_t size);
|
|
|
|
int tls_device_sendpage(struct sock *sk, struct page *page,
|
|
|
|
int offset, size_t size, int flags);
|
2018-09-21 07:16:13 +03:00
|
|
|
int tls_tx_records(struct sock *sk, int flags);
|
2018-04-30 10:16:16 +03:00
|
|
|
|
2018-07-13 14:33:39 +03:00
|
|
|
struct tls_record_info *tls_get_record(struct tls_offload_context_tx *context,
|
2018-04-30 10:16:16 +03:00
|
|
|
u32 seq, u64 *p_record_sn);
|
|
|
|
|
|
|
|
static inline bool tls_record_is_start_marker(struct tls_record_info *rec)
|
|
|
|
{
|
|
|
|
return rec->len == 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline u32 tls_record_start_seq(struct tls_record_info *rec)
|
|
|
|
{
|
|
|
|
return rec->end_seq - rec->len;
|
|
|
|
}
|
2017-06-14 21:37:39 +03:00
|
|
|
|
|
|
|
int tls_push_sg(struct sock *sk, struct tls_context *ctx,
|
|
|
|
struct scatterlist *sg, u16 first_offset,
|
|
|
|
int flags);
|
2018-09-21 07:16:13 +03:00
|
|
|
int tls_push_partial_record(struct sock *sk, struct tls_context *ctx,
|
|
|
|
int flags);
|
2019-11-27 23:16:44 +03:00
|
|
|
void tls_free_partial_record(struct sock *sk, struct tls_context *ctx);
|
2018-09-21 07:16:13 +03:00
|
|
|
|
2019-02-23 11:42:37 +03:00
|
|
|
static inline struct tls_msg *tls_msg(struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
return (struct tls_msg *)strp_msg(skb);
|
|
|
|
}
|
|
|
|
|
2019-02-27 18:38:03 +03:00
|
|
|
static inline bool tls_is_partially_sent_record(struct tls_context *ctx)
|
2017-06-14 21:37:39 +03:00
|
|
|
{
|
2019-02-27 18:38:03 +03:00
|
|
|
return !!ctx->partially_sent_record;
|
2017-06-14 21:37:39 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool tls_is_pending_open_record(struct tls_context *tls_ctx)
|
|
|
|
{
|
|
|
|
return tls_ctx->pending_open_record_frags;
|
|
|
|
}
|
|
|
|
|
net/tls: Fixed race condition in async encryption
On processors with multi-engine crypto accelerators, it is possible that
multiple records get encrypted in parallel and their encryption
completion is notified to different cpus in multicore processor. This
leads to the situation where tls_encrypt_done() starts executing in
parallel on different cores. In current implementation, encrypted
records are queued to tx_ready_list in tls_encrypt_done(). This requires
addition to linked list 'tx_ready_list' to be protected. As
tls_decrypt_done() could be executing in irq content, it is not possible
to protect linked list addition operation using a lock.
To fix the problem, we remove linked list addition operation from the
irq context. We do tx_ready_list addition/removal operation from
application context only and get rid of possible multiple access to
the linked list. Before starting encryption on the record, we add it to
the tail of tx_ready_list. To prevent tls_tx_records() from transmitting
it, we mark the record with a new flag 'tx_ready' in 'struct tls_rec'.
When record encryption gets completed, tls_encrypt_done() has to only
update the 'tx_ready' flag to true & linked list add operation is not
required.
The changed logic brings some other side benefits. Since the records
are always submitted in tls sequence number order for encryption, the
tx_ready_list always remains sorted and addition of new records to it
does not have to traverse the linked list.
Lastly, we renamed tx_ready_list in 'struct tls_sw_context_tx' to
'tx_list'. This is because now, the some of the records at the tail are
not ready to transmit.
Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption")
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-09-24 13:05:56 +03:00
|
|
|
static inline bool is_tx_ready(struct tls_sw_context_tx *ctx)
|
2018-09-21 07:16:13 +03:00
|
|
|
{
|
|
|
|
struct tls_rec *rec;
|
|
|
|
|
net/tls: Fixed race condition in async encryption
On processors with multi-engine crypto accelerators, it is possible that
multiple records get encrypted in parallel and their encryption
completion is notified to different cpus in multicore processor. This
leads to the situation where tls_encrypt_done() starts executing in
parallel on different cores. In current implementation, encrypted
records are queued to tx_ready_list in tls_encrypt_done(). This requires
addition to linked list 'tx_ready_list' to be protected. As
tls_decrypt_done() could be executing in irq content, it is not possible
to protect linked list addition operation using a lock.
To fix the problem, we remove linked list addition operation from the
irq context. We do tx_ready_list addition/removal operation from
application context only and get rid of possible multiple access to
the linked list. Before starting encryption on the record, we add it to
the tail of tx_ready_list. To prevent tls_tx_records() from transmitting
it, we mark the record with a new flag 'tx_ready' in 'struct tls_rec'.
When record encryption gets completed, tls_encrypt_done() has to only
update the 'tx_ready' flag to true & linked list add operation is not
required.
The changed logic brings some other side benefits. Since the records
are always submitted in tls sequence number order for encryption, the
tx_ready_list always remains sorted and addition of new records to it
does not have to traverse the linked list.
Lastly, we renamed tx_ready_list in 'struct tls_sw_context_tx' to
'tx_list'. This is because now, the some of the records at the tail are
not ready to transmit.
Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption")
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-09-24 13:05:56 +03:00
|
|
|
rec = list_first_entry(&ctx->tx_list, struct tls_rec, list);
|
2018-09-21 07:16:13 +03:00
|
|
|
if (!rec)
|
|
|
|
return false;
|
|
|
|
|
net/tls: Fixed race condition in async encryption
On processors with multi-engine crypto accelerators, it is possible that
multiple records get encrypted in parallel and their encryption
completion is notified to different cpus in multicore processor. This
leads to the situation where tls_encrypt_done() starts executing in
parallel on different cores. In current implementation, encrypted
records are queued to tx_ready_list in tls_encrypt_done(). This requires
addition to linked list 'tx_ready_list' to be protected. As
tls_decrypt_done() could be executing in irq content, it is not possible
to protect linked list addition operation using a lock.
To fix the problem, we remove linked list addition operation from the
irq context. We do tx_ready_list addition/removal operation from
application context only and get rid of possible multiple access to
the linked list. Before starting encryption on the record, we add it to
the tail of tx_ready_list. To prevent tls_tx_records() from transmitting
it, we mark the record with a new flag 'tx_ready' in 'struct tls_rec'.
When record encryption gets completed, tls_encrypt_done() has to only
update the 'tx_ready' flag to true & linked list add operation is not
required.
The changed logic brings some other side benefits. Since the records
are always submitted in tls sequence number order for encryption, the
tx_ready_list always remains sorted and addition of new records to it
does not have to traverse the linked list.
Lastly, we renamed tx_ready_list in 'struct tls_sw_context_tx' to
'tx_list'. This is because now, the some of the records at the tail are
not ready to transmit.
Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption")
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-09-24 13:05:56 +03:00
|
|
|
return READ_ONCE(rec->tx_ready);
|
2018-09-21 07:16:13 +03:00
|
|
|
}
|
|
|
|
|
2019-08-30 13:25:49 +03:00
|
|
|
static inline u16 tls_user_config(struct tls_context *ctx, bool tx)
|
|
|
|
{
|
|
|
|
u16 config = tx ? ctx->tx_conf : ctx->rx_conf;
|
|
|
|
|
|
|
|
switch (config) {
|
|
|
|
case TLS_BASE:
|
|
|
|
return TLS_CONF_BASE;
|
|
|
|
case TLS_SW:
|
|
|
|
return TLS_CONF_SW;
|
|
|
|
case TLS_HW:
|
|
|
|
return TLS_CONF_HW;
|
|
|
|
case TLS_HW_RECORD:
|
|
|
|
return TLS_CONF_HW_RECORD;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-07-13 14:33:43 +03:00
|
|
|
struct sk_buff *
|
|
|
|
tls_validate_xmit_skb(struct sock *sk, struct net_device *dev,
|
|
|
|
struct sk_buff *skb);
|
|
|
|
|
2018-04-30 10:16:16 +03:00
|
|
|
static inline bool tls_is_sk_tx_device_offloaded(struct sock *sk)
|
|
|
|
{
|
2018-07-13 14:33:43 +03:00
|
|
|
#ifdef CONFIG_SOCK_VALIDATE_XMIT
|
2019-04-09 03:59:50 +03:00
|
|
|
return sk_fullsock(sk) &&
|
2018-07-13 14:33:43 +03:00
|
|
|
(smp_load_acquire(&sk->sk_validate_xmit_skb) ==
|
|
|
|
&tls_validate_xmit_skb);
|
|
|
|
#else
|
|
|
|
return false;
|
|
|
|
#endif
|
2018-04-30 10:16:16 +03:00
|
|
|
}
|
|
|
|
|
2018-03-22 20:10:15 +03:00
|
|
|
static inline void tls_err_abort(struct sock *sk, int err)
|
2017-06-14 21:37:39 +03:00
|
|
|
{
|
2018-03-22 20:10:15 +03:00
|
|
|
sk->sk_err = err;
|
2017-06-14 21:37:39 +03:00
|
|
|
sk->sk_error_report(sk);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool tls_bigint_increment(unsigned char *seq, int len)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = len - 1; i >= 0; i--) {
|
|
|
|
++seq[i];
|
|
|
|
if (seq[i] != 0)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return (i == -1);
|
|
|
|
}
|
|
|
|
|
2020-11-15 16:14:48 +03:00
|
|
|
static inline void tls_bigint_subtract(unsigned char *seq, int n)
|
|
|
|
{
|
|
|
|
u64 rcd_sn;
|
|
|
|
__be64 *p;
|
|
|
|
|
|
|
|
BUILD_BUG_ON(TLS_MAX_REC_SEQ_SIZE != 8);
|
|
|
|
|
|
|
|
p = (__be64 *)seq;
|
|
|
|
rcd_sn = be64_to_cpu(*p);
|
|
|
|
*p = cpu_to_be64(rcd_sn - n);
|
|
|
|
}
|
|
|
|
|
2019-02-14 10:11:35 +03:00
|
|
|
static inline struct tls_context *tls_get_ctx(const struct sock *sk)
|
|
|
|
{
|
|
|
|
struct inet_connection_sock *icsk = inet_csk(sk);
|
|
|
|
|
2019-08-30 13:25:47 +03:00
|
|
|
/* Use RCU on icsk_ulp_data only for sock diag code,
|
|
|
|
* TLS data path doesn't need rcu_dereference().
|
|
|
|
*/
|
|
|
|
return (__force void *)icsk->icsk_ulp_data;
|
2019-02-14 10:11:35 +03:00
|
|
|
}
|
|
|
|
|
2017-06-14 21:37:39 +03:00
|
|
|
static inline void tls_advance_record_sn(struct sock *sk,
|
2019-06-04 01:17:05 +03:00
|
|
|
struct tls_prot_info *prot,
|
|
|
|
struct cipher_context *ctx)
|
2017-06-14 21:37:39 +03:00
|
|
|
{
|
2019-02-14 10:11:35 +03:00
|
|
|
if (tls_bigint_increment(ctx->rec_seq, prot->rec_seq_size))
|
2018-03-22 20:10:15 +03:00
|
|
|
tls_err_abort(sk, EBADMSG);
|
2019-01-31 00:58:31 +03:00
|
|
|
|
2020-11-24 18:24:48 +03:00
|
|
|
if (prot->version != TLS_1_3_VERSION &&
|
|
|
|
prot->cipher_type != TLS_CIPHER_CHACHA20_POLY1305)
|
2020-11-24 18:24:46 +03:00
|
|
|
tls_bigint_increment(ctx->iv + prot->salt_size,
|
2019-02-14 10:11:35 +03:00
|
|
|
prot->iv_size);
|
2017-06-14 21:37:39 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tls_fill_prepend(struct tls_context *ctx,
|
|
|
|
char *buf,
|
|
|
|
size_t plaintext_len,
|
2020-11-24 18:24:46 +03:00
|
|
|
unsigned char record_type)
|
2017-06-14 21:37:39 +03:00
|
|
|
{
|
2019-02-14 10:11:35 +03:00
|
|
|
struct tls_prot_info *prot = &ctx->prot_info;
|
|
|
|
size_t pkt_len, iv_size = prot->iv_size;
|
2017-06-14 21:37:39 +03:00
|
|
|
|
2019-02-14 10:11:35 +03:00
|
|
|
pkt_len = plaintext_len + prot->tag_size;
|
2020-11-24 18:24:48 +03:00
|
|
|
if (prot->version != TLS_1_3_VERSION &&
|
|
|
|
prot->cipher_type != TLS_CIPHER_CHACHA20_POLY1305) {
|
2019-01-31 00:58:31 +03:00
|
|
|
pkt_len += iv_size;
|
|
|
|
|
|
|
|
memcpy(buf + TLS_NONCE_OFFSET,
|
2020-11-24 18:24:46 +03:00
|
|
|
ctx->tx.iv + prot->salt_size, iv_size);
|
2019-01-31 00:58:31 +03:00
|
|
|
}
|
2017-06-14 21:37:39 +03:00
|
|
|
|
|
|
|
/* we cover nonce explicit here as well, so buf should be of
|
|
|
|
* size KTLS_DTLS_HEADER_SIZE + KTLS_DTLS_NONCE_EXPLICIT_SIZE
|
|
|
|
*/
|
2020-11-24 18:24:46 +03:00
|
|
|
buf[0] = prot->version == TLS_1_3_VERSION ?
|
2019-01-31 00:58:31 +03:00
|
|
|
TLS_RECORD_TYPE_DATA : record_type;
|
|
|
|
/* Note that VERSION must be TLS_1_2 for both TLS1.2 and TLS1.3 */
|
|
|
|
buf[1] = TLS_1_2_VERSION_MINOR;
|
|
|
|
buf[2] = TLS_1_2_VERSION_MAJOR;
|
2017-06-14 21:37:39 +03:00
|
|
|
/* we can use IV for nonce explicit according to spec */
|
|
|
|
buf[3] = pkt_len >> 8;
|
|
|
|
buf[4] = pkt_len & 0xFF;
|
|
|
|
}
|
|
|
|
|
2017-11-13 11:22:47 +03:00
|
|
|
static inline void tls_make_aad(char *buf,
|
|
|
|
size_t size,
|
|
|
|
char *record_sequence,
|
2019-01-31 00:58:31 +03:00
|
|
|
unsigned char record_type,
|
2020-11-24 18:24:46 +03:00
|
|
|
struct tls_prot_info *prot)
|
2019-01-31 00:58:31 +03:00
|
|
|
{
|
2020-11-24 18:24:46 +03:00
|
|
|
if (prot->version != TLS_1_3_VERSION) {
|
|
|
|
memcpy(buf, record_sequence, prot->rec_seq_size);
|
2019-01-31 00:58:31 +03:00
|
|
|
buf += 8;
|
|
|
|
} else {
|
2020-11-24 18:24:46 +03:00
|
|
|
size += prot->tag_size;
|
2019-01-31 00:58:31 +03:00
|
|
|
}
|
|
|
|
|
2020-11-24 18:24:46 +03:00
|
|
|
buf[0] = prot->version == TLS_1_3_VERSION ?
|
2019-01-31 00:58:31 +03:00
|
|
|
TLS_RECORD_TYPE_DATA : record_type;
|
|
|
|
buf[1] = TLS_1_2_VERSION_MAJOR;
|
|
|
|
buf[2] = TLS_1_2_VERSION_MINOR;
|
|
|
|
buf[3] = size >> 8;
|
|
|
|
buf[4] = size & 0xFF;
|
|
|
|
}
|
|
|
|
|
2020-11-24 18:24:46 +03:00
|
|
|
static inline void xor_iv_with_seq(struct tls_prot_info *prot, char *iv, char *seq)
|
2017-11-13 11:22:47 +03:00
|
|
|
{
|
2019-01-31 00:58:31 +03:00
|
|
|
int i;
|
2017-11-13 11:22:47 +03:00
|
|
|
|
2020-11-24 18:24:48 +03:00
|
|
|
if (prot->version == TLS_1_3_VERSION ||
|
|
|
|
prot->cipher_type == TLS_CIPHER_CHACHA20_POLY1305) {
|
2019-01-31 00:58:31 +03:00
|
|
|
for (i = 0; i < 8; i++)
|
|
|
|
iv[i + 4] ^= seq[i];
|
|
|
|
}
|
2017-11-13 11:22:47 +03:00
|
|
|
}
|
|
|
|
|
2017-06-14 21:37:39 +03:00
|
|
|
|
2018-04-30 10:16:15 +03:00
|
|
|
static inline struct tls_sw_context_rx *tls_sw_ctx_rx(
|
|
|
|
const struct tls_context *tls_ctx)
|
|
|
|
{
|
|
|
|
return (struct tls_sw_context_rx *)tls_ctx->priv_ctx_rx;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct tls_sw_context_tx *tls_sw_ctx_tx(
|
2017-06-14 21:37:39 +03:00
|
|
|
const struct tls_context *tls_ctx)
|
|
|
|
{
|
2018-04-30 10:16:15 +03:00
|
|
|
return (struct tls_sw_context_tx *)tls_ctx->priv_ctx_tx;
|
2017-06-14 21:37:39 +03:00
|
|
|
}
|
|
|
|
|
2018-07-13 14:33:39 +03:00
|
|
|
static inline struct tls_offload_context_tx *
|
|
|
|
tls_offload_ctx_tx(const struct tls_context *tls_ctx)
|
2017-06-14 21:37:39 +03:00
|
|
|
{
|
2018-07-13 14:33:39 +03:00
|
|
|
return (struct tls_offload_context_tx *)tls_ctx->priv_ctx_tx;
|
2017-06-14 21:37:39 +03:00
|
|
|
}
|
|
|
|
|
bpf: sk_msg, sock{map|hash} redirect through ULP
A sockmap program that redirects through a kTLS ULP enabled socket
will not work correctly because the ULP layer is skipped. This
fixes the behavior to call through the ULP layer on redirect to
ensure any operations required on the data stream at the ULP layer
continue to be applied.
To do this we add an internal flag MSG_SENDPAGE_NOPOLICY to avoid
calling the BPF layer on a redirected message. This is
required to avoid calling the BPF layer multiple times (possibly
recursively) which is not the current/expected behavior without
ULPs. In the future we may add a redirect flag if users _do_
want the policy applied again but this would need to work for both
ULP and non-ULP sockets and be opt-in to avoid breaking existing
programs.
Also to avoid polluting the flag space with an internal flag we
reuse the flag space overlapping MSG_SENDPAGE_NOPOLICY with
MSG_WAITFORONE. Here WAITFORONE is specific to recv path and
SENDPAGE_NOPOLICY is only used for sendpage hooks. The last thing
to verify is user space API is masked correctly to ensure the flag
can not be set by user. (Note this needs to be true regardless
because we have internal flags already in-use that user space
should not be able to set). But for completeness we have two UAPI
paths into sendpage, sendfile and splice.
In the sendfile case the function do_sendfile() zero's flags,
./fs/read_write.c:
static ssize_t do_sendfile(int out_fd, int in_fd, loff_t *ppos,
size_t count, loff_t max)
{
...
fl = 0;
#if 0
/*
* We need to debate whether we can enable this or not. The
* man page documents EAGAIN return for the output at least,
* and the application is arguably buggy if it doesn't expect
* EAGAIN on a non-blocking file descriptor.
*/
if (in.file->f_flags & O_NONBLOCK)
fl = SPLICE_F_NONBLOCK;
#endif
file_start_write(out.file);
retval = do_splice_direct(in.file, &pos, out.file, &out_pos, count, fl);
}
In the splice case the pipe_to_sendpage "actor" is used which
masks flags with SPLICE_F_MORE.
./fs/splice.c:
static int pipe_to_sendpage(struct pipe_inode_info *pipe,
struct pipe_buffer *buf, struct splice_desc *sd)
{
...
more = (sd->flags & SPLICE_F_MORE) ? MSG_MORE : 0;
...
}
Confirming what we expect that internal flags are in fact internal
to socket side.
Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling")
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-12-20 22:35:35 +03:00
|
|
|
static inline bool tls_sw_has_ctx_tx(const struct sock *sk)
|
|
|
|
{
|
|
|
|
struct tls_context *ctx = tls_get_ctx(sk);
|
|
|
|
|
|
|
|
if (!ctx)
|
|
|
|
return false;
|
|
|
|
return !!tls_sw_ctx_tx(ctx);
|
|
|
|
}
|
|
|
|
|
2020-05-30 02:06:59 +03:00
|
|
|
static inline bool tls_sw_has_ctx_rx(const struct sock *sk)
|
|
|
|
{
|
|
|
|
struct tls_context *ctx = tls_get_ctx(sk);
|
|
|
|
|
|
|
|
if (!ctx)
|
|
|
|
return false;
|
|
|
|
return !!tls_sw_ctx_rx(ctx);
|
|
|
|
}
|
|
|
|
|
2019-02-27 18:38:04 +03:00
|
|
|
void tls_sw_write_space(struct sock *sk, struct tls_context *ctx);
|
|
|
|
void tls_device_write_space(struct sock *sk, struct tls_context *ctx);
|
|
|
|
|
2018-07-13 14:33:43 +03:00
|
|
|
static inline struct tls_offload_context_rx *
|
|
|
|
tls_offload_ctx_rx(const struct tls_context *tls_ctx)
|
|
|
|
{
|
|
|
|
return (struct tls_offload_context_rx *)tls_ctx->priv_ctx_rx;
|
|
|
|
}
|
|
|
|
|
2019-06-06 00:11:39 +03:00
|
|
|
#if IS_ENABLED(CONFIG_TLS_DEVICE)
|
|
|
|
static inline void *__tls_driver_ctx(struct tls_context *tls_ctx,
|
|
|
|
enum tls_offload_ctx_dir direction)
|
|
|
|
{
|
|
|
|
if (direction == TLS_OFFLOAD_CTX_DIR_TX)
|
|
|
|
return tls_offload_ctx_tx(tls_ctx)->driver_state;
|
|
|
|
else
|
|
|
|
return tls_offload_ctx_rx(tls_ctx)->driver_state;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void *
|
|
|
|
tls_driver_ctx(const struct sock *sk, enum tls_offload_ctx_dir direction)
|
|
|
|
{
|
|
|
|
return __tls_driver_ctx(tls_get_ctx(sk), direction);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
net/tls: Add asynchronous resync
This patch adds support for asynchronous resynchronization in tls_device.
Async resync follows two distinct stages:
1. The NIC driver indicates that it would like to resync on some TLS
record within the received packet (P), but the driver does not
know (yet) which of the TLS records within the packet.
At this stage, the NIC driver will query the device to find the exact
TCP sequence for resync (tcpsn), however, the driver does not wait
for the device to provide the response.
2. Eventually, the device responds, and the driver provides the tcpsn
within the resync packet to KTLS. Now, KTLS can check the tcpsn against
any processed TLS records within packet P, and also against any record
that is processed in the future within packet P.
The asynchronous resync path simplifies the device driver, as it can
save bits on the packet completion (32-bit TCP sequence), and pass this
information on an asynchronous command instead.
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2020-06-08 19:11:38 +03:00
|
|
|
#define RESYNC_REQ BIT(0)
|
|
|
|
#define RESYNC_REQ_ASYNC BIT(1)
|
2018-07-13 14:33:43 +03:00
|
|
|
/* The TLS context is valid until sk_destruct is called */
|
|
|
|
static inline void tls_offload_rx_resync_request(struct sock *sk, __be32 seq)
|
|
|
|
{
|
|
|
|
struct tls_context *tls_ctx = tls_get_ctx(sk);
|
|
|
|
struct tls_offload_context_rx *rx_ctx = tls_offload_ctx_rx(tls_ctx);
|
|
|
|
|
net/tls: Add asynchronous resync
This patch adds support for asynchronous resynchronization in tls_device.
Async resync follows two distinct stages:
1. The NIC driver indicates that it would like to resync on some TLS
record within the received packet (P), but the driver does not
know (yet) which of the TLS records within the packet.
At this stage, the NIC driver will query the device to find the exact
TCP sequence for resync (tcpsn), however, the driver does not wait
for the device to provide the response.
2. Eventually, the device responds, and the driver provides the tcpsn
within the resync packet to KTLS. Now, KTLS can check the tcpsn against
any processed TLS records within packet P, and also against any record
that is processed in the future within packet P.
The asynchronous resync path simplifies the device driver, as it can
save bits on the packet completion (32-bit TCP sequence), and pass this
information on an asynchronous command instead.
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2020-06-08 19:11:38 +03:00
|
|
|
atomic64_set(&rx_ctx->resync_req, ((u64)ntohl(seq) << 32) | RESYNC_REQ);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Log all TLS record header TCP sequences in [seq, seq+len] */
|
|
|
|
static inline void
|
|
|
|
tls_offload_rx_resync_async_request_start(struct sock *sk, __be32 seq, u16 len)
|
|
|
|
{
|
|
|
|
struct tls_context *tls_ctx = tls_get_ctx(sk);
|
|
|
|
struct tls_offload_context_rx *rx_ctx = tls_offload_ctx_rx(tls_ctx);
|
|
|
|
|
|
|
|
atomic64_set(&rx_ctx->resync_async->req, ((u64)ntohl(seq) << 32) |
|
2020-06-30 17:27:46 +03:00
|
|
|
((u64)len << 16) | RESYNC_REQ | RESYNC_REQ_ASYNC);
|
net/tls: Add asynchronous resync
This patch adds support for asynchronous resynchronization in tls_device.
Async resync follows two distinct stages:
1. The NIC driver indicates that it would like to resync on some TLS
record within the received packet (P), but the driver does not
know (yet) which of the TLS records within the packet.
At this stage, the NIC driver will query the device to find the exact
TCP sequence for resync (tcpsn), however, the driver does not wait
for the device to provide the response.
2. Eventually, the device responds, and the driver provides the tcpsn
within the resync packet to KTLS. Now, KTLS can check the tcpsn against
any processed TLS records within packet P, and also against any record
that is processed in the future within packet P.
The asynchronous resync path simplifies the device driver, as it can
save bits on the packet completion (32-bit TCP sequence), and pass this
information on an asynchronous command instead.
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2020-06-08 19:11:38 +03:00
|
|
|
rx_ctx->resync_async->loglen = 0;
|
2020-11-15 16:14:48 +03:00
|
|
|
rx_ctx->resync_async->rcd_delta = 0;
|
net/tls: Add asynchronous resync
This patch adds support for asynchronous resynchronization in tls_device.
Async resync follows two distinct stages:
1. The NIC driver indicates that it would like to resync on some TLS
record within the received packet (P), but the driver does not
know (yet) which of the TLS records within the packet.
At this stage, the NIC driver will query the device to find the exact
TCP sequence for resync (tcpsn), however, the driver does not wait
for the device to provide the response.
2. Eventually, the device responds, and the driver provides the tcpsn
within the resync packet to KTLS. Now, KTLS can check the tcpsn against
any processed TLS records within packet P, and also against any record
that is processed in the future within packet P.
The asynchronous resync path simplifies the device driver, as it can
save bits on the packet completion (32-bit TCP sequence), and pass this
information on an asynchronous command instead.
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2020-06-08 19:11:38 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
tls_offload_rx_resync_async_request_end(struct sock *sk, __be32 seq)
|
|
|
|
{
|
|
|
|
struct tls_context *tls_ctx = tls_get_ctx(sk);
|
|
|
|
struct tls_offload_context_rx *rx_ctx = tls_offload_ctx_rx(tls_ctx);
|
|
|
|
|
|
|
|
atomic64_set(&rx_ctx->resync_async->req,
|
|
|
|
((u64)ntohl(seq) << 32) | RESYNC_REQ);
|
2018-07-13 14:33:43 +03:00
|
|
|
}
|
|
|
|
|
2019-06-11 07:40:02 +03:00
|
|
|
static inline void
|
|
|
|
tls_offload_rx_resync_set_type(struct sock *sk, enum tls_offload_sync_type type)
|
|
|
|
{
|
|
|
|
struct tls_context *tls_ctx = tls_get_ctx(sk);
|
|
|
|
|
|
|
|
tls_offload_ctx_rx(tls_ctx)->resync_type = type;
|
|
|
|
}
|
2018-07-13 14:33:43 +03:00
|
|
|
|
2019-06-11 07:40:09 +03:00
|
|
|
/* Driver's seq tracking has to be disabled until resync succeeded */
|
|
|
|
static inline bool tls_offload_tx_resync_pending(struct sock *sk)
|
|
|
|
{
|
|
|
|
struct tls_context *tls_ctx = tls_get_ctx(sk);
|
|
|
|
bool ret;
|
|
|
|
|
|
|
|
ret = test_bit(TLS_TX_SYNC_SCHED, &tls_ctx->flags);
|
|
|
|
smp_mb__after_atomic();
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-10-05 02:19:24 +03:00
|
|
|
int __net_init tls_proc_init(struct net *net);
|
|
|
|
void __net_exit tls_proc_fini(struct net *net);
|
|
|
|
|
2017-06-14 21:37:39 +03:00
|
|
|
int tls_proccess_cmsg(struct sock *sk, struct msghdr *msg,
|
|
|
|
unsigned char *record_type);
|
2018-07-13 14:33:40 +03:00
|
|
|
int decrypt_skb(struct sock *sk, struct sk_buff *skb,
|
|
|
|
struct scatterlist *sgout);
|
2019-06-06 00:11:40 +03:00
|
|
|
struct sk_buff *tls_encrypt_skb(struct sk_buff *skb);
|
2017-06-14 21:37:39 +03:00
|
|
|
|
2018-04-30 10:16:16 +03:00
|
|
|
int tls_sw_fallback_init(struct sock *sk,
|
2018-07-13 14:33:39 +03:00
|
|
|
struct tls_offload_context_tx *offload_ctx,
|
2018-04-30 10:16:16 +03:00
|
|
|
struct tls_crypto_info *crypto_info);
|
|
|
|
|
2019-09-03 07:31:05 +03:00
|
|
|
#ifdef CONFIG_TLS_DEVICE
|
|
|
|
void tls_device_init(void);
|
|
|
|
void tls_device_cleanup(void);
|
2019-12-18 01:12:01 +03:00
|
|
|
void tls_device_sk_destruct(struct sock *sk);
|
2019-09-03 07:31:05 +03:00
|
|
|
int tls_set_device_offload(struct sock *sk, struct tls_context *ctx);
|
|
|
|
void tls_device_free_resources_tx(struct sock *sk);
|
2018-07-13 14:33:43 +03:00
|
|
|
int tls_set_device_offload_rx(struct sock *sk, struct tls_context *ctx);
|
|
|
|
void tls_device_offload_cleanup_rx(struct sock *sk);
|
2019-06-11 07:40:02 +03:00
|
|
|
void tls_device_rx_resync_new_rec(struct sock *sk, u32 rcd_len, u32 seq);
|
2019-10-05 02:19:22 +03:00
|
|
|
void tls_offload_tx_resync_request(struct sock *sk, u32 got_seq, u32 exp_seq);
|
2019-10-07 07:09:30 +03:00
|
|
|
int tls_device_decrypted(struct sock *sk, struct tls_context *tls_ctx,
|
|
|
|
struct sk_buff *skb, struct strp_msg *rxm);
|
2019-12-18 01:12:01 +03:00
|
|
|
|
|
|
|
static inline bool tls_is_sk_rx_device_offloaded(struct sock *sk)
|
|
|
|
{
|
|
|
|
if (!sk_fullsock(sk) ||
|
|
|
|
smp_load_acquire(&sk->sk_destruct) != tls_device_sk_destruct)
|
|
|
|
return false;
|
|
|
|
return tls_get_ctx(sk)->rx_conf == TLS_HW;
|
|
|
|
}
|
2019-09-03 07:31:05 +03:00
|
|
|
#else
|
|
|
|
static inline void tls_device_init(void) {}
|
|
|
|
static inline void tls_device_cleanup(void) {}
|
2018-07-13 14:33:43 +03:00
|
|
|
|
2019-09-03 07:31:05 +03:00
|
|
|
static inline int
|
|
|
|
tls_set_device_offload(struct sock *sk, struct tls_context *ctx)
|
|
|
|
{
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tls_device_free_resources_tx(struct sock *sk) {}
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
tls_set_device_offload_rx(struct sock *sk, struct tls_context *ctx)
|
|
|
|
{
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tls_device_offload_cleanup_rx(struct sock *sk) {}
|
|
|
|
static inline void
|
|
|
|
tls_device_rx_resync_new_rec(struct sock *sk, u32 rcd_len, u32 seq) {}
|
|
|
|
|
2019-10-07 07:09:30 +03:00
|
|
|
static inline int
|
|
|
|
tls_device_decrypted(struct sock *sk, struct tls_context *tls_ctx,
|
|
|
|
struct sk_buff *skb, struct strp_msg *rxm)
|
2019-09-03 07:31:05 +03:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|
2017-06-14 21:37:39 +03:00
|
|
|
#endif /* _TLS_OFFLOAD_H */
|