From: Eric Dumazet <dada1@cosmosbay.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: netdev@vger.kernel.org, kuznet@ms2.inr.ac.ru,
davem@davemloft.net, pekkas@netcore.fi, jmorris@namei.org,
yoshfuji@linux-ipv6.org, kaber@trash.net
Subject: Re: [PATCH] net: implement emergency route cache rebulds when gc_elasticity is exceeded
Date: Mon, 29 Sep 2008 22:22:03 +0200 [thread overview]
Message-ID: <48E138EB.1080001@cosmosbay.com> (raw)
In-Reply-To: <20080929191254.GA20074@hmsreliant.think-freely.org>
Neil Horman a écrit :
> Hey all-
> We currently have the ability to disable our route cache secret interval
> rebuild timer (by setting it to zero), but if we do that its possible for an
> attacker (if they guess our route cache hash secret, to fill our system with
> routes that all hash to the same bucket, destroying our performance. This patch
> provides a backstop for that issues. In the event that our rebuild interval is
> disabled (or very large), if any hash chain exceeds ip_rt_gc_elasticity, we do
> an emergency hash rebuild. During the hash rebuild we:
> 1) warn the user of the emergency
> 2) disable the rebuild timer
> 3) invalidate the route caches
> 4) re-enable the rebuild timer with its old value
>
> Regards
> Neil
This sounds not good at all to me.
1) Dont set ip_rt_secret_interval to zero, this is plain silly, since
you give attackers infinite time to break your machine.
To quote Herbert (who allowed to set this interval to 0)
"Let me first state that disabling the route cache hash rebuild
should not be done without extensive analysis on the risk profile
and careful deliberation.
However, there are times when this can be done safely or for
testing. For example, when you have mechanisms for ensuring
that offending parties do not exist in your network."
2) Many machines have ip_rt_gc_elasticity set to 2,
because they have a huge hash table, but low chain depths.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
>
> route.c | 36 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 6ee5354..b95e02a 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -145,7 +145,7 @@ static struct dst_entry *ipv4_negative_advice(struct dst_entry *dst);
> static void ipv4_link_failure(struct sk_buff *skb);
> static void ip_rt_update_pmtu(struct dst_entry *dst, u32 mtu);
> static int rt_garbage_collect(struct dst_ops *ops);
> -
> +static void rt_emergency_hash_rebuild(void);
>
> static struct dst_ops ipv4_dst_ops = {
> .family = AF_INET,
> @@ -1056,6 +1056,15 @@ restart:
> *candp = cand->u.dst.rt_next;
> rt_free(cand);
> }
> + } else if (chain_length > ip_rt_gc_elasticity) {
> + /*
> + * We didn't find a route entry we could safely free,
> + * yet our chain length is over our elasticity value.
> + * Someone may have guessed our hash secret and is artifically
> + * filling up our route cache. Lets do an emergency rebuild
> + * to be safe
> + */
> + rt_emergency_hash_rebuild();
> }
>
> /* Try to bind route to arp only if it is output
> @@ -2946,6 +2955,31 @@ static void rt_secret_reschedule(int old)
> rtnl_unlock();
> }
>
> +static void rt_secret_rebuild_oneshot(void) {
> + struct net *net;
> + int old_interval = ip_rt_secret_interval;
> +
> + ip_rt_secret_interval = 0;
> +
> + rt_secret_reschedule(old_interval);
> +
> + for_each_net(net)
> + rt_cache_invalidate(net);
> +
> + ip_rt_secret_interval = old_interval;
> +
> + rt_secret_reschedule(0);
> +}
> +
> +static void rt_emergency_hash_rebuild(void) {
> + if (net_ratelimit()) {
> + printk(KERN_WARNING "Route hash chain too long!\n");
> + printk(KERN_WARNING "Adjust your secret_interval!\n");
> + }
> +
> + rt_secret_rebuild_oneshot();
> +}
> +
> static int ipv4_sysctl_rt_secret_interval(ctl_table *ctl, int write,
> struct file *filp,
> void __user *buffer, size_t *lenp,
next prev parent reply other threads:[~2008-09-29 20:22 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-29 19:12 [PATCH] net: implement emergency route cache rebulds when gc_elasticity is exceeded Neil Horman
2008-09-29 20:22 ` Eric Dumazet [this message]
2008-09-29 20:27 ` Neil Horman
2008-09-29 21:00 ` Eric Dumazet
2008-09-29 22:38 ` Neil Horman
2008-09-30 6:02 ` Eric Dumazet
2008-09-30 11:23 ` Neil Horman
2008-09-30 14:10 ` David Miller
2008-09-30 17:16 ` Eric Dumazet
2008-09-30 18:42 ` Neil Horman
2008-10-02 7:16 ` Evgeniy Polyakov
2008-10-02 13:14 ` Neil Horman
2008-10-01 18:08 ` Neil Horman
2008-10-02 5:01 ` Bill Fink
2008-10-02 6:56 ` Eric Dumazet
2008-10-02 8:15 ` Eric Dumazet
2008-10-02 14:20 ` Eric Dumazet
2008-10-03 0:31 ` Neil Horman
2008-10-03 20:36 ` Neil Horman
2008-10-06 10:49 ` Eric Dumazet
2008-10-06 13:14 ` Neil Horman
2008-10-06 20:54 ` Neil Horman
2008-10-06 21:21 ` Eric Dumazet
2008-10-06 22:52 ` Neil Horman
2008-10-07 5:13 ` Eric Dumazet
2008-10-07 10:54 ` Neil Horman
2008-10-13 18:26 ` Neil Horman
2008-10-16 6:55 ` David Miller
2008-10-16 9:19 ` Eric Dumazet
2008-10-16 21:18 ` David Miller
2008-10-16 11:41 ` Neil Horman
2008-10-16 12:25 ` Eric Dumazet
2008-10-16 16:36 ` Neil Horman
2008-10-16 23:35 ` Neil Horman
2008-10-17 4:53 ` Eric Dumazet
2008-10-17 5:23 ` David Miller
2008-10-17 5:03 ` Stephen Hemminger
2008-10-17 5:06 ` Stephen Hemminger
2008-10-17 10:39 ` Neil Horman
[not found] ` <48F8806A.6090306@cosmosbay.com>
[not found] ` <20081017152328.GB23591@hmsreliant.think-freely.org>
[not found] ` <48F8AFBE.5080503@cosmosbay.com>
2008-10-17 20:44 ` Neil Horman
2008-10-18 0:54 ` Neil Horman
2008-10-18 4:36 ` Eric Dumazet
2008-10-18 13:30 ` Neil Horman
2008-10-20 0:07 ` Neil Horman
2008-10-20 8:12 ` Eric Dumazet
2008-10-27 19:28 ` David Miller
2008-10-02 7:13 ` Evgeniy Polyakov
2008-09-30 14:08 ` David Miller
2008-09-30 14:08 ` David Miller
2008-09-30 17:47 ` Eric Dumazet
2008-10-05 3:26 ` Herbert Xu
2008-10-05 4:45 ` Andrew Dickinson
2008-10-05 17:34 ` David Miller
2008-10-05 18:06 ` Andrew Dickinson
2008-10-06 4:21 ` Herbert Xu
2008-10-06 10:50 ` Neil Horman
2008-10-06 11:02 ` Herbert Xu
2008-10-06 12:43 ` Neil Horman
2008-09-30 14:17 ` Denis V. Lunev
2008-09-30 14:35 ` Neil Horman
2008-09-30 14:49 ` Denis V. Lunev
2008-10-05 3:17 ` Herbert Xu
2008-10-05 3:20 ` Herbert Xu
2008-10-06 0:52 ` Neil Horman
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=48E138EB.1080001@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=davem@davemloft.net \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=pekkas@netcore.fi \
--cc=yoshfuji@linux-ipv6.org \
/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).