^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. _kernel_tls:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ==========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) Kernel TLS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) ==========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) Overview
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) ========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) Transport Layer Security (TLS) is a Upper Layer Protocol (ULP) that runs over
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) TCP. TLS provides end-to-end data integrity and confidentiality.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) User interface
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) Creating a TLS connection
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) -------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) First create a new TCP socket and set the TLS ULP.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) sock = socket(AF_INET, SOCK_STREAM, 0);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) Setting the TLS ULP allows us to set/get TLS socket options. Currently
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) only the symmetric encryption is handled in the kernel. After the TLS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) handshake is complete, we have all the parameters required to move the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) data-path to the kernel. There is a separate socket option for moving
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) the transmit and the receive into the kernel.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) /* From linux/tls.h */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) struct tls_crypto_info {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) unsigned short version;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) unsigned short cipher_type;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) struct tls12_crypto_info_aes_gcm_128 {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) struct tls_crypto_info info;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) unsigned char iv[TLS_CIPHER_AES_GCM_128_IV_SIZE];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) unsigned char key[TLS_CIPHER_AES_GCM_128_KEY_SIZE];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) unsigned char salt[TLS_CIPHER_AES_GCM_128_SALT_SIZE];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) unsigned char rec_seq[TLS_CIPHER_AES_GCM_128_REC_SEQ_SIZE];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) struct tls12_crypto_info_aes_gcm_128 crypto_info;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) crypto_info.info.version = TLS_1_2_VERSION;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) crypto_info.info.cipher_type = TLS_CIPHER_AES_GCM_128;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) memcpy(crypto_info.iv, iv_write, TLS_CIPHER_AES_GCM_128_IV_SIZE);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) memcpy(crypto_info.rec_seq, seq_number_write,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) TLS_CIPHER_AES_GCM_128_REC_SEQ_SIZE);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) memcpy(crypto_info.key, cipher_key_write, TLS_CIPHER_AES_GCM_128_KEY_SIZE);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) memcpy(crypto_info.salt, implicit_iv_write, TLS_CIPHER_AES_GCM_128_SALT_SIZE);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) setsockopt(sock, SOL_TLS, TLS_TX, &crypto_info, sizeof(crypto_info));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) Transmit and receive are set separately, but the setup is the same, using either
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) TLS_TX or TLS_RX.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) Sending TLS application data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) ----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) After setting the TLS_TX socket option all application data sent over this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) socket is encrypted using TLS and the parameters provided in the socket option.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) For example, we can send an encrypted hello world record as follows:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) const char *msg = "hello world\n";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) send(sock, msg, strlen(msg));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) send() data is directly encrypted from the userspace buffer provided
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) to the encrypted kernel send buffer if possible.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) The sendfile system call will send the file's data over TLS records of maximum
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) length (2^14).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) file = open(filename, O_RDONLY);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) fstat(file, &stat);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) sendfile(sock, file, &offset, stat.st_size);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) TLS records are created and sent after each send() call, unless
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) MSG_MORE is passed. MSG_MORE will delay creation of a record until
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) MSG_MORE is not passed, or the maximum record size is reached.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) The kernel will need to allocate a buffer for the encrypted data.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) This buffer is allocated at the time send() is called, such that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) either the entire send() call will return -ENOMEM (or block waiting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) for memory), or the encryption will always succeed. If send() returns
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) -ENOMEM and some data was left on the socket buffer from a previous
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) call using MSG_MORE, the MSG_MORE data is left on the socket buffer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) Receiving TLS application data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) ------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) After setting the TLS_RX socket option, all recv family socket calls
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) are decrypted using TLS parameters provided. A full TLS record must
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) be received before decryption can happen.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) char buffer[16384];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) recv(sock, buffer, 16384);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) Received data is decrypted directly in to the user buffer if it is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) large enough, and no additional allocations occur. If the userspace
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) buffer is too small, data is decrypted in the kernel and copied to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) userspace.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) ``EINVAL`` is returned if the TLS version in the received message does not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) match the version passed in setsockopt.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) ``EMSGSIZE`` is returned if the received message is too big.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) ``EBADMSG`` is returned if decryption failed for any other reason.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) Send TLS control messages
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) -------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) Other than application data, TLS has control messages such as alert
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) messages (record type 21) and handshake messages (record type 22), etc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) These messages can be sent over the socket by providing the TLS record type
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) via a CMSG. For example the following function sends @data of @length bytes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) using a record of type @record_type.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) /* send TLS control message using record_type */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) static int klts_send_ctrl_message(int sock, unsigned char record_type,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) void *data, size_t length)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) struct msghdr msg = {0};
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) int cmsg_len = sizeof(record_type);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) struct cmsghdr *cmsg;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) char buf[CMSG_SPACE(cmsg_len)];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) struct iovec msg_iov; /* Vector of data to send/receive into. */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) msg.msg_control = buf;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) msg.msg_controllen = sizeof(buf);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) cmsg = CMSG_FIRSTHDR(&msg);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) cmsg->cmsg_level = SOL_TLS;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) cmsg->cmsg_type = TLS_SET_RECORD_TYPE;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) cmsg->cmsg_len = CMSG_LEN(cmsg_len);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) *CMSG_DATA(cmsg) = record_type;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) msg.msg_controllen = cmsg->cmsg_len;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) msg_iov.iov_base = data;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) msg_iov.iov_len = length;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) msg.msg_iov = &msg_iov;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) msg.msg_iovlen = 1;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) return sendmsg(sock, &msg, 0);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) Control message data should be provided unencrypted, and will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) encrypted by the kernel.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) Receiving TLS control messages
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) ------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) TLS control messages are passed in the userspace buffer, with message
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) type passed via cmsg. If no cmsg buffer is provided, an error is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) returned if a control message is received. Data messages may be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) received without a cmsg buffer set.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) char buffer[16384];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) char cmsg[CMSG_SPACE(sizeof(unsigned char))];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) struct msghdr msg = {0};
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) msg.msg_control = cmsg;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) msg.msg_controllen = sizeof(cmsg);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) struct iovec msg_iov;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) msg_iov.iov_base = buffer;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) msg_iov.iov_len = 16384;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) msg.msg_iov = &msg_iov;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) msg.msg_iovlen = 1;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) int ret = recvmsg(sock, &msg, 0 /* flags */);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) struct cmsghdr *cmsg = CMSG_FIRSTHDR(&msg);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) if (cmsg->cmsg_level == SOL_TLS &&
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) cmsg->cmsg_type == TLS_GET_RECORD_TYPE) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) int record_type = *((unsigned char *)CMSG_DATA(cmsg));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) // Do something with record_type, and control message data in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) // buffer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) //
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) // Note that record_type may be == to application data (23).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) } else {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) // Buffer contains application data.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) recv will never return data from mixed types of TLS records.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) Integrating in to userspace TLS library
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) ---------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) At a high level, the kernel TLS ULP is a replacement for the record
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) layer of a userspace TLS library.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) A patchset to OpenSSL to use ktls as the record layer is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) `here <https://github.com/Mellanox/openssl/commits/tls_rx2>`_.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) `An example <https://github.com/ktls/af_ktls-tool/commits/RX>`_
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) of calling send directly after a handshake using gnutls.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) Since it doesn't implement a full record layer, control
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) messages are not supported.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) Statistics
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) ==========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) TLS implementation exposes the following per-namespace statistics
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) (``/proc/net/tls_stat``):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) - ``TlsCurrTxSw``, ``TlsCurrRxSw`` -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) number of TX and RX sessions currently installed where host handles
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) cryptography
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) - ``TlsCurrTxDevice``, ``TlsCurrRxDevice`` -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) number of TX and RX sessions currently installed where NIC handles
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) cryptography
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) - ``TlsTxSw``, ``TlsRxSw`` -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) number of TX and RX sessions opened with host cryptography
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) - ``TlsTxDevice``, ``TlsRxDevice`` -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) number of TX and RX sessions opened with NIC cryptography
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) - ``TlsDecryptError`` -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) record decryption failed (e.g. due to incorrect authentication tag)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) - ``TlsDeviceRxResync`` -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) number of RX resyncs sent to NICs handling cryptography