On 11/10/2020 10:37 AM, Vinay Kumar Yadav wrote:
On 11/10/2020 12:28 AM, Jakub Kicinski wrote:
On Tue, 10 Nov 2020 00:21:13 +0530 Vinay Kumar Yadav wrote:
On 11/7/2020 1:58 AM, Jakub Kicinski wrote:
On Sat, 7 Nov 2020 02:02:42 +0530 Vinay Kumar Yadav wrote:
On 11/6/2020 12:16 AM, Jakub Kicinski wrote:
On Thu, 5 Nov 2020 23:55:15 +0530 Vinay Kumar Yadav wrote:
We should prevent from the socket getting into LISTEN state in
the
first place. Can we make a copy of proto_ops (like
tls_sw_proto_ops)
and set listen to sock_no_listen?
Once tls-toe (TLS_HW_RECORD) is configured on a socket,
listen() call
from user on same socket will create hash at two places.
What I'm saying is - disallow listen calls on sockets with tls-toe
installed on them. Is that not possible?
You mean socket with tls-toe installed shouldn't be listening at
other
than adapter? basically avoid ctx->sk_proto->hash(sk) call.
No, replace the listen callback, like I said. Why are you talking
about
hash???
As per my understanding we can't avoid socket listen.
Not sure how replacing listen callback solve the issue,
can you please elaborate ?
TLS sockets are not supposed to get into listen state. IIUC the problem
is that the user is able to set TLS TOE on a socket which then starts
to listen and the state gets cloned improperly.
TLS-TOE can go to listen mode, removing listen is not an option and
TLS-TOE support only server mode so if we remove listen then we will not
have TLS-TOE support which we don't want.
Oh, so it's completely incompatible with kernel tls. How about we
remove the support completely then? Clearly it's not an offload of
kernel tls if it supports completely different mode of operation.
It is not incompatible. It fits in k.org tls infrastructure (TLS-TOE
mode). For the current issue we have proposed a fix. What is the issue
with proposed fix, can you elaborate and we will address that?
and it is valid TLS offload mode.
