netdev - Re: [net-next v5 3/3] net/tls: Remove redundant array allocation.

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: <DB7PR04MB4252DEFEDC63C40EF287F22D8B550@DB7PR04MB4252.eurprd04.prod.outlook.com>
Date:   Tue, 24 Jul 2018 04:43:55 +0000
From:   Vakul Garg <vakul.garg@....com>
To:     "davejwatson@...com" <davejwatson@...com>,
        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>,
        "doronrk@...com" <doronrk@...com>
Subject: Re: [net-next v5 3/3] net/tls: Remove redundant array allocation.

Hi Dave

Can you still apply the rest of two patches in the series or do I need to send them again separately?

Regards

Vakul

________________________________
From: netdev-owner@...r.kernel.org <netdev-owner@...r.kernel.org> on behalf of David Miller <davem@...emloft.net>
Sent: Tuesday, July 24, 2018 10:11:09 AM
To: davejwatson@...com
Cc: Vakul Garg; netdev@...r.kernel.org; borisp@...lanox.com; aviadye@...lanox.com; doronrk@...com
Subject: Re: [net-next v5 3/3] net/tls: Remove redundant array allocation.

From: Dave Watson <davejwatson@...com>
Date: Mon, 23 Jul 2018 09:35:09 -0700

> I don't think this patch is safe as-is.  sgin_arr is a stack array of
> size MAX_SKB_FRAGS (+ overhead), while my read of skb_cow_data is that
> it walks the whole chain of skbs from skb->next, and can return any
> number of segments.  Therefore we need to heap allocate.  I think I
> copied the IPSEC code here.

Ok I see what you are saying.

So it means that, when a non-NULL sgout is passed into decrypt_skb(),
via decrypt_skb_update(), via tls_sw_recvmsg() it means that it is the
zerocopy case and you know that you only have page frags and no SKB
frag list, right?

I agree with you that this change is therefore incorrect.

Content of type "text/html" skipped