Date: Wed, 18 Apr 2007 20:18:27 +0200 From: Max Laier <max@love2party.net> To: freebsd-current@freebsd.org Cc: Tillman Hodgson <tillman@seekingfire.com> Subject: Re: Panic on boot with April 16 src (lengthy info attached) Message-ID: <200704182018.35054.max@love2party.net> In-Reply-To: <20070418154950.GM1225@seekingfire.com> References: <20070417153357.GA1335@seekingfire.com> <20070418084345.H2913@fledge.watson.org> <20070418154950.GM1225@seekingfire.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2830636.rBnoFHnBoV
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Wednesday 18 April 2007 17:49, Tillman Hodgson wrote:
> On Wed, Apr 18, 2007 at 08:54:00AM +0100, Robert Watson wrote:
> > Things get sticky deep in the firewall code because our firewalls
> > include credential-aware rules, which essentially "peek up the stack"
> > in order to decide what user is associated with a packet before
> > delivery to the connection is done. The firewall rule lock is held
> > over this lookup and inspection of TCP-layer state. In the out-bound
> > path, we pass down the TCP state reference (PCB pointer) and
> > guarantee the lock is already held. However, in the in-bound
> > direction, the firewall has to do the full lookup and lock
> > acquisition. Which reverses the lock order, and can lead to
> > deadlocks.
>
> Thanks for the explanation :-)
>
> Previously you pointed out the ipfw man page which seems to be say the
> same thing (albeit with much less detail):
>
> gid group
> Matches all TCP or UDP packets sent by or received for a group.
> A group may be specified by name or number. This option should
> be used only if debug.mpsafenet=3D0 to avoid possible deadlocks due
> to layering violations in its implementation.
>
> Setting debug.mpsafenet=3D0 worked for me until the TCP timer change. Is
> the LOR situation always true for every inbound packet, or only with
> certain firewall rules in place?
>
> That question has me wondering if I can avoid the issue by avoiding
> certain PF features. My current ruleset is pretty simple. If I drop the
> variables definitions and comments, the whole thing is 13 lines:
>
> nat on $ext_if from $internal_net to any -> ($ext_if)
> rdr on $int_if proto tcp from $internal_net to any port ftp ->
> 127.0.0.1 port 8021 block log all
> pass quick on lo0 all
> pass quick on $int_if proto ospf all
> pass in on $ext_if inet proto tcp from any to ($ext_if) port
> $tcp_services flags S/SA keep state pass in on $ext_if inet proto udp
> from any to ($ext_if) port $udp_services keep state pass in on $ext_if
> inet proto icmp all icmp-type $icmp_types keep state pass in on $ext_if
> inet proto tcp from any to $ext_if user proxy keep state pass in on
> $int_if from $metanetwork to any
> pass out on $int_if from any to $metanetwork
> pass out on $ext_if proto tcp all modulate state flags S/SA
> pass out on $ext_if proto { udp, icmp } all keep state
Running Current you can try to include "options PF_MPSAFE_UGID". This is=20
a hack that allows the use of user/group rules in a debug.mpsafe=3D1=20
environment. Unfortunately, I never got any feedback on this albeit=20
throwing it after everybody with these symptoms. Please report back!
=2D-=20
/"\ Best regards, | mlaier@freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
--nextPart2830636.rBnoFHnBoV
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQBGJmD7XyyEoT62BG0RAnMEAJsFQPkFLjnSF/OaGvt66Vy9LpZhgACfW1mf
8OOQLxNfV8XuxPS02O77KAY=
=ieQT
-----END PGP SIGNATURE-----
--nextPart2830636.rBnoFHnBoV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704182018.35054.max>