netdev - [regression] Bug 217064 - Kernel TLS with CAAM is Broken (net/tls/tls

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

Date:   Wed, 22 Feb 2023 08:46:46 +0100
From:   "Linux regression tracking (Thorsten Leemhuis)" 
        <regressions@...mhuis.info>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev <netdev@...r.kernel.org>,
        Linux kernel regressions list <regressions@...ts.linux.dev>,
        LKML <linux-kernel@...r.kernel.org>,
        Boris Pismenny <borisp@...dia.com>,
        John Fastabend <john.fastabend@...il.com>,
        Gaurav Jain <gaurav.jain@....com>
Subject: [regression] Bug 217064 - Kernel TLS with CAAM is Broken
 (net/tls/tls_sw.c)

Hi, this is your Linux kernel regression tracker.

I noticed a regression report in bugzilla.kernel.org. As many (most?)
kernel developer don't keep an eye on it, I decided to forward it by
mail. Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=217064 :

>  Gaurav Jain 2023-02-21 07:07:22 UTC
> 
> I am running Kernel TLS with CAAM on iMX8M board.
> KTLS + CAAM is broken in 6.1 kernel when async and zero copy is true.
> 
> **Commit id causing the issue: **
> 
> commit cbbdee9918a2662914f411aa999f2f80bf044a30
> Author: Jakub Kicinski kuba@...nel.org
> Date:   Thu Jul 14 22:22:34 2022 -0700
> 
>     tls: rx: async: don't put async zc on the list
> 
>     The "zero-copy" path in SW TLS will engage either for no skbs or
>     for all but last. If the recvmsg parameters are right and the
>     socket can do ZC we'll ZC until the iterator can't fit a full
>     record at which point we'll decrypt one more record and copy
>     over the necessary bits to fill up the request.
> 
>     The only reason we hold onto the ZC skbs which went thru the async
>     path until the end of recvmsg() is to count bytes. We need an accurate
>     count of zc'ed bytes so that we can calculate how much of the non-zc'd
>     data to copy. To allow freeing input skbs on the ZC path count only
>     how much of the list we'll need to consume.
> 
>     Signed-off-by: Jakub Kicinski kuba@...nel.org
>     Signed-off-by: David S. Miller davem@...emloft.net



See the ticket for more details.


[TLDR for the rest of this mail: I'm adding this report to the list of
tracked Linux kernel regressions; the text you find below is based on a
few templates paragraphs you might have encountered already in similar
form.]

BTW, let me use this mail to also add the report to the list of tracked
regressions to ensure it's doesn't fall through the cracks:

#regzbot introduced: cbbdee9918a2
https://bugzilla.kernel.org/show_bug.cgi?id=217064
#regzbot title: net/ktls: Kernel TLS with CAAM is Broken
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.

Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (e.g. the buzgzilla ticket and maybe this mail as well, if
this thread sees some discussion). See page linked in footer for details.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.