On Wed, Jan 10, 2007 at 10:06:05PM -0800, David Miller wrote:
>
> One thing we could do is force a full flow cache flush when some
> percentage before the generation count would overflow. Say every
> %80 of the generation ID space? That gives enough space to ensure
> the flush tasklet runs befor
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 11 Jan 2007 10:27:13 +1100
> On Wed, Jan 10, 2007 at 03:08:55PM -0600, Venkat Yekkirala wrote:
> >
> > I was talking about this (the latter) as well. Currently, on a proper
> > "negative", -ESRCH is returned by security_xfrm_policy_lookup(), and
> >
Hi Paul:
On Wed, Jan 10, 2007 at 11:11:43AM -0500, Paul Moore wrote:
>
> I'm far from a flow cache expert (David, James, and Venkat will probably be
> able to give you much better feedback) I did notice a few things which may or
> may not be issues ... comments below. FWIW, I believe Venkat is
On Wed, Jan 10, 2007 at 03:08:55PM -0600, Venkat Yekkirala wrote:
>
> I was talking about this (the latter) as well. Currently, on a proper
> "negative", -ESRCH is returned by security_xfrm_policy_lookup(), and
> this comes back up as a 0 from resolver(), correctly indicating NO
> applicable
> xfr
> > Only, on a security policy denial (-ESRCH from the LSM hook), a 0
> > is returned by the resolver to signify no applicable policy since
> > a negative result is akin to no policy. And I see the "no policy"
> > case is already cached.
>
> I'm not talking about an xfrm policy lookup failure, that
On Wed, Jan 10, 2007 at 11:41:07AM -0600, Venkat Yekkirala wrote:
>
> Only, on a security policy denial (-ESRCH from the LSM hook), a 0
> is returned by the resolver to signify no applicable policy since
> a negative result is akin to no policy. And I see the "no policy"
> case is already cached.
> > This patch causes security policy denials to be cached instead of
> > causing a relookup every time.
Only, on a security policy denial (-ESRCH from the LSM hook), a 0
is returned by the resolver to signify no applicable policy since
a negative result is akin to no policy. And I see the "no pol
On Wednesday, January 10 2007 2:22 am, Herbert Xu wrote:
> Hi:
>
> [IPSEC] flow: Cache negative security checks
Hi Herbert,
I'm far from a flow cache expert (David, James, and Venkat will probably be
able to give you much better feedback) I did notice a few things which may or
may not be issues
> > So if the security folks actually care about this, they'd need to
> > flush the flow cache whenever a relevant change is made to the
> > security database.
I do not believe we are doing this. I will look into this ASAP.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
On Wed, 10 Jan 2007, Herbert Xu wrote:
> Hi:
>
> [IPSEC] flow: Cache negative security checks
We did some work in this part of the code a few months back -- IIRC it was
resolved correctly from a security point of view.
(cc'ing Venkat & Paul for review).
>
> This patch causes security policy
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 10 Jan 2007 18:22:51 +1100
> This patch also happens to fix a nasty bug where if an expiring
> flow entry that's not at the head happens to trigger a security
> denial, all entries before it are removed from the cache and
> leaked.
Nasty, this is be
Hi:
[IPSEC] flow: Cache negative security checks
This patch causes security policy denials to be cached instead of
causing a relookup every time. This is OK because we already cache
positive security policy results which is strictly worse as far as
security is concerned. In particular, if the s
12 matches
Mail list logo
