From owner-freebsd-ipfw@FreeBSD.ORG Wed Dec 28 10:26:12 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02563106566B; Wed, 28 Dec 2011 10:26:12 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id ADFCB8FC1E; Wed, 28 Dec 2011 10:26:11 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 17E7C73027; Wed, 28 Dec 2011 11:42:51 +0100 (CET) Date: Wed, 28 Dec 2011 11:42:51 +0100 From: Luigi Rizzo To: Lev Serebryakov Message-ID: <20111228104251.GB74183@onelab2.iet.unipi.it> References: <1498545030.20111227015431@nitronet.pl> <4EF9ADBC.8090402@FreeBSD.org> <4EFA3F6F.9040404@sentex.net> <4EFA40D7.60206@FreeBSD.org> <444957640.20111228102844@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <444957640.20111228102844@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: Pawel Tyll , Adrian Chadd , "Alexander V. Chernikov" , Mike Tancsa , freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: Firewall Profiling. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 10:26:12 -0000 On Wed, Dec 28, 2011 at 10:28:44AM +0400, Lev Serebryakov wrote: > Hello, Adrian. > You wrote 28 ??????? 2011 ?., 10:04:13: > > > Maybe someone should write one and open source it this time.. :) > In presence of LLVM in the base, it looks, that we should generate > native code from IPFW bytecodes, without intermediate C code :) > Looks doeable! There is a problem here. You have to trust the native code before allowing its execution in the kernel. So either you implement some form of sandboxing or code validator before accepting a blob of native code from the setsockopt(), or you generate the code directly within the kernel. But with these sizes you cannot embed clang or gcc in the kernel: > size /usr/bin/clang text data bss dec hex filename 31892505 538200 76544 32507249 1f00571 /usr/bin/clang > size /usr/libexec/cc1 text data bss dec hex filename 6172008 39800 723320 6935128 69d258 /usr/libexec/cc1 maybe you can embed tcc or libtcc: > size `which tcc` text data bss dec hex filename 127573 600 42680 170853 29b65 /usr/local/bin/tcc though i would guess that a custom code generator is probably simpler to write (perhaps reusing sys/i386/i386/bpf_jit_machdep.c and its amd64 counterpart) cheers luigi