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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).