Message-ID: <DB6PR05MB317642E9F747D39AF83A68DFB0340@DB6PR05MB3176.eurprd05.prod.outlook.com>
Date:   Thu, 30 Mar 2017 06:49:47 +0000
From:   Boris Pismenny <borisp@...lanox.com>
To:     Hannes Frederic Sowa <hannes@...essinduktion.org>,
        David Miller <davem@...emloft.net>,
        Aviad Yehezkel <aviadye@...lanox.com>
CC:     Ilya Lesokhin <ilyal@...lanox.com>,
        "davejwatson@...com" <davejwatson@...com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Matan Barak <matanb@...lanox.com>,
        Liran Liss <liranl@...lanox.com>,
        "Haggai Eran" <haggaie@...lanox.com>,
        "tom@...bertland.com" <tom@...bertland.com>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "nmav@...lts.org" <nmav@...lts.org>,
        "fridolin.pokorny@...il.com" <fridolin.pokorny@...il.com>,
        Ilan Tayari <ilant@...lanox.com>,
        "Yevgeny Kliteynik" <kliteyn@...lanox.com>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        Saeed Mahameed <saeedm@...lanox.com>,
        "aviadye@....mellanox.co.il" <aviadye@....mellanox.co.il>
Subject: RE: [RFC TLS Offload Support 00/15] cover letter

> >> 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?
We maintain the crypto context by tracking TCP sequence numbers, splitting
TCP segments is not a problem. Even if reordering is introduced anywhere
between TCP and the driver, we can identify it according to the TCP
sequence number and handle it gracefully – see mlx_tls_tx_handler.

> 
> Furthermore, it doesn't seem to work with bonding or any other virtual
> interface, which could move the skb's to be processed on another NIC, as the
> context is put onto the NIC. Even a redirect can not be processed anymore
> (seems like those patches try to stick the connection to an interface anyway).
> 
> Wouldn't it be possible to keep the state in software and push down a
> security context per skb, which get applied during sending? If not possible via
> hw, slowpath can encrypt packet in sw.
We do have all the state required to encrypt a TLS packet in software. But,
pushing down the state for each skb is too expansive, because the state
depends on all data in the TLS record, essentially it requires to resend the
record up to that skb. This is accomplished for OOO packets in the
“handle_ooo” function in mlx_tls.

Maybe we could use that functionality to handle bonding, but at first it would
be easier to prevent it.

The slowpath you’ve mentioned is tricky, because you need to decide in
advance that a TLS record will use the slowpath, because after the plaintext
TLS record is pushed into TCP it is difficult to fallback to software crypto.
> 
> Also sticking connections to outgoing interfaces might work for TX, but you
> can't force the interface where packets come in.
Right. This RFC handles only TX offload.
> 
> Bye,
> Hannes

Thanks,
Boris

Powered by blists - more mailing lists