netdev - Re: [GIT net-next] Open vSwitch

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, 3 Aug 2014 12:20:32 -0700
From:	Pravin Shelar <pshelar@...ira.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: [GIT net-next] Open vSwitch

On Sat, Aug 2, 2014 at 3:16 PM, David Miller <davem@...emloft.net> wrote:
> From: Pravin B Shelar <pshelar@...ira.com>
> Date: Thu, 31 Jul 2014 16:57:37 -0700
>
>> Following patch adds mask cache so that we do not need to iterate over
>> all entries in mask list on every packet. We have seen good performance
>> improvement with this patch.
>
> How much have you thought about the DoS'ability of openvswitch's
> datastructures?
>
This cache is populated by flow lookup in fast path. The mask cache is
fixed in size. Userspace or number of packets can not change its size.
Memory is statically allocated, no garbage collection. So DoS attack
can not exploit this cache to increase ovs memory footprint.

> What are the upper bounds for performance of packet switching?
>
Cache is keyed on packet RSS. Worst case scenario this cache adds one
extra flow-table lookup for the flow if RSS hash matches but packet
belong to different flow (hash collision).
This is designed to be lightweight, stateless cache (does not take any
reference on other data structures) to have least impact on
DoS'ability of Open vSwitch.

> To be quite honest, a lot of the openvswitch data structures
> adjustments that hit my inbox seem to me to only address specific
> situations that specific user configurations have run into.
>

Overall OVS DoS defense has improved since introduction of mega-flow.
Recently introduced OVS feature allows userspace to set multiple
sockets for upcall processing for given vport. This adds fairness by
separating upcall from different flows to a socket. Userspace process
upcall from these sockets in round-robin fashion. This helps to avoid
one port monopolize upcall communication path.

I agree there is scope for improving DoS defense and we will keep
working on this issue.

> It took us two decades, but we ripped out the ipv4 routing cache
> because external entities could provoke unreasonable worst case
> behavior in routing lookups.
>
> With openvswitch you guys have a unique opportunity to try and design
> all of your features such that they absolutely can use scalable
> datastructures from the beginning that provide reasonable performance
> in the common case and precise upper bounds for any possible sequence
> of incoming packets.
>
> New features tend to blind the developer to the eventual long term
> ramifications on performance.  Would you add a new feature if you
> could know ahead of time that you'll never be able to design a
> datastructure which supports that feature and is not DoS'able by a
> remote entity?
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html