From: Aviad Yehezkel <aviadye@xxxxxxxxxxxx> Date: Tue, 28 Mar 2017 16:26:17 +0300 > TLS Tx crypto offload is a new feature of network devices. It > enables the kernel TLS socket to skip encryption and authentication > operations on the transmit side of the data path, delegating those > to the NIC. In turn, the NIC encrypts packets that belong to an > offloaded TLS socket on the fly. The NIC does not modify any packet > headers. It expects to receive fully framed TCP packets with TLS > records as payload. The NIC replaces plaintext with ciphertext and > fills the authentication tag. The NIC does not hold any state beyond > the context needed to encrypt the next expected packet, > i.e. expected TCP sequence number and crypto state. It seems like, since you do the TLS framing in TCP and the card is expecting to fill in certain aspects, there is a requirement that the packet contents aren't mangled between the TLS framing code and when the SKB hits the card. Is this right? For example, what happens if netfilter splits a TLS Tx offloaded frame into two TCP segments?
