netdev - Re: xfrm_state locking regression...

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: <20080902.234723.163403187.davem@davemloft.net>
Date:	Tue, 02 Sep 2008 23:47:23 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	timo.teras@....fi
Cc:	herbert@...dor.apana.org.au, netdev@...r.kernel.org
Subject: Re: xfrm_state locking regression...

From: Timo Teräs <timo.teras@....fi>
Date: Wed, 03 Sep 2008 09:45:48 +0300

> David Miller wrote:
> > Once there are no list references, there cannot be any other references.
> > So in fact it seems to me that unlinking when the xfrm_state is removed
> > from those other lists makes perfect sense.
> > 
> > If __xfrm_state_delete sets the state to DEAD, and you skip xfrm_state
> > objects marked DEAD, why does the ->all list reference have to survive
> > past __xfrm_state_delete()?
> > 
> > It seems the perfect place to do the ->all removal.
> 
> 1. xfrm_state_walk() called, it returns but holds an entry since
>    the walking was interrupted temporarily (e.g. full netlink buffer).
> 
> 2. xfrm_state_delete() called to the entry that xfrm_state_walk()
>    is keeping a pointer to and it is unlinked.
> 
> 3. xfrm_state_walk() called again, it tries to resume list walking
>    but whoops, the entry was unlinked and kaboom.

Get creative, use a key of some sort to continue the walk, that's what
other netlink'ish subsystems use.

> Yes, but the dumping code produced crap. It could dump same entry
> multiple times, miss entries and was dog slow. With it there was
> no possibility to keep userland in sync with kernel SPD/SAD because
> entries were lost.

I'd rather see an entry twice in a dump than have my IPSEC gateway
lockup, or run slower because we take a lock twice as often as
necessary during object destruction.
--
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