Orange Pi5 kernel

Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards

3 Commits   0 Branches   0 Tags
^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