Re: ipfw: LOR/panic with uid rules

On Tuesday 23 September 2008 20:18:19 Ben Kaduk wrote:
> On Tue, Sep 23, 2008 at 12:51 PM, Stefan Ehmann <shoesoft_at_gmx.net> wrote:
> > Hello,
> >
> > Also posted about this problem recently in stable_at_. But got no replies
> > there. So I tried on a recent CURRENT but the problem persists:
> >
> > ipfw rules using uid are causing a deadlock.
> > eg. allow ip from any to any uid root
> > A simple HTTP fetch triggers this problem nearly instantly.
> >
> > For me, this problem existed in 6.x with PREEMPTION enabled. It was fixed
> > in 7.0. But in RELENG_7 and head it's back. This is a single processor
> > i386 machine.
>
> I don't think this was ever guaranteed to work.  See this post by
> Robert Watson to freebsd-hackers:
> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-September/025930.ht
>ml Perhaps the biggest problem is that there's a stack-layering violation
> inherent in this sort of rule; Robert's message has more detail.
Thanks for the pointer.

Before 7.0(?) this could be found in ipfw(8):
This option should be used only if debug.mpsafenet=0 to avoid possible 
deadlocks due to layering violations in its implementation.

But then debug.mpsafenet no longer exists.

My point being:
I'm probably not the only one upgrading from 7.0 to 7.1 with uid rules.
It would be nice if there was at least a word of warning either in ipfw(8) or 
in the release notes.

Apparently it's seems to be working in some configurations. Otherwise the patch 
in the thread above wouldn't make much sense. Maybe it would work here if I 
disabled PREEMPTION. I can live without uid rules although I found them very 
handy in some situations.

I have never tried it but Linux also seems to have problems with these rules. 
From the iptables manpage:
NOTE: pid, sid and command matching are broken on SMP

> Nonetheless, it might be interesting if you had the time to track down
> a particular set of changes that caused the problem to return.
Can't promise anything. Maybe I got some time this weekend.

-- 
Stefan