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]

Date:   Sun, 2 Sep 2018 02:28:00 +0000
From:   Vakul Garg <vakul.garg@....com>
To:     David Miller <davem@...emloft.net>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "borisp@...lanox.com" <borisp@...lanox.com>,
        "aviadye@...lanox.com" <aviadye@...lanox.com>,
        "davejwatson@...com" <davejwatson@...com>
Subject: RE: [PATCH net-next v2] net/tls: Add support for async decryption of
 tls records


> -----Original Message-----
> From: David Miller <davem@...emloft.net>
> Sent: Saturday, September 1, 2018 6:31 AM
> To: Vakul Garg <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.

I do not find this patch in tree yet. 
Can you please check? Thanks and Regards.