Date: Tue, 24 Apr 2012 21:47:07 +0400 From: "Alexander V. Chernikov" <melifaro@FreeBSD.org> To: Hiroki Sato <hrs@FreeBSD.org> Cc: freebsd-ipfw@FreeBSD.org Subject: Re: CFR: ipfw0 pseudo-interface clonable Message-ID: <4F96E71B.9020405@FreeBSD.org> In-Reply-To: <20120425.020518.406495893112283552.hrs@allbsd.org> References: <20120425.002600.1631867625819249738.hrs@allbsd.org> <4F96D11B.2060007@FreeBSD.org> <20120425.020518.406495893112283552.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24.04.2012 21:05, Hiroki Sato wrote: > "Alexander V. Chernikov"<melifaro@FreeBSD.org> wrote > in<4F96D11B.2060007@FreeBSD.org>: > > me> On 24.04.2012 19:26, Hiroki Sato wrote: > me> > Hi, > me> > > me> > I created the attached patch to make the current ipfw0 > me> > pseudo-interface clonable. The functionality of ipfw0 logging > me> > interface is not changed by this patch, but the ipfw0 > me> > pseudo-interface is not created by default and can be created with > me> > the following command: > me> > > me> > # ifconfig ipfw0 create > me> > > me> > Any objection to commit this patch? The primary motivation for this > me> > change is that presence of the interface by default increases size of > me> > the interface list, which is returned by NET_RT_IFLIST sysctl even > me> > when the sysadmin does not need it. Also this pseudo-interface can > me> > confuse the sysadmin and/or network-related userland utilities like > me> > SNMP agent. With this patch, one can use ifconfig(8) to > me> > create/destroy the pseudo-interface as necessary. > me> > me> ipfw_log() log_if usage is not protected, so it is possible to trigger > me> use-after-free. > > Ah, right. I will revise lock handling and resubmit the patch. > > me> Maybe it is better to have some interface flag which makes > me> NET_RT_IFLIST skip given interface ? > > I do not think so. NET_RT_IFLIST should be able to list all of the > interfaces because it is the purpose. Okay, another try (afair already discussed somewhere): Do we really need all BPF providers to have ifnets? It seems that removing all bp_bif depends from BPF code is not so hard task. > > -- Hiroki -- WBR, Alexander
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F96E71B.9020405>