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
| ||
|
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?
Powered by blists - more mailing lists