From owner-freebsd-arch@FreeBSD.ORG Fri Jul 20 20:29:24 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94B0C16A417; Fri, 20 Jul 2007 20:29:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E003013C45A; Fri, 20 Jul 2007 20:29:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9528346B95; Fri, 20 Jul 2007 16:29:22 -0400 (EDT) Date: Fri, 20 Jul 2007 21:29:22 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Paul Allen In-Reply-To: <20070720191201.GE5504@regurgitate.ugcs.caltech.edu> Message-ID: <20070720212206.J83919@fledge.watson.org> References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> <20070720111539.U1096@fledge.watson.org> <46A100C2.1030606@elischer.org> <20070720191201.GE5504@regurgitate.ugcs.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , freebsd-pf@freebsd.org, Max Laier Subject: Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2007 20:29:24 -0000 On Fri, 20 Jul 2007, Paul Allen wrote: > From Julian Elischer , Fri, Jul 20, 2007 at 11:36:50AM -0700: >> Robert Watson wrote: >>> On Tue, 17 Jul 2007, Max Laier wrote: >>> >>> So far I have had 0 (zero) reports of problems since this thread began. >>> Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* try >>> running their firewalls without debug.mpsafenet -- ignore the witness >>> warnings and/or disable witness, and let us know if you experience >>> deadlocks. We're reaching the very end of the merge cycle for 7.0, and I >>> would really like to remove the Giant crutches (now effectively unused) >>> from the network stack so it's not part of the ABI/API, the code is >>> simplified and cleaned up, etc. > > Wasn't there a a clear solution to the uid/gid problem involving flip-pages: > eliminate the pf lock by forcing reconfigurations to build a parallel > data-structure and then perform an atomic operation to exchange the > pointers. I think there are a few potential solutions and areas for work here, the trick is figuring out the best approach to get 7.0 out the door. I think any long term structural changes to the firewalls should be avoided at this point, and targeted at 7.1 or 8.0. FYI, my feeling is that the current approach taken, using a pcb lookup in the firewall, is not really an appropriate solution to the problem. Among other things, there are (small) race conditions such that the lookup could return one pcb in the input path and use that for the check, but another pcb during TCP-layer delivery. The lock order reversal warning is a symptom of reaching across layers in fairly ugly (and atomicity-unsafe) ways. One idea that I'd been pondering was having the inpcb code in the TCP/UDP/SCTP/etc layers invoke event handlers as bindings/connections are made, making credentials and other information available to firewall packages, which could then cache information under their own locks. > AFAIK, Max's patch was just an ugly hack and it isn't really suitable for > performance reasons. > > What's the state of MAC for the networking stack? Are we able to restrict > particular uid's to listening only on particular ports? See mac_portacl(4), which is a functional but not particularly elegant implementation of this idea. In Mac OS X Leopard, many of the traditional "firewall" sorts of checks are now performed at the socket layer using this sort of approach -- this provides greater application context, allows control of things like binding/listening, not just packet transmission and receipt, and provides access to the data as received at the application layer rather than at the datagram layer, avoiding the need for normalization. The MAC Framework will not be enabled by default in 7.0, but one of my goals for 8.0 is to ship the framework enabled in GENERIC by default. This will require a significant amount of performance optimization to do. Robert N M Watson Computer Laboratory University of Cambridge