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  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:	Mon, 04 Aug 2014 12:42:46 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	pshelar@...ira.com
Cc:	netdev@...r.kernel.org
Subject: Re: [GIT net-next] Open vSwitch

From: Pravin Shelar <pshelar@...ira.com>
Date: Mon, 4 Aug 2014 12:35:59 -0700

> On Sun, Aug 3, 2014 at 9:21 PM, David Miller <davem@...emloft.net> wrote:
>> From: Pravin Shelar <pshelar@...ira.com>
>> Date: Sun, 3 Aug 2014 12:20:32 -0700
>>
>>> 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.
>>
>> An attacker can construct a packet sequence such that every mask cache
>> lookup misses, making the cache effectively useless.
> 
> Yes, but it does work in normal traffic situations.

You're basically just reiterating the point I'm trying to make.

Your caches are designed for specific configuration and packet traffic
pattern cases, and can be easily duped into a worse case performance
scenerio by an attacker.

Caches, basically, do not work on the real internet.

Make the fundamental core data structures fast and scalable enough,
rather than bolting caches (which are basically hacks) on top every
time they don't perform to your expectations.

What if you made the full flow lookup fundamentally faster?  Then an
attacker can't do anything about that.  That's a real performance
improvement, one that sustains arbitrary traffic patterns.
--
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

Powered by blists - more mailing lists