From: Ben Hutchings <bhutchings@solarflare.com>
To: Changli Gao <xiaosuo@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <eric.dumazet@gmail.com>,
Tom Herbert <therbert@google.com>,
netdev@vger.kernel.org
Subject: Re: net: rps: support 802.1Q
Date: Sat, 20 Aug 2011 02:12:49 +0100 [thread overview]
Message-ID: <1313802769.2814.33.camel@deadeye> (raw)
In-Reply-To: <CABa6K_FhG9_XrCfhJDhhUArFEeG5FqOoU_HN1vY-TOKmjMxBKQ@mail.gmail.com>
On Fri, 2011-08-19 at 23:05 +0800, Changli Gao wrote:
> On Fri, Aug 19, 2011 at 7:54 PM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
> >
> > Should this really be reading an unlimited number of tags?
>
> Not unlimited, but it won't stop until reaching the end of the packet.
Right, I understand that the parsing is properly range-checked against
the length of the packet.
> > What if an
> > attacker starts sending packets full of VLAN tags? Since this runs
> > before netfilter, there would be no way to prevent those packets burning
> > our CPU time. And if there are legitimately multiple VLAN tags, they
> > presumably won't all have the 802.1q Ethertype.
> >
>
> Do we need to limit the number of rounds to stop this kind of "bad"
> packets from burning our CPU time?
Well, maybe. Then again, the most effective way for an attacker to
waste a target's CPU time (aside from application-level vulnerabilities)
will often be just to send minimum size packets.
> Then, __netif_receive_skb() has to
> be update too, so the inspection of tunnel in __skb_get_rxhash() does.
Yes, if we agree this is something worth defending against then we would
need to be consistent in limiting any such parsing loop in pre-netfilter
processing.
> Is there a such limitation in xfrm?
It appears to be limited to 6 levels of encapsulation.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
prev parent reply other threads:[~2011-08-20 1:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-19 5:05 net: rps: support 802.1Q Changli Gao
2011-08-19 5:08 ` David Miller
2011-08-19 5:22 ` Changli Gao
2011-08-19 5:26 ` David Miller
2011-08-19 11:54 ` Ben Hutchings
2011-08-19 15:05 ` Changli Gao
2011-08-20 1:12 ` Ben Hutchings [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1313802769.2814.33.camel@deadeye \
--to=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=therbert@google.com \
--cc=xiaosuo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.