From owner-cvs-all Mon May 13 4:56: 5 2002 Delivered-To: cvs-all@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id AE73237B401; Mon, 13 May 2002 04:55:57 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.3/8.12.3) with SMTP id g4DBtXb5043947; Mon, 13 May 2002 07:55:33 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 13 May 2002 07:55:33 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp Cc: John Hay , Luigi Rizzo , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/net if_ethersubr.c src/sys/netinet ip_dummynet.c ip_dummynet.h In-Reply-To: <13469.1021290439@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 13 May 2002, Poul-Henning Kamp wrote: > In message <200205131143.g4DBhrH38559@zibbi.icomtek.csir.co.za>, John Hay write > s: > > >Would one still be able to add or remove a single rule then? That is > >a very usefull feature for me. > > Yes, it would take a tiny fraction of a second longer because you would > have to run the c-compiler and kldload but otherwise no change. And nothing says you can't continue to support an older kernel-derived rule processing block in addition to the fast implementation. Given the likely performance hit for bpf, I'd rather see the compiled version. Bill's prototype is probably a good place to start looking--I recall his performance numbers being really spectacular, and he had a number of parallel cleanups. The interesting bits of the work are probably how you call out to some existing symbols to do processing related to state management, "me" processing, etc. One downside to the approach, and a reason I want to keep a kernel-based rule management system in place as a fallback, is that it means modifying firewall rules requires the privilege to set/replace/remove running kernel modules. This is a privilege it would be nice to be able to have a running system not use regularly under some circumstances. Securelevels are the handwave there, but when running the MAC code in a mobile computing environment where rules need updating, it would be helpful. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message