netdev - Re: [RFC PATCH 0/6] BOND TLS flags fixes

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20210607123733.16fb8317@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Mon, 7 Jun 2021 12:37:33 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Tariq Toukan <ttoukan.linux@...il.com>
Cc:     Tariq Toukan <tariqt@...dia.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Moshe Shemesh <moshe@...dia.com>,
        Boris Pismenny <borisp@...dia.com>,
        Saeed Mahameed <saeedm@...dia.com>,
        Maxim Mikityanskiy <maximmi@...dia.com>
Subject: Re: [RFC PATCH 0/6] BOND TLS flags fixes

On Sun, 6 Jun 2021 17:02:49 +0300 Tariq Toukan wrote:
> > Regarding UPPER_DISABLES:
> > I propose using it here as an attempt to give the bond device some 
> > control over kTLS offloaded connections, to avoid cases where:
> > (*) UPPER.ktls_device_offload==OFF
> > (*) LOWER.ktls_device_offload==ON
> > (*) Newly created connections are offloaded!! Simply ignoring and 
> > bypassing the UPPER device state (this is how .ndo_sk_get_lower_dev works).
> > 
> > This is not my preferred solution though.
> > I think we should reconsider introducing bond implementation for "struct 
> > tlsdev_ops" callbacks, which gives bond interface full control and 
> > awareness to new TLS connections.  
> 
> If you're fine with the direction, I can prepare a new series that adds 
> "struct tlsdev_ops" callbacks implementation for bond, instead of the 
> "UPPER_DISABLES solution" above.
> 
> What do you think?

I think a design which requires teaching middle layer drivers about
individual hardware offloads for ULPs is poor, brittle and hard to
reason about.

But historically we seem to have acted in an ad-hoc fashion, so I 
won't hold it against you if you prefer to keep the whack-a-mole going.