netdev - [PATCH RFC net-next 0/6] RFC: TLS TX HW offload for Bond

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-next>] [day] [month] [year] [list]

Message-Id: <20201229114104.7120-1-tariqt@nvidia.com>
Date:   Tue, 29 Dec 2020 13:40:58 +0200
From:   Tariq Toukan <tariqt@...dia.com>
To:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     Saeed Mahameed <saeedm@...dia.com>,
        Boris Pismenny <borisp@...dia.com>, netdev@...r.kernel.org,
        Moshe Shemesh <moshe@...dia.com>, andy@...yhouse.net,
        vfalico@...il.com, j.vosburgh@...il.com,
        Tariq Toukan <ttoukan.linux@...il.com>,
        Tariq Toukan <tariqt@...dia.com>
Subject: [PATCH RFC net-next 0/6] RFC: TLS TX HW offload for Bond

Hi,

This is an RFC of the series that opens TLS TX HW offload for bond interfaces.
It allows them to benefit from capable slave devices.

To keep simple track of the HW and SW TLS contexts, we bind each socket to
a specific slave for the socket's whole lifetime. This is logically valid
(and similar to the SW kTLS behavior) in the following bond configuration, 
so we restrict the offload support to it:

((mode == balance-xor) or (mode == 802.3ad))
and xmit_hash_policy == layer3+4.

Opens/points for discussion:
- New ndo_sk_get_slave is introduced, as the existing ndo_get_xmit_slave returns
  a slave based on SKB fields, which in throry could give different results
  along the socket's lifetime.

- In this design, bond driver has no way to specify its own restrictions on
  when the TLS device offload is supported (depending on mode and xmit_policy).
  The best it can do today is return NULL in bond_sk_get_slave().
  This is not optimal, non-TLS cases might also want to call bond_sk_get_slave()
  in the future, and they might have other restrictions (for example, they might
  be okay in working with layer != LAYER34).
  That's another reason why I didn't combine ndo_sk_get_slave/ndo_get_xmit_slave
  into a single operation in this RFC.

- Patch #3 adds two explicit exceptions for bond devices in the TLS module.
  First is because a bond device supports the device offload without having
  a tls_dev_ops structure of it's own.
  Second, the TLS context is totally unaware of the bond netdev, but SKBs 
  still go through its xmit/validate functions.
  This is not very clean. What do you think?

- This bond design and implementation for the TLS device offload differs from the
  xfrm/ipsec offload. Bond does have struct xfrmdev_ops and callbacks of its own,
  communication is done via the bond and not directly to the lowest device.

Regards,
Tariq


Tariq Toukan (6):
  net: netdevice: Add operation ndo_sk_get_slave
  net/tls: Device offload to use lowest netdevice in chain
  net/tls: Except bond interface from some TLS checks
  net/bonding: Take IP hash logic into a helper
  net/bonding: Implement ndo_sk_get_slave
  net/bonding: Support TLS TX device offload

 drivers/net/bonding/bond_main.c    | 134 +++++++++++++++++++++++++++--
 drivers/net/bonding/bond_options.c |  27 ++++--
 include/linux/netdevice.h          |   4 +
 include/net/bonding.h              |   2 +
 net/core/dev.c                     |  32 +++++++
 net/tls/tls_device.c               |   4 +-
 net/tls/tls_device_fallback.c      |   3 +-
 7 files changed, 194 insertions(+), 12 deletions(-)

-- 
2.21.0