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

Message-ID: <68e3a841-3c03-9d70-8c89-b7c05788e077@gmail.com>
Date:   Wed, 17 Aug 2022 15:09:58 +0700
From:   Bagas Sanjaya <bagasdotme@...il.com>
To:     Adel Abouchaev <adel.abushaev@...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

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.

-- 
An old man doll... just what I always wanted! - Clara