netdev - Re: [PATCH] ipv6: fix two typos in a comment in xfrm6

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]

Message-ID: <20121109075726.GD22290@secunet.com>
Date:	Fri, 9 Nov 2012 08:57:26 +0100
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	David Miller <davem@...emloft.net>
Cc:	roy.qing.li@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH] ipv6: fix two typos in a comment in xfrm6_init()

On Thu, Nov 08, 2012 at 02:59:39PM -0500, David Miller wrote:
> From: Steffen Klassert <steffen.klassert@...unet.com>
> > 
> > The routing cache is removed, so this comment is obsolete. But it reminds
> > me that we set the gc threshold to ip_rt_max_size/2 in ipv4. With the
> > routing cache removal patch, ip_rt_max_size was set to INT_MAX. So the gc
> > starts to remove entries when a threshold of INT_MAX/2 is reached.
> > 
> > cat /proc/sys/net/ipv4/xfrm4_gc_thresh
> > 1073741823
> > 
> > I guess this was not intentional.
> 
> Do you mean for IPSEC routes?  For non-IPSEC routes on ipv4 there
> is nothing to garbage collect.

Yes, I mean IPsec routes. We still cache them at the flow cache
and at sockets, so we should do some garbage collecting.

We could either go back to a static threshold, as it was before

git commit a33bc5c15154c835aae26f16e6a3a7d9ad4acb45
xfrm: select sane defaults for xfrm[4|6] gc_thresh

or do the same as ipv6 does. I'll take care of this.

Btw. it seems to me that the flow cache has similar limitations
as the routing cache had. At least I was able to fill the flow
cache with a nmap scan from a remote entity. In practice, it's
hard to DOS the flow cache because we use a Jenkins hash with
a random initialization value, but this was the same with the
routing cache.

--
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