linux-kernel - Re: [PATCH] openvswitch: supply a dummy err_handler of gre_cisco

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 2 Apr 2014 08:23:28 +0800 (CST)
From:	"wei zhang" <asuka.com@....com>
To:	"Jesse Gross" <jesse@...ira.com>
Cc:	"David Miller" <davem@...emloft.net>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>,
	netdev <netdev@...r.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] openvswitch: supply a dummy err_handler of
 gre_cisco_protocol to prevent kernel crash

At 2014-04-02 02:27:56,"Jesse Gross" <jesse@...ira.com> wrote:
>On Tue, Apr 1, 2014 at 8:24 AM, wei zhang <asuka.com@....com> wrote:
>> At 2014-04-01 08:49:53,"Jesse Gross" <jesse@...ira.com> wrote:
>>>On Sun, Mar 30, 2014 at 5:12 AM, wei zhang <asuka.com@....com> wrote:
>>>> At 2014-03-29 06:02:25,"Jesse Gross" <jesse@...ira.com> wrote:
>>
>>>> Maybe I misunderstand something? I think if we discard all packet pass to us
>>>> when we use gre vport, new gre_cisco_protocol which has lower priority could
>>>> not see the packet intended to it.
>>>
>>>That's true but in this case it would also not see any data packets,
>>>so I don't think that situation would work well anyways.
>>>
>>>> I checked the implementation of the ipgre_err(), which has be called before
>>>> the err_handler of gre vport. It use the the (local address, remote address, key)
>>>> to distinguish the packet which is realy intended to it, although it could not
>>>> always get the key from the icmp packet. Should we do as the same as it?
>>>> I'm not sure this is feasible, any advice is appreciate.
>>>
>>>OVS does flow based matching rather than using a static set of
>>>configuration parameters, so everything "matches" in some way
>>>(although the result might be to drop).
>>
>> So the flow based match could dynamically determine by the ovs daemon, we could
>> not find out the belonging of the packet as far as we call ovs_dp_upcall(), isn't it?
>
>That's right - and since the OVS flow table always has a default
>behavior (even if it is drop or send to controller) there's never a
>packet that isn't considered to be destined to OVS once it is
>received.
>
>If this makes sense to you, would you mind submitting the patch you
>had earlier formally with a commit message and signed off by line?

Sure, thank you again as it's my first time to send patch to the kernel, your patient and kind
help give me confidence to do it :)

Regards,
Wei Zhang