netdev - Re: [net-next 0/6] net: support QUIC crypto

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

Date:   Wed, 17 Aug 2022 11:49:29 -0700
From:   Adel Abouchaev <adel.abushaev@...il.com>
To:     Bagas Sanjaya <bagasdotme@...il.com>, kuba@...nel.org
Cc:     davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
        corbet@....net, dsahern@...nel.org, shuah@...nel.org,
        imagedong@...cent.com, netdev@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [net-next 0/6] net: support QUIC crypto

The base commit for the branch I am using here is:

commit f86d1fbbe7858884d6754534a0afbb74fc30bc26 
(origin/net-next-upstream, net-next/master, net-next/main, net-next)
Merge: 526942b8134c 7c6327c77d50
Author: Linus Torvalds <torvalds@...ux-foundation.org>
Date:   Wed Aug 3 16:29:08 2022 -0700

Will fix the whitespaces and resubmit.

On 8/17/22 1:09 AM, Bagas Sanjaya wrote:
> On 8/17/22 01:11, Adel Abouchaev wrote:
>> QUIC requires end to end encryption of the data. The application usually
>> prepares the data in clear text, encrypts and calls send() which implies
>> multiple copies of the data before the packets hit the networking stack.
>> Similar to kTLS, QUIC kernel offload of cryptography reduces the memory
>> pressure by reducing the number of copies.
>>
>> The scope of kernel support is limited to the symmetric cryptography,
>> leaving the handshake to the user space library. For QUIC in particular,
>> the application packets that require symmetric cryptography are the 1RTT
>> packets with short headers. Kernel will encrypt the application packets
>> on transmission and decrypt on receive. This series implements Tx only,
>> because in QUIC server applications Tx outweighs Rx by orders of
>> magnitude.
>>
>> Supporting the combination of QUIC and GSO requires the application to
>> correctly place the data and the kernel to correctly slice it. The
>> encryption process appends an arbitrary number of bytes (tag) to the end
>> of the message to authenticate it. The GSO value should include this
>> overhead, the offload would then subtract the tag size to parse the
>> input on Tx before chunking and encrypting it.
>>
>> With the kernel cryptography, the buffer copy operation is conjoined
>> with the encryption operation. The memory bandwidth is reduced by 5-8%.
>> When devices supporting QUIC encryption in hardware come to the market,
>> we will be able to free further 7% of CPU utilization which is used
>> today for crypto operations.
>>
> Hmmm...
>
> I can't cleanly applied this series on top of current net-next. Exactly
> on what commit this series is based on?
>
> Also, I see two whitespace warnings when applying. Please fixup and resend.
> When resending, don't forget to pass --base to git-format-patch(1).
>
> Thanks.
>