• Ilya Lesokhin's avatar
    net/tls: Add generic NIC offload infrastructure · e8f69799
    Ilya Lesokhin authored
    This patch adds a generic infrastructure to offload TLS crypto to a
    network device. It enables the kernel TLS socket to skip encryption
    and authentication operations on the transmit side of the data path.
    Leaving those computationally expensive operations to the NIC.
    
    The NIC offload infrastructure builds TLS records and pushes them to
    the TCP layer just like the SW KTLS implementation and using the same
    API.
    TCP segmentation is mostly unaffected. Currently the only exception is
    that we prevent mixed SKBs where only part of the payload requires
    offload. In the future we are likely to add a similar restriction
    following a change cipher spec record.
    
    The notable differences between SW KTLS and NIC offloaded TLS
    implementations are as follows:
    1. The offloaded implementation builds "plaintext TLS record", those
    records contain plaintext instead of ciphertext and place holder bytes
    instead of authentication tags.
    2. The offloaded implementation maintains a mapping from TCP sequence
    number to TLS records. Thus given a TCP SKB sent from a NIC offloaded
    TLS socket, we can use the tls NIC offload infrastructure to obtain
    enough context to encrypt the payload of the SKB.
    A TLS record is released when the last byte of the record is ack'ed,
    this is done through the new icsk_clean_acked callback.
    
    The infrastructure should be extendable to support various NIC offload
    implementations.  However it is currently written with the
    implementation below in mind:
    The NIC assumes that packets from each offloaded stream are sent as
    plaintext and in-order. It keeps track of the TLS records in the TCP
    stream. When a packet marked for offload is transmitted, the NIC
    encrypts the payload in-place and puts authentication tags in the
    relevant place holders.
    
    The responsibility for handling out-of-order packets (i.e. TCP
    retransmission, qdisc drops) falls on the netdev driver.
    
    The netdev driver keeps track of the expected TCP SN from the NIC's
    perspective.  If the next packet to transmit matches the expected TCP
    SN, the driver advances the expected TCP SN, and transmits the packet
    with TLS offload indication.
    
    If the next packet to transmit does not match the expected TCP SN. The
    driver calls the TLS layer to obtain the TLS record that includes the
    TCP of the packet for transmission. Using this TLS record, the driver
    posts a work entry on the transmit queue to reconstruct the NIC TLS
    state required for the offload of the out-of-order packet. It updates
    the expected TCP SN accordingly and transmits the now in-order packet.
    The same queue is used for packet transmission and TLS context
    reconstruction to avoid the need for flushing the transmit queue before
    issuing the context reconstruction request.
    Signed-off-by: default avatarIlya Lesokhin <ilyal@mellanox.com>
    Signed-off-by: default avatarBoris Pismenny <borisp@mellanox.com>
    Signed-off-by: default avatarAviad Yehezkel <aviadye@mellanox.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    e8f69799
tls_device_fallback.c 12.3 KB