netdev - Re: [PATCH net-next v2 5/7] tcp: allow tls to decrypt directly from the tcp rcv queue

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]

Date:   Fri, 22 Jul 2022 10:00:44 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
        borisp@...dia.com, john.fastabend@...il.com, maximmi@...dia.com,
        tariqt@...dia.com, vfedorenko@...ek.ru, yoshfuji@...ux-ipv6.org,
        dsahern@...nel.org
Subject: Re: [PATCH net-next v2 5/7] tcp: allow tls to decrypt directly from
 the tcp rcv queue

On Thu, 2022-07-21 at 10:35 -0700, Jakub Kicinski wrote:
> On Thu, 21 Jul 2022 12:53:32 +0200 Paolo Abeni wrote:
> > I *think* tcp_recv_skb() is not needed here, the consumed skb has been
> > removed in the above loop. AFAICS tcp_read_sock() needs it because the
> > recv_actor can release and re-acquire the socket lock just after the
> > previous tcp_recv_skb() call. 
> 
> I see, thanks!
> 
> > I guess that retpoline overhead is a concern, to avoid calling
> > tcp_read_sock() with a dummy recv_actor?
> 
> Yes, and I figured the resulting helper is not very large so should 
> be okay. But I can redo it with tcp_read_sock() if you prefer.

I'm personally fine either way, and the new helper looks small enough,
so whatever is easier to you.

Unrealted to this series, I'm wondering if it would makes sense
reworking tcp_read_sock() API to avoid the indirect call? 

Cheers,

Paolo