netdev - Re: [PATCH net-next v2] net/tls: Add support for async decryption of tls records

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: <20180831.180052.1973952115883483635.davem@davemloft.net>
Date:   Fri, 31 Aug 2018 18:00:52 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     vakul.garg@....com
Cc:     netdev@...r.kernel.org, borisp@...lanox.com, aviadye@...lanox.com,
        davejwatson@...com
Subject: Re: [PATCH net-next v2] net/tls: Add support for async decryption
 of tls records

From: Vakul Garg <vakul.garg@....com>
Date: Wed, 29 Aug 2018 15:26:55 +0530

> When tls records are decrypted using asynchronous acclerators such as
> NXP CAAM engine, the crypto apis return -EINPROGRESS. Presently, on
> getting -EINPROGRESS, the tls record processing stops till the time the
> crypto accelerator finishes off and returns the result. This incurs a
> context switch and is not an efficient way of accessing the crypto
> accelerators. Crypto accelerators work efficient when they are queued
> with multiple crypto jobs without having to wait for the previous ones
> to complete.
> 
> The patch submits multiple crypto requests without having to wait for
> for previous ones to complete. This has been implemented for records
> which are decrypted in zero-copy mode. At the end of recvmsg(), we wait
> for all the asynchronous decryption requests to complete.
> 
> The references to records which have been sent for async decryption are
> dropped. For cases where record decryption is not possible in zero-copy
> mode, asynchronous decryption is not used and we wait for decryption
> crypto api to complete.
> 
> For crypto requests executing in async fashion, the memory for
> aead_request, sglists and skb etc is freed from the decryption
> completion handler. The decryption completion handler wakesup the
> sleeping user context when recvmsg() flags that it has done sending
> all the decryption requests and there are no more decryption requests
> pending to be completed.
> 
> Signed-off-by: Vakul Garg <vakul.garg@....com>
> Reviewed-by: Dave Watson <davejwatson@...com>
> ---
> 
> Changes since v1:
> 	- Simplified recvmsg() so to drop reference to skb in case it
> 	  was submimtted for async decryption.
> 	- Modified tls_sw_advance_skb() to handle case when input skb is
> 	  NULL.

Applied.