netdev - Re: [PATCH net-next] net/tls: Always get number of sg entries for skb to be decrypted

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:   Thu, 2 Aug 2018 17:26:48 -0700
From:   Doron Roberts-Kedes <doronrk@...com>
To:     Dave Watson <davejwatson@...com>
CC:     Vakul Garg <vakul.garg@....com>, <netdev@...r.kernel.org>,
        <borisp@...lanox.com>, <aviadye@...lanox.com>,
        <davem@...emloft.net>
Subject: Re: [PATCH net-next] net/tls: Always get number of sg entries for
 skb to be decrypted

On Thu, Aug 02, 2018 at 09:50:58AM -0700, Dave Watson wrote:
> On 08/02/18 09:50 PM, Vakul Garg wrote:
> > Function decrypt_skb() made a bad assumption that number of sg entries
> > required for mapping skb to be decrypted would always be less than
> > MAX_SKB_FRAGS. The required count of sg entries for skb should always be
> > calculated. If they cannot fit in local array sgin_arr[], allocate them
> > from heap irrespective whether it is zero-copy case or otherwise. The
> > change also benefits the non-zero copy case as we could use sgin_arr[]
> > instead of always allocating sg entries from heap.
> > 
> > Signed-off-by: Vakul Garg <vakul.garg@....com>
> 
> Looks great, thanks.
> 
> Reviewed-by: Dave Waston <davejwatson@...com>

I agree that this is a problem, but I'm not sure that this is the best
way to fix it. Calling skb_cow_data unconditionally is expensive. In my
benchmarks this patch cause a 5% CPU regression, all from memcpy from
skb_cow_data, and a 15% regression in encrypted NBD IOPS. It is possible
to calculate the number of scatterlist elements required to map the skb
without invoking skb_cow_data. I'll have a patch up shortly.