netdev - Re: [RFC TLS Offload Support 00/15] cover letter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20170329.104122.139835608303809432.davem@davemloft.net>
Date:   Wed, 29 Mar 2017 10:41:22 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     aviadye@...lanox.com
Cc:     ilyal@...lanox.com, borisp@...lanox.com, davejwatson@...com,
        netdev@...r.kernel.org, matanb@...lanox.com, liranl@...lanox.com,
        haggaie@...lanox.com, tom@...bertland.com,
        herbert@...dor.apana.org.au, nmav@...lts.org,
        fridolin.pokorny@...il.com, ilant@...lanox.com,
        kliteyn@...lanox.com, linux-crypto@...r.kernel.org,
        saeedm@...lanox.com, aviadye@....mellanox.co.il
Subject: Re: [RFC TLS Offload Support 00/15] cover letter

From: Aviad Yehezkel <aviadye@...lanox.com>
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?