netdev - Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing

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

Message-ID: <CAOrHB_A1sQWforWuUve5phrxPjSOpbTEQ4F5h3beh1C9qWmUTw@mail.gmail.com>
Date:   Sat, 6 Jan 2018 10:57:56 -0800
From:   Pravin Shelar <pshelar@....org>
To:     Ed Swierk <eswierk@...portsystems.com>
Cc:     ovs-dev <ovs-dev@...nvswitch.org>, netdev <netdev@...r.kernel.org>,
        Benjamin Warren <ben@...portsystems.com>,
        Keith Holleman <holleman@...portsystems.com>
Subject: Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing

On Fri, Jan 5, 2018 at 10:59 PM, Ed Swierk <eswierk@...portsystems.com> wrote:
>
>
> On Jan 5, 2018 22:17, "Pravin Shelar" <pshelar@....org> wrote:
>
> On Fri, Jan 5, 2018 at 3:20 PM, Ed Swierk <eswierk@...portsystems.com>
> wrote:
>> On Fri, Jan 5, 2018 at 10:14 AM, Ed Swierk <eswierk@...portsystems.com>
>> wrote:
>>> On Thu, Jan 4, 2018 at 7:36 PM, Pravin Shelar <pshelar@....org> wrote:
>>>> OVS already pull all required headers in skb linear data, so no need
>>>> to redo all of it. only check required is the ip-checksum validation.
>>>> I think we could avoid it in most of cases by checking skb length to
>>>> ipheader length before verifying the ip header-checksum.
>>>
>>> Shouldn't the IP header checksum be verified even earlier, like in
>>> key_extract(), before actually using any of the fields in the IP
>>> header?
>>
>> Something like this for verifying the IP header checksum (not tested):
>>
> AFAIU openflow does not need this verification, so it is not required
> in flow extract.
>
>
> Okay. How about my proposed trimming implementation, caching the pad length
> in the ovs cb?
>
Caching the length is not that simple, OVS actions can change the
length. Keeping it consistent with packet would be more work, so lets
calculate it in ovs-ct function.