From owner-freebsd-arch@FreeBSD.ORG Sun Jun 11 03:18:44 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F41B16A41F; Sun, 11 Jun 2006 03:18:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id E93E043D46; Sun, 11 Jun 2006 03:18:43 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.3.5]) ([10.251.60.18]) by a50.ironport.com with ESMTP; 10 Jun 2006 20:18:42 -0700 Message-ID: <448B8B7A.1020008@elischer.org> Date: Sun, 11 Jun 2006 11:18:18 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Lyashkov References: <1149610678.4074.42.camel@berloga.shadowland> <448633F2.7030902@elischer.org> <20060607095824.W53690@fledge.watson.org> <200606070819.04301.jhb@freebsd.org> <4486E41B.4000003@elischer.org> <1149692184.3224.208.camel@berloga.shadowland> <4486EBBD.3090404@elischer.org> <1149757290.3222.44.camel@berloga.shadowland> <1149786697.3222.91.camel@berloga.shadowland> <44897693.5050306@elischer.org> <1149969164.3215.66.camel@berloga.shadowland> In-Reply-To: <1149969164.3215.66.camel@berloga.shadowland> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: Robert Watson , freebsd-arch@freebsd.org Subject: Re: jail extensions 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: Sun, 11 Jun 2006 03:18:44 -0000 Alex Lyashkov wrote: >÷ ðÔÎ, 09.06.2006, × 16:24, Julian Elischer ÐÉÛÅÔ: > >>Alex Lyashkov wrote: >> >> >>>>2) at MOD_LOAD case run loop for each prisons and init private data for >>>>this module at all contexts. At this way module always 'exist' at all >>>>contexts. >>>>and disable module compiling (loading) when module don`t marked jail >>>>safe. >>>> >>>> >>>> >>>example for this way. >>>http://cvs.freevps.com/index.cgi/kernel/include/linux/freevps/s_context_xfrm.h?rev=1.3 >>>http://cvs.freevps.com/index.cgi/kernel/net/ipv4/ah4.c?rev=1.3 >>>ah4_init/ah4_fini functions. >>> >>> >>> >>this is the bit that is obvious. >> >>The hard bit is the non obvious difficulty of changing all existing >>modules in such away that >>they can be compiled both in the new way, and in a way that they are >>still compiled to the old way. >> >>You need to put all the currently global variables into a structure that >>can be instantiated >>for each jail, but in order to make this continue to work in the >>existing system, they still need to >>be compiled as a global when the normal buold is made. >> >>for this reason Marco and I were looking at various macros that can be >>defined to >>allow the variables to be compiled both ways. >> >>For example : >> >> >>int xx; >>static int yy; >>struct a { >> int aa; >> int bb; >>} cc; >> >>might become: >> >>VM_GLOBAL_START(modname) >> int xx; >> VMG_STATIC int yy; >> struct a { >> int aa; >> int bb; >> } cc; >> VM_GLOBAL_STOP(modname) >> >> >>You would access these as: >> VM_GLOBAL(modname, yy) = 2 >> foobar( VM_GLOBAL_STRUCT(cc, modname)->bb); >> >>or similar. >> >> >> >> >And I can`t find any benefits of give up old way when create >per module >struct module_data_$name { > int xx; > int yy; > struct a { > int aa; > int bb; > } cc; >}; >and use access as $name_data(context, yy) = 2. >for non jail kernel it`s should be converted to always access via >prison0. >main difficulty is convert access to variables to use macros, not are >create struct. > >is anybody can review my patch and point me any wrong parts > It's not a technical problem. It's the fact that when we introduce these things we always try to do it is a way so that there is a period where both old and new can co-exist. It would also be useful to have a set of macros (similar to the current SYSINIT) that make this easy to do. If you do this then you are adding two indirections to every global access as you need to access the struct via the current jail. people who compile this out are not likely to want to have that set of indirections for no purpose, especially during the settl-down eriod when it is new. If you want to not make it optional then, yes, but that in general is not how most large new work is done. And expect people to complain bitterly about any slow-down you introduce for people who don't want that fearture. ESPECIALLY in networking. From owner-freebsd-arch@FreeBSD.ORG Sun Jun 11 13:25:30 2006 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8614716A41B for ; Sun, 11 Jun 2006 13:25:30 +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 3BE5E43D45 for ; Sun, 11 Jun 2006 13:25:30 +0000 (GMT) (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 E599946BE7 for ; Sun, 11 Jun 2006 09:25:29 -0400 (EDT) Date: Sun, 11 Jun 2006 14:25:29 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Message-ID: <20060611141632.Y26634@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: MFC of socket/protocol reference improvements 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: Sun, 11 Jun 2006 13:25:30 -0000 Dear All, I'm in the process of evaluating a possible MFC over the socket/protocol reference changes I made in April, 2006, to the RELENG_6 branch. Over the past few months, these changes have been gradually refined, and a number of bugs (of varying severity) have been fixed. These changes are important because they close a significant number of races, reduce the locking overhead and improve parallelism, and lay the groundwork for future improvement in the socket and protocol code. However, they also make significant changes in a number of important network protocols (such as TCP), and change the semantics of the socket/protocol interface (protosw.h). I think these changes are important to our short and long term goals of improving network stack performance and architecture. My original plan was to start looking in detail at the MFC after about three months of settling time, which is in about three weeks. I continue to plan to do this. A few specific points for discussion: (1) Normally, RELENG_* has significant constraints on changes to the kernel APIs used by loadable modules -- especially for device drivers. In the past, we've not made a lot of changes to the protocol switch interface, and historically it hasn't been a run-time extensible interface. Andre has recent made changes to allow IP protocols to be loaded at runtime, such as IP divert, and these will be affected, however. Do we consider modules programmed against these interfaces to be "breakable" -- i.e., the require a recompile and or changes in the RELENG_6 branch? (2) More testing would really be appreciated. I caught a subtle bug in the handling of the retransmit timer in the context of my changes by accident as a result of close analysis of TCP traces through a firewall -- I noticed some "odd" packets that were, with a bit of time, tracked to their source. However, this sort of thing is really subtle. Any help determining whether there are other regressions in TCP behavior would be greatly appreciated. While we've now hammered on the new code quite a bit, and it fixes some known panics in RELENG_6, I would categorize these changes as high risk, as they touch quite sensitive and heavily deployed code. Getting the 7.x code tested in diverse high load environments before the MFC would be very good. I'm still in the process of looking at further refinements of the socket/protocol relationship, which may be candidates for future merging, and will depend on these changes. Among other things, I've been looking at further evolving the notion of socket close vs. socket detach, which are currently conflated notions, leading to both a lack of clarity and lack of flexibility in the current API. In turn, that has presented a problem with experimenting with alternative locking strategies, such as vertical integration of locks between the socket and protocol layers. Getting these changes into RELENG_6 will depend on these earlier changes being merged. Robert N M Watson Computer Laboratory Universty of Cambridge From owner-freebsd-arch@FreeBSD.ORG Sun Jun 11 17:23:23 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0238316A418; Sun, 11 Jun 2006 17:23:23 +0000 (UTC) (envelope-from shadow@psoft.net) Received: from mail.sevcity.net (ns.sevcity.net [193.47.166.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B0F643D46; Sun, 11 Jun 2006 17:23:19 +0000 (GMT) (envelope-from shadow@psoft.net) Received: from mail.sevcity.net (service.sevcity [127.0.0.1]) by mail.sevcity.net (Postfix) with ESMTP id 562BB170009; Sun, 11 Jun 2006 20:24:56 +0300 (EEST) Received: from berloga.shadowland (umka.sevcity.net [193.47.166.138]) by mail.sevcity.net (Postfix) with ESMTP id 1F55B170004; Sun, 11 Jun 2006 20:24:55 +0300 (EEST) Received: from berloga.shadowland (berloga.shadowland [127.0.0.1]) by berloga.shadowland (8.12.11.20060308/8.12.11) with ESMTP id k5BHNE9T021378; Sun, 11 Jun 2006 20:23:15 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11.20060308/8.12.11/Submit) id k5BHNDD4021374; Sun, 11 Jun 2006 20:23:13 +0300 From: Alex Lyashkov To: Julian Elischer In-Reply-To: <448B8B7A.1020008@elischer.org> References: <1149610678.4074.42.camel@berloga.shadowland> <448633F2.7030902@elischer.org> <20060607095824.W53690@fledge.watson.org> <200606070819.04301.jhb@freebsd.org> <4486E41B.4000003@elischer.org> <1149692184.3224.208.camel@berloga.shadowland> <4486EBBD.3090404@elischer.org> <1149757290.3222.44.camel@berloga.shadowland> <1149786697.3222.91.camel@berloga.shadowland> <44897693.5050306@elischer.org> <1149969164.3215.66.camel@berloga.shadowland> <448B8B7A.1020008@elischer.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Positive Software Message-Id: <1150046593.3315.18.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Date: Sun, 11 Jun 2006 20:23:13 +0300 X-Virus-Scanned: ClamAV using ClamSMTP Cc: Robert Watson , freebsd-arch@freebsd.org Subject: Re: jail extensions 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: Sun, 11 Jun 2006 17:23:23 -0000 > > It's not a technical problem. > > It's the fact that when we introduce these things we always try to do > it is a way so > that there is a period where both old and new can co-exist. > > It would also be useful to have a set of macros (similar to the current > SYSINIT) > that make this easy to do. > > If you do this then you are adding two indirections to every global access > as you need to access the struct via the current jail. > > people who compile this out are not likely to want to have that set of > indirections > for no purpose, especially during the settl-down eriod when it is new. > > If you want to not make it optional then, yes, but that in general is > not how most large new > work is done. And expect people to complain bitterly about any slow-down > you introduce for > people who don't want that fearture. ESPECIALLY in networking. > my change log has record - 'option JAIL' added to kernel config, without it - kernel build at "old" way. In future, after all of need modules will be rewrite to support jail, - this behaviour can be changed and to disable only codepath where jail add overhead (for my FreeVPS project it`s only L2 routing for separate packets between context) or disable code only used with jail. -- FreeVPS Developers Team http://www.freevps.com Positive Software http://www.psoft.net From owner-freebsd-arch@FreeBSD.ORG Mon Jun 12 22:07:31 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42EAF16A418; Mon, 12 Jun 2006 22:07:31 +0000 (UTC) (envelope-from peter@wemm.org) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11FDA43D48; Mon, 12 Jun 2006 22:07:27 +0000 (GMT) (envelope-from peter@wemm.org) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id E04671979A; Mon, 12 Jun 2006 15:07:26 -0700 (PDT) From: Peter Wemm To: freebsd-arch@freebsd.org Date: Mon, 12 Jun 2006 15:07:26 -0700 User-Agent: KMail/1.9.1 References: <18115.1148803531@critter.freebsd.dk> In-Reply-To: <18115.1148803531@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606121507.26764.peter@wemm.org> Cc: arch@freebsd.org, Poul-Henning Kamp Subject: Re: A sort of plan for consoles in FreeBSD 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: Mon, 12 Jun 2006 22:07:31 -0000 On Sunday 28 May 2006 01:05, Poul-Henning Kamp wrote: > In message <20060528.011518.1306332021.imp@bsdimp.com>, "M. Warner > Losh" writes > > >In message: <16029.1148764704@critter.freebsd.dk> > > > > Poul-Henning Kamp writes: > >: 4. The /dev/console device in multi-user mode. > >: Emergency output device for critical messages. > > > >Who is generating these messages? > > Typically programs in distress. FWIW. The syslog(3) library call will open /dev/console if it cannot connect to the syslog socket and LOG_CONS is set. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Mon Jun 12 22:07:31 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42EAF16A418; Mon, 12 Jun 2006 22:07:31 +0000 (UTC) (envelope-from peter@wemm.org) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11FDA43D48; Mon, 12 Jun 2006 22:07:27 +0000 (GMT) (envelope-from peter@wemm.org) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id E04671979A; Mon, 12 Jun 2006 15:07:26 -0700 (PDT) From: Peter Wemm To: freebsd-arch@freebsd.org Date: Mon, 12 Jun 2006 15:07:26 -0700 User-Agent: KMail/1.9.1 References: <18115.1148803531@critter.freebsd.dk> In-Reply-To: <18115.1148803531@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606121507.26764.peter@wemm.org> Cc: arch@freebsd.org, Poul-Henning Kamp Subject: Re: A sort of plan for consoles in FreeBSD 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: Mon, 12 Jun 2006 22:07:31 -0000 On Sunday 28 May 2006 01:05, Poul-Henning Kamp wrote: > In message <20060528.011518.1306332021.imp@bsdimp.com>, "M. Warner > Losh" writes > > >In message: <16029.1148764704@critter.freebsd.dk> > > > > Poul-Henning Kamp writes: > >: 4. The /dev/console device in multi-user mode. > >: Emergency output device for critical messages. > > > >Who is generating these messages? > > Typically programs in distress. FWIW. The syslog(3) library call will open /dev/console if it cannot connect to the syslog socket and LOG_CONS is set. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Tue Jun 13 02:49:49 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D29716A4CB for ; Tue, 13 Jun 2006 02:49:49 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6387F43D5F for ; Tue, 13 Jun 2006 02:49:46 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 1EC48EB0B77 for ; Tue, 13 Jun 2006 10:49:45 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id 9H1N5bA+gZnL for ; Tue, 13 Jun 2006 10:49:38 +0800 (CST) Received: from [10.217.12.210] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 21E46EB0B3B for ; Tue, 13 Jun 2006 10:49:37 +0800 (CST) From: Xin LI To: freebsd-arch@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Dpq9o/HbflHL57rEfR8e" Organization: The FreeBSD Project Date: Tue, 13 Jun 2006 10:49:34 +0800 Message-Id: <1150166974.936.6.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Cc: Subject: Why do we do if_init for AF_INET even if the interface is running? 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: Tue, 13 Jun 2006 02:49:49 -0000 --=-Dpq9o/HbflHL57rEfR8e Content-Type: multipart/mixed; boundary="=-efWsI2BtVBYfcy+E8XlV" --=-efWsI2BtVBYfcy+E8XlV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Is there any reason why we do if_init() for AF_INET regardless whether the interface is already in IF_DRV_RUNNING? This seems to cause the interface to reinitialize its link level state, which causes the network to stop for a short while. The proposed patch is inspired from NetBSD net/if_ethersubr.c,v 1.86 which says: "When setting an address on an interface, for address families which do not require changing the link-level address, only (*if_init)() if the interface is not already RUNNING." I think we may want this as well. Comments? Cheers, --=20 Xin LI http://www.delphij.net/ --=-efWsI2BtVBYfcy+E8XlV Content-Disposition: attachment; filename=patch-if_ethersubr.c Content-Type: text/x-patch; name=patch-if_ethersubr.c; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SW5kZXg6IGlmX2V0aGVyc3Vici5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9z cmMvc3lzL25ldC9pZl9ldGhlcnN1YnIuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjE1DQpk aWZmIC11IC1yMS4yMTUgaWZfZXRoZXJzdWJyLmMNCi0tLSBpZl9ldGhlcnN1YnIuYwkzIE1hciAy MDA2IDE3OjIxOjA4IC0wMDAwCTEuMjE1DQorKysgaWZfZXRoZXJzdWJyLmMJMTMgSnVuIDIwMDYg MDE6NTU6MzEgLTAwMDANCkBAIC05OTcsNyArOTk3LDggQEANCiAJCXN3aXRjaCAoaWZhLT5pZmFf YWRkci0+c2FfZmFtaWx5KSB7DQogI2lmZGVmIElORVQNCiAJCWNhc2UgQUZfSU5FVDoNCi0JCQlp ZnAtPmlmX2luaXQoaWZwLT5pZl9zb2Z0Yyk7CS8qIGJlZm9yZSBhcnB3aG9oYXMgKi8NCisJCQlp ZiAoIShpZnAtPmlmX2Rydl9mbGFncyAmIElGRl9EUlZfUlVOTklORykpDQorCQkJCWlmcC0+aWZf aW5pdChpZnAtPmlmX3NvZnRjKTsJLyogYmVmb3JlIGFycHdob2hhcyAqLw0KIAkJCWFycF9pZmlu aXQoaWZwLCBpZmEpOw0KIAkJCWJyZWFrOw0KICNlbmRpZg0KQEAgLTEwMjcsNyArMTAyOCw4IEBA DQogCQkJfQ0KICNlbmRpZg0KIAkJZGVmYXVsdDoNCi0JCQlpZnAtPmlmX2luaXQoaWZwLT5pZl9z b2Z0Yyk7DQorCQkJaWYgKCEoaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpKQ0K KwkJCQlpZnAtPmlmX2luaXQoaWZwLT5pZl9zb2Z0Yyk7DQogCQkJYnJlYWs7DQogCQl9DQogCQli cmVhazsNCg== --=-efWsI2BtVBYfcy+E8XlV-- --=-Dpq9o/HbflHL57rEfR8e Content-Type: application/pgp-signature; name=signature.asc Content-Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8=E5=88=86?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBEjie+hcUczkLqiksRAlloAJsFPysHYjKQ6cf4Jh4RLZuZs8JlUQCfetc0 30gvCZreFVQjDAi7CXjR5vM= =gR+e -----END PGP SIGNATURE----- --=-Dpq9o/HbflHL57rEfR8e-- From owner-freebsd-arch@FreeBSD.ORG Tue Jun 13 04:53:05 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EB2816A41A for ; Tue, 13 Jun 2006 04:53:05 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id F350843D46 for ; Tue, 13 Jun 2006 04:53:04 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k5D4qb0x006268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jun 2006 21:52:38 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <448E4495.4030200@errno.com> Date: Mon, 12 Jun 2006 21:52:37 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.2 (X11/20060508) MIME-Version: 1.0 To: Xin LI References: <1150166974.936.6.camel@spirit> In-Reply-To: <1150166974.936.6.camel@spirit> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Why do we do if_init for AF_INET even if the interface is running? 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: Tue, 13 Jun 2006 04:53:05 -0000 Xin LI wrote: > Hi, > > Is there any reason why we do if_init() for AF_INET regardless whether > the interface is already in IF_DRV_RUNNING? This seems to cause the > interface to reinitialize its link level state, which causes the network > to stop for a short while. > > The proposed patch is inspired from NetBSD net/if_ethersubr.c,v 1.86 > which says: > > "When setting an address on an interface, for address families which > do not require changing the link-level address, only (*if_init)() > if the interface is not already RUNNING." > > I think we may want this as well. > > Comments? > > Cheers, > > > ------------------------------------------------------------------------ > > Index: if_ethersubr.c > =================================================================== > RCS file: /home/ncvs/src/sys/net/if_ethersubr.c,v > retrieving revision 1.215 > diff -u -r1.215 if_ethersubr.c > --- if_ethersubr.c 3 Mar 2006 17:21:08 -0000 1.215 > +++ if_ethersubr.c 13 Jun 2006 01:55:31 -0000 > @@ -997,7 +997,8 @@ > switch (ifa->ifa_addr->sa_family) { > #ifdef INET > case AF_INET: > - ifp->if_init(ifp->if_softc); /* before arpwhohas */ > + if (!(ifp->if_drv_flags & IFF_DRV_RUNNING)) > + ifp->if_init(ifp->if_softc); /* before arpwhohas */ > arp_ifinit(ifp, ifa); > break; > #endif > @@ -1027,7 +1028,8 @@ > } > #endif > default: > - ifp->if_init(ifp->if_softc); > + if (!(ifp->if_drv_flags & IFF_DRV_RUNNING)) > + ifp->if_init(ifp->if_softc); > break; > } > break; Try it; you'll find various drivers blow up in their multicast code because they assume the init method is called. I tried to get this same change committed last year because it causes wireless drivers to blow chunks. I finally gave up and stuck a similar change in ieee80211_ioctl. Sam From owner-freebsd-arch@FreeBSD.ORG Tue Jun 13 05:04:19 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12F4C16A418 for ; Tue, 13 Jun 2006 05:04:19 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAAE143D49 for ; Tue, 13 Jun 2006 05:04:18 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k5D53JtQ003990; Mon, 12 Jun 2006 22:03:19 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k5D53J6T003989; Mon, 12 Jun 2006 22:03:19 -0700 Date: Mon, 12 Jun 2006 22:03:19 -0700 From: Brooks Davis To: Xin LI Message-ID: <20060613050319.GA9290@odin.ac.hmc.edu> References: <1150166974.936.6.camel@spirit> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <1150166974.936.6.camel@spirit> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new Cc: freebsd-arch@freebsd.org Subject: Re: Why do we do if_init for AF_INET even if the interface is running? 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: Tue, 13 Jun 2006 05:04:19 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 13, 2006 at 10:49:34AM +0800, Xin LI wrote: > Hi, >=20 > Is there any reason why we do if_init() for AF_INET regardless whether > the interface is already in IF_DRV_RUNNING? This seems to cause the > interface to reinitialize its link level state, which causes the network > to stop for a short while. >=20 > The proposed patch is inspired from NetBSD net/if_ethersubr.c,v 1.86 > which says: >=20 > "When setting an address on an interface, for address families which > do not require changing the link-level address, only (*if_init)() > if the interface is not already RUNNING." >=20 > I think we may want this as well. >=20 > Comments? As Sam says, there are hardware filters that need to be initialized. My feeling is that you're correct that doing so via if_init is a bug since that's way too big a hammer, but there are too many edge cases for it to be possible to have a flag day. If we want to move to more selective updating, the way to do it is probably some sort of flag similar to IFF_NEEDSGIANT that tell the interface subsystem to keep the old behavior and otherwise pass the change down to the driver to decide what it needs to do. That way we could make the change over time and eventually deprecate and then remove the flag. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEjkcWXY6L6fI4GtQRAng2AJ4lyQZVFvQCIy0TzqWjceAj/6IgJwCfU3FX xcKaRkDtttpc15rfBZWdWkk= =pAfW -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From owner-freebsd-arch@FreeBSD.ORG Thu Jun 15 22:53:22 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E065116A47B for ; Thu, 15 Jun 2006 22:53:22 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt6.ihug.co.nz (grunt6.ihug.co.nz [203.109.254.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89CE543D5E for ; Thu, 15 Jun 2006 22:53:15 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt6.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1Fr0i9-0005w2-00; Fri, 16 Jun 2006 10:53:13 +1200 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 945EF1CC37; Fri, 16 Jun 2006 10:53:12 +1200 (NZST) Date: Fri, 16 Jun 2006 10:53:12 +1200 From: Andrew Thompson To: arch@freebsd.org Message-ID: <20060615225312.GB64552@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline User-Agent: Mutt/1.5.11 Cc: net@freebsd.org Subject: enc0 patch for ipsec 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: Thu, 15 Jun 2006 22:53:23 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I have a patch attached that implements the much requested feature of packet filtering ipsec connections. This is a device to expose packets going in/out of ipsec and comes from OpenBSD. There are two functions, a bpf tap which has a basic header with the SPI number which our current tcpdump knows how to display, and handoff to pfil(9) for packet filtering. They way I have hooked it in is compiling it in with fast_ipsec and the extra work is only done when the enc0 interface is created. The interface is not created by default so its a minimal hit, the user will need to 'ifconfig enc0 create' in order to activate it. I believe the locking is correct so it can be created and destroyed at runtime. PRs 98219 and 94829 are requesting this feature. Andrew --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipsec_enc.diff" Index: share/man/man4/enc.4 =================================================================== RCS file: share/man/man4/enc.4 diff -N share/man/man4/enc.4 --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ share/man/man4/enc.4 15 Jun 2006 22:08:24 -0000 @@ -0,0 +1,111 @@ +.\" $OpenBSD: enc.4,v 1.22 2006/05/26 08:51:29 jmc Exp $ +.\" +.\" Copyright (c) 1999 Angelos D. Keromytis +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. All advertising materials mentioning features or use of this software +.\" must display the following acknowledgement: +.\" This product includes software developed by Angelos D. Keromytis. +.\" 4. The name of the author may not be used to endorse or promote products +.\" derived from this software without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd June 16, 2006 +.Dt ENC 4 +.Os +.Sh NAME +.Nm enc +.Nd Encapsulating Interface +.Sh DESCRIPTION +The +.Nm +interface is a software loopback mechanism that allows hosts or +firewalls to filter +.Xr fast_ipsec 4 +traffic using any firewall package that hooks in via the +.Xr pfil 9 +framework. +.Pp +In order to enable packet handoff to +.Xr pfil 9 +and +.Xr bpf 4 , +the +.Dq enc0 +interface needs to be created and marked up. +This is most easily done with the +.Xr ifconfig 8 +.Cm create +command or using the +.Va cloned_interfaces +variable in +.Xr rc.conf 5 . +The interface can also be destroyed at runtime, this will disable packet +interception and filtering. +.Pp +The +.Nm +interface allows an administrator +to see outgoing packets before they have been processed by +.Xr fast_ipsec 4 , +or incoming packets after they have been similarly processed, via +.Xr tcpdump 8 . +.Pp +The +.Dq enc0 +interface inherits all IPsec traffic. +Thus all IPsec traffic can be filtered based on +.Dq enc0 , +and all IPsec traffic could be seen by invoking +.Xr tcpdump 8 +on the +.Dq enc0 +interface. +.Sh EXAMPLES +To create the interface and enable IPsec packet filtering: +.Pp +.Bd -literal -offset indent +ifconfig enc0 create up +.Ed +.Pp +To see all outgoing packets before they have been processed via +.Xr fast_ipsec 4 , +or all incoming packets after they have been similarly processed: +.Pp +.Bd -literal -offset indent +tcpdump -i enc0 +.Ed +.Pp +To disable packet filtering: +.Pp +.Bd -literal -offset indent +ifconfig enc0 destroy +.Ed +.Sh SEE ALSO +.Xr bpf 4 , +.Xr fast_ipsec 4 , +.Xr ipf 4 , +.Xr ipfw 4 , +.Xr pf 4 , +.Xr tcpdump 8 Index: share/man/man4/fast_ipsec.4 =================================================================== RCS file: /home/ncvs/src/share/man/man4/fast_ipsec.4,v retrieving revision 1.3 diff -u -p -r1.3 fast_ipsec.4 --- share/man/man4/fast_ipsec.4 21 Jan 2005 08:36:37 -0000 1.3 +++ share/man/man4/fast_ipsec.4 15 Jun 2006 22:32:58 -0000 @@ -78,10 +78,16 @@ When the protocols are configured for use, all protocols are included in the system. To selectively enable/disable protocols, use .Xr sysctl 8 . +.Pp +The packets can be passed to a virtual interface, +.Dq enc0 , +to perform packet filtering before outbound encryption and after decapsulation +inbound. .Sh DIAGNOSTICS To be added. .Sh SEE ALSO .Xr crypto 4 , +.Xr enc 4 , .Xr ipsec 4 , .Xr setkey 8 , .Xr sysctl 8 Index: sys/conf/files =================================================================== RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.1125 diff -u -p -r1.1125 files --- sys/conf/files 14 Jun 2006 03:03:08 -0000 1.1125 +++ sys/conf/files 15 Jun 2006 21:38:18 -0000 @@ -1459,6 +1459,7 @@ net/if_bridge.c optional if_bridge net/if_clone.c standard net/if_disc.c optional disc net/if_ef.c optional ef +net/if_enc.c optional fast_ipsec net/if_ethersubr.c optional ether net/if_faith.c optional faith net/if_fddisubr.c optional fddi Index: sys/net/if_enc.c =================================================================== RCS file: sys/net/if_enc.c diff -N sys/net/if_enc.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sys/net/if_enc.c 15 Jun 2006 21:38:18 -0000 @@ -0,0 +1,323 @@ +/*- + * Copyright (c) 2006 Andrew Thompson + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. Neither the name of Broadcom Corporation nor the name of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written consent. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS' + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS + * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF + * THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include "opt_inet6.h" + +#ifdef INET6 +#include +#include +#endif + +#include + +#define ENCMTU (1024+512) +#define ENC_HDRLEN 12 + +/* XXX this define must have the same value as in OpenBSD */ +#define M_CONF 0x0400 /* payload was encrypted (ESP-transport) */ +#define M_AUTH 0x0800 /* payload was authenticated (AH or ESP auth) */ +#define M_AUTH_AH 0x2000 /* header was authenticated (AH) */ + +struct enchdr { + u_int32_t af; + u_int32_t spi; + u_int32_t flags; +}; + +struct ifnet *encif; +struct mtx enc_mtx; + +struct enc_softc { + struct ifnet *sc_ifp; +}; + +int encioctl(struct ifnet *, u_long, caddr_t); +int encoutput(struct ifnet *ifp, struct mbuf *m, + struct sockaddr *dst, struct rtentry *rt); +static int enc_clone_create(struct if_clone *, int); +static void enc_clone_destroy(struct ifnet *); + +IFC_SIMPLE_DECLARE(enc, 0); + +static void +enc_clone_destroy(struct ifnet *ifp) +{ + + KASSERT(encif == ifp, ("%s: unknown ifnet", __func__)); + + mtx_lock(&enc_mtx); + encif = NULL; + mtx_unlock(&enc_mtx); + + bpfdetach(ifp); + if_detach(ifp); + if_free(ifp); + +} + +static int +enc_clone_create(struct if_clone *ifc, int unit) +{ + struct ifnet *ifp; + struct enc_softc *sc; + + mtx_lock(&enc_mtx); + if (encif != NULL) + return (EBUSY); + mtx_unlock(&enc_mtx); + + sc = malloc(sizeof(*sc), M_DEVBUF, M_WAITOK|M_ZERO); + ifp = sc->sc_ifp = if_alloc(IFT_ENC); + if (ifp == NULL) { + free(sc, M_DEVBUF); + return (ENOSPC); + } + + if_initname(ifp, ifc->ifc_name, unit); + ifp->if_mtu = ENCMTU; + ifp->if_ioctl = encioctl; + ifp->if_output = encoutput; + ifp->if_snd.ifq_maxlen = ifqmaxlen; + ifp->if_softc = sc; + if_attach(ifp); + bpfattach(ifp, DLT_ENC, ENC_HDRLEN); + + mtx_lock(&enc_mtx); + encif = ifp; + mtx_unlock(&enc_mtx); + + return (0); +} + +static int +enc_modevent(module_t mod, int type, void *data) +{ + switch (type) { + case MOD_LOAD: + mtx_init(&enc_mtx, "enc mtx", NULL, MTX_DEF); + if_clone_attach(&enc_cloner); + break; + case MOD_UNLOAD: + printf("enc module unload - not possible for this module\n"); + return (EINVAL); + default: + return (EOPNOTSUPP); + } + return (0); +} + +static moduledata_t enc_mod = { + "enc", + enc_modevent, + 0 +}; + +DECLARE_MODULE(enc, enc_mod, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_ANY); + +int +encoutput(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, + struct rtentry *rt) +{ + m_freem(m); + return (0); +} + +/* + * Process an ioctl request. + */ +/* ARGSUSED */ +int +encioctl(struct ifnet *ifp, u_long cmd, caddr_t data) +{ + int error = 0; + + switch (cmd) { + + case SIOCSIFFLAGS: + if (ifp->if_flags & IFF_UP) + ifp->if_drv_flags |= IFF_DRV_RUNNING; + else + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; + + break; + + default: + error = EINVAL; + } + return (error); +} + +int +ipsec_filter(struct mbuf **mp, int dir) +{ + int error, i; + struct ip *ip; + + mtx_lock(&enc_mtx); + if (encif == NULL || (encif->if_drv_flags & IFF_DRV_RUNNING) == 0) { + mtx_unlock(&enc_mtx); + return (0); + } + + /* Skip pfil(9) if no filters are loaded */ + if (inet_pfil_hook.ph_busy_count < 0 +#ifdef INET6 + && inet6_pfil_hook.ph_busy_count < 0 +#endif + ) { + mtx_unlock(&enc_mtx); + return (0); + } + + i = min((*mp)->m_pkthdr.len, max_protohdr); + if ((*mp)->m_len < i) { + *mp = m_pullup(*mp, i); + if (*mp == NULL) { + printf("%s: m_pullup failed\n", __func__); + mtx_unlock(&enc_mtx); + return (-1); + } + } + + error = 0; + ip = mtod(*mp, struct ip *); + switch (ip->ip_v) { + case 4: + /* + * before calling the firewall, swap fields the same as + * IP does. here we assume the header is contiguous + */ + ip->ip_len = ntohs(ip->ip_len); + ip->ip_off = ntohs(ip->ip_off); + + error = pfil_run_hooks(&inet_pfil_hook, mp, + encif, dir, NULL); + + if (*mp == NULL || error != 0) + break; + + /* restore byte ordering */ + ip = mtod(*mp, struct ip *); + ip->ip_len = htons(ip->ip_len); + ip->ip_off = htons(ip->ip_off); + break; + +#ifdef INET6 + case 6: + error = pfil_run_hooks(&inet6_pfil_hook, mp, + encif, dir, NULL); + break; +#endif + default: + printf("%s: unknown IP version\n", __func__); + } + + mtx_unlock(&enc_mtx); + if (*mp == NULL) + return (error); + if (error != 0) + goto bad; + + return (error); + +bad: + mtx_unlock(&enc_mtx); + m_freem(*mp); + *mp = NULL; + return (error); +} + +void +ipsec_bpf(struct mbuf *m, struct secasvar *sav, int af) +{ + int flags; + struct enchdr hdr; + struct mbuf m1; + + KASSERT(sav != NULL, ("%s: sav is null", __func__)); + + mtx_lock(&enc_mtx); + if (encif == NULL || (encif->if_drv_flags & IFF_DRV_RUNNING) == 0) { + mtx_unlock(&enc_mtx); + return; + } + + if (encif->if_bpf) { + flags = 0; + if (sav->alg_enc != SADB_EALG_NONE) + flags |= M_CONF; + if (sav->alg_auth != SADB_AALG_NONE) + flags |= M_AUTH; + + /* + * We need to prepend the address family as a four byte + * field. Cons up a dummy header to pacify bpf. This + * is safe because bpf will only read from the mbuf + * (i.e., it won't try to free it or keep a pointer a + * to it). + */ + hdr.af = af; + hdr.spi = sav->spi; + hdr.flags = flags; + + m1.m_flags = 0; + m1.m_next = m; + m1.m_len = ENC_HDRLEN; + m1.m_data = (char *) &hdr; + + bpf_mtap(encif->if_bpf, &m1); + } + mtx_unlock(&enc_mtx); +} Index: sys/net/if_types.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_types.h,v retrieving revision 1.21 diff -u -p -r1.21 if_types.h --- sys/net/if_types.h 10 Jun 2005 16:49:19 -0000 1.21 +++ sys/net/if_types.h 15 Jun 2006 21:38:18 -0000 @@ -246,6 +246,7 @@ #define IFT_GIF 0xf0 #define IFT_PVC 0xf1 #define IFT_FAITH 0xf2 +#define IFT_ENC 0xf4 #define IFT_PFLOG 0xf6 #define IFT_PFSYNC 0xf7 #define IFT_CARP 0xf8 /* Common Address Redundancy Protocol */ Index: sys/netipsec/ipsec.h =================================================================== RCS file: /home/ncvs/src/sys/netipsec/ipsec.h,v retrieving revision 1.11 diff -u -p -r1.11 ipsec.h --- sys/netipsec/ipsec.h 10 Apr 2006 15:04:36 -0000 1.11 +++ sys/netipsec/ipsec.h 15 Jun 2006 21:38:18 -0000 @@ -335,6 +335,8 @@ extern int ipsec_replay; extern int ipsec_integrity; #endif +extern struct ifnet *encif; + extern struct newipsecstat newipsecstat; extern struct secpolicy ip4_def_policy; extern int ip4_esp_trans_deflev; @@ -417,6 +419,9 @@ extern void m_checkalignment(const char* extern struct mbuf *m_makespace(struct mbuf *m0, int skip, int hlen, int *off); extern caddr_t m_pad(struct mbuf *m, int n); extern int m_striphdr(struct mbuf *m, int skip, int hlen); +extern int ipsec_filter(struct mbuf **, int); +extern void ipsec_bpf(struct mbuf *, struct secasvar *, int); + #endif /* _KERNEL */ #ifndef _KERNEL Index: sys/netipsec/ipsec_input.c =================================================================== RCS file: /home/ncvs/src/sys/netipsec/ipsec_input.c,v retrieving revision 1.11 diff -u -p -r1.11 ipsec_input.c --- sys/netipsec/ipsec_input.c 4 Jun 2006 19:32:32 -0000 1.11 +++ sys/netipsec/ipsec_input.c 15 Jun 2006 21:38:18 -0000 @@ -443,6 +443,18 @@ ipsec4_common_input_cb(struct mbuf *m, s key_sa_recordxfer(sav, m); /* record data transfer */ /* + * Pass the mbuf to enc0 for bpf and pfil. We will filter the IPIP + * packet later after it has been decapsulated. + */ + if (encif != NULL) { + ipsec_bpf(m, sav, AF_INET); + + if (prot != IPPROTO_IPIP) + if ((error = ipsec_filter(&m, 1)) != 0) + return (error); + } + + /* * Re-dispatch via software interrupt. */ if ((error = netisr_queue(NETISR_IP, m))) { Index: sys/netipsec/ipsec_output.c =================================================================== RCS file: /home/ncvs/src/sys/netipsec/ipsec_output.c,v retrieving revision 1.11 diff -u -p -r1.11 ipsec_output.c --- sys/netipsec/ipsec_output.c 2 Nov 2005 13:46:32 -0000 1.11 +++ sys/netipsec/ipsec_output.c 15 Jun 2006 21:38:18 -0000 @@ -358,6 +358,11 @@ ipsec4_process_packet( goto bad; sav = isr->sav; + + /* pass the mbuf to enc0 for packet filtering */ + if (encif != NULL && (error = ipsec_filter(&m, 2)) != 0) + goto bad; + if (!tunalready) { union sockaddr_union *dst = &sav->sah->saidx.dst; int setdf; @@ -455,6 +460,10 @@ ipsec4_process_packet( } } + /* pass the mbuf to enc0 for bpf processing */ + if (encif != NULL) + ipsec_bpf(m, sav, AF_INET); + /* * Dispatch to the appropriate IPsec transform logic. The * packet will be returned for transmission after crypto Index: sys/netipsec/xform_ipip.c =================================================================== RCS file: /home/ncvs/src/sys/netipsec/xform_ipip.c,v retrieving revision 1.12 diff -u -p -r1.12 xform_ipip.c --- sys/netipsec/xform_ipip.c 30 Mar 2006 18:57:04 -0000 1.12 +++ sys/netipsec/xform_ipip.c 15 Jun 2006 21:38:18 -0000 @@ -345,6 +345,10 @@ _ipip_input(struct mbuf *m, int iphlen, /* Statistics */ ipipstat.ipips_ibytes += m->m_pkthdr.len - iphlen; + /* pass the mbuf to enc0 for packet filtering */ + if (encif != NULL && ipsec_filter(&m, 1) != 0) + return; + /* * Interface pointer stays the same; if no IPsec processing has * been done (or will be done), this will point to a normal --ReaqsoxgOBHFXBhH-- From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 01:03:26 2006 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 030A916A479; Fri, 16 Jun 2006 01:03:26 +0000 (UTC) (envelope-from dwhite@gumbysoft.com) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4CAC43D45; Fri, 16 Jun 2006 01:03:25 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id DEABF72DA5; Thu, 15 Jun 2006 18:01:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id DCAAB72DA2; Thu, 15 Jun 2006 18:01:59 -0700 (PDT) Date: Thu, 15 Jun 2006 18:01:59 -0700 (PDT) From: Doug White To: Robert Watson In-Reply-To: <20060611141632.Y26634@fledge.watson.org> Message-ID: <20060615175853.Y52950@carver.gumbysoft.com> References: <20060611141632.Y26634@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org Subject: Re: MFC of socket/protocol reference improvements 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, 16 Jun 2006 01:03:26 -0000 On Sun, 11 Jun 2006, Robert Watson wrote: > (1) Normally, RELENG_* has significant constraints on changes to the kernel > APIs used by loadable modules -- especially for device drivers. In the > past, we've not made a lot of changes to the protocol switch interface, > and historically it hasn't been a run-time extensible interface. Andre > has recent made changes to allow IP protocols to be loaded at runtime, > such as IP divert, and these will be affected, however. Do we consider > modules programmed against these interfaces to be "breakable" -- i.e., > the > require a recompile and or changes in the RELENG_6 branch? >From a policy standpoint, breaking modules in a -STABLE branch is forbidden since it causes pain for 3rd party developers. Exceptions can be made for changes that provide more benefit than damage caused by breaking the ABI. Usually the question revolves around, "Does anyone actually distribute modules that use that interface?" :-) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 09:57:00 2006 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D87616A47A for ; Fri, 16 Jun 2006 09:57:00 +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 CBFBC43D48 for ; Fri, 16 Jun 2006 09:56:59 +0000 (GMT) (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 8878A46BD4; Fri, 16 Jun 2006 05:56:59 -0400 (EDT) Date: Fri, 16 Jun 2006 10:56:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Doug White In-Reply-To: <20060615175853.Y52950@carver.gumbysoft.com> Message-ID: <20060616102458.N742@fledge.watson.org> References: <20060611141632.Y26634@fledge.watson.org> <20060615175853.Y52950@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org Subject: Re: MFC of socket/protocol reference improvements 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, 16 Jun 2006 09:57:00 -0000 On Thu, 15 Jun 2006, Doug White wrote: > On Sun, 11 Jun 2006, Robert Watson wrote: > >> (1) Normally, RELENG_* has significant constraints on changes to the kernel >> APIs used by loadable modules -- especially for device drivers. In the >> past, we've not made a lot of changes to the protocol switch interface, >> and historically it hasn't been a run-time extensible interface. Andre >> has recent made changes to allow IP protocols to be loaded at runtime, >> such as IP divert, and these will be affected, however. Do we consider >> modules programmed against these interfaces to be "breakable" -- i.e., >> the >> require a recompile and or changes in the RELENG_6 branch? > > From a policy standpoint, breaking modules in a -STABLE branch is forbidden > since it causes pain for 3rd party developers. Exceptions can be made for > changes that provide more benefit than damage caused by breaking the ABI. > > Usually the question revolves around, "Does anyone actually distribute > modules that use that interface?" :-) So far I've identified one third party infiniband stack used in a product that implements the protosw API, and would need changes. However, the scope and nature of the product mean that this wouldn't be a significant issue for them. I guess the question is whether and how many other protocol modules exist out there. My leaning is to say very few, but perhaps those people simply don't talk to me/us. It would be good to know if there are any other significant protocol stacks being distributed in binary form. The source changes are relatively minor to update a protocol, but do need to be done. I have some more changes in the works that follow on the heels of this change that require a slightly larger set of protocol changes -- all in the management of socket setup and teardown (attach, abort, close, detach). The larger overhaul portion of my changes is within protocols, and those changes largely rely on the protocol switch changes. These changes do a couple of things: (1) Close a number of known races and eliminate a number of known panics. For example, a panic in tcp_ctloutput() has been repeatedly reported, and is fixed by this because so_pcb can no longer suddenly become NULL during a call to setsockopt(). (2) Reduce lock contention on the tcbinfo lock by avoiding calling it in the socket send path in a significant number of situations -- specifically, normal, off-the-self send and receive on TCP. (3) Lay the groundwork for future changes to break down tcbinfo and otherwise optimize TCP locking. We can do (1) through some workarounds I've been looking at in a few cases, and I believe specifically in the setsockopt() case. (2) and (3) are basically impossible without these changes, so if we want to get them into RELENG_6 as opposed to just RELENG_7, merging this set of changes is necessary. I hope to post an initial draft patch in a few days -- I'm currently setting up a Perforce branch and merging the changes to that branch, but there are about 65 commits involved. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 15:35:36 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A79D16A47D; Fri, 16 Jun 2006 15:35:36 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87ED243D45; Fri, 16 Jun 2006 15:35:35 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.178.14] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1FrGMA331i-0000Cf; Fri, 16 Jun 2006 17:35:34 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Fri, 16 Jun 2006 17:35:27 +0200 User-Agent: KMail/1.9.1 References: <20060615225312.GB64552@heff.fud.org.nz> In-Reply-To: <20060615225312.GB64552@heff.fud.org.nz> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2154621.EIZNAYH37s"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606161735.33801.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: arch@freebsd.org, Andrew Thompson , net@freebsd.org Subject: Re: enc0 patch for ipsec 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, 16 Jun 2006 15:35:36 -0000 --nextPart2154621.EIZNAYH37s Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 16 June 2006 00:53, Andrew Thompson wrote: > I have a patch attached that implements the much requested feature of > packet filtering ipsec connections. > > This is a device to expose packets going in/out of ipsec and comes > from OpenBSD. There are two functions, a bpf tap which has a basic > header with the SPI number which our current tcpdump knows how to > display, and handoff to pfil(9) for packet filtering. > > They way I have hooked it in is compiling it in with fast_ipsec and > the extra work is only done when the enc0 interface is created. The > interface is not created by default so its a minimal hit, the user > will need to 'ifconfig enc0 create' in order to activate it. I > believe the locking is correct so it can be created and destroyed at > runtime. I think it should get a "device enc" on its own. Some people might conside= r=20 enc(4) to be a security problem so getting it with FAST_IPSEC automatically= =20 isn't preferable. Other than that, great news. Thanks a lot. > PRs 98219 and 94829 are requesting this feature. > > > > Andrew =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2154621.EIZNAYH37s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEks/FXyyEoT62BG0RAtKgAJ4tmOL2iMvLf7KaAmyUB23gT0gAPgCaAyv9 JCyNxxVv06CA/LSaRXMX2d0= =Mtlo -----END PGP SIGNATURE----- --nextPart2154621.EIZNAYH37s-- From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 15:42:13 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DB3D16A47B; Fri, 16 Jun 2006 15:42:13 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from leia.fdn.fr (ns0.fdn.org [80.67.169.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id C707A43D58; Fri, 16 Jun 2006 15:42:11 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by leia.fdn.fr (8.13.3/8.13.3/FDN) with ESMTP id k5GFg8V7001639; Fri, 16 Jun 2006 17:42:09 +0200 Received: by smtp.zeninc.net (smtpd, from userid 1000) id BDE2C3F17; Fri, 16 Jun 2006 17:42:03 +0200 (CEST) Date: Fri, 16 Jun 2006 17:42:03 +0200 From: VANHULLEBUS Yvan To: Andrew Thompson Message-ID: <20060616154203.GA11590@zen.inc> References: <20060615225312.GB64552@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060615225312.GB64552@heff.fud.org.nz> User-Agent: All mail clients suck. This one just sucks less. Cc: arch@freebsd.org, net@freebsd.org Subject: Re: enc0 patch for ipsec 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, 16 Jun 2006 15:42:13 -0000 On Fri, Jun 16, 2006 at 10:53:12AM +1200, Andrew Thompson wrote: > Hi, Hi. > PRs 98219 and 94829 are requesting this feature. Patch provided in PR 94829 does not provide filters hook, but it has support for both IPSEC and FAST_IPSEC. Perhaps we could merge some "features" of both patches, I'll have a look at that. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 16:05:09 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73F7416A47D; Fri, 16 Jun 2006 16:05:09 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4473C43D7E; Fri, 16 Jun 2006 16:05:08 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.178.14] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1FrGol1vD6-0000AE; Fri, 16 Jun 2006 18:05:07 +0200 From: Max Laier Organization: FreeBSD To: "Scott Ullrich" Date: Fri, 16 Jun 2006 18:04:55 +0200 User-Agent: KMail/1.9.1 References: <20060615225312.GB64552@heff.fud.org.nz> <200606161735.33801.max@love2party.net> In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4110410.kbyFMc9pHU"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606161805.06651.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-net@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org Subject: Re: enc0 patch for ipsec 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, 16 Jun 2006 16:05:09 -0000 --nextPart4110410.kbyFMc9pHU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 16 June 2006 17:41, Scott Ullrich wrote: > On 6/16/06, Max Laier wrote: > > I think it should get a "device enc" on its own. Some people might > > consider enc(4) to be a security problem so getting it with FAST_IPSEC > > automatically isn't preferable. > > You have to specifically create the enc0 interface (ifconfig enc0 > create) before it becomes active. Otherwise it will not hit the enc > code path unless the device is created. The issue is, if an attacker manages to get root on your box they are=20 automatically able to read your IPSEC traffic ending at that box. If you=20 don't have enc(4) compiled in, that would be more difficult to do. Same=20 reason you don't want SADB_FLUSH on by default. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart4110410.kbyFMc9pHU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEktayXyyEoT62BG0RAsneAJ9O1gLgquzP085Nqi+8um5aXpnQ/QCfdQVw Xw51C+T0P5BCfzA43UczxwI= =eusH -----END PGP SIGNATURE----- --nextPart4110410.kbyFMc9pHU-- From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 16:14:22 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D8D316A479; Fri, 16 Jun 2006 16:14:22 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F95143D49; Fri, 16 Jun 2006 16:14:21 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.178.14] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1FrGxg0zHV-0000Bm; Fri, 16 Jun 2006 18:14:20 +0200 From: Max Laier Organization: FreeBSD To: "Scott Ullrich" Date: Fri, 16 Jun 2006 18:14:12 +0200 User-Agent: KMail/1.9.1 References: <20060615225312.GB64552@heff.fud.org.nz> <200606161805.06651.max@love2party.net> In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4390624.zale1C6xGP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606161814.19336.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-net@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org Subject: Re: enc0 patch for ipsec 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, 16 Jun 2006 16:14:22 -0000 --nextPart4390624.zale1C6xGP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 16 June 2006 18:09, Scott Ullrich wrote: > On 6/16/06, Max Laier wrote: > > The issue is, if an attacker manages to get root on your box they are > > automatically able to read your IPSEC traffic ending at that box. If y= ou > > don't have enc(4) compiled in, that would be more difficult to do. Same > > reason you don't want SADB_FLUSH on by default. > > Okay, this makes sense. But couldn't you also argue that if someone > gets access to the machine they could also use tcpdump to do the same > thing technically on the internal interface? Just playing devils > advocate.. :) Think tunnel2tunnel or an SA for a local connection, then. Given, if you a= re=20 root you *might* have other means to obtain that information, but that is w= hy=20 we have a switch to turn off bpf, kmem or the like. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart4390624.zale1C6xGP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEktjbXyyEoT62BG0RAmjNAJ9WLPc7LByESWUlyzHR/dt0J9OiigCbBAms Fo8vKq0DHjCKaUeltXeskjk= =FL6S -----END PGP SIGNATURE----- --nextPart4390624.zale1C6xGP-- From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 17:22:21 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFC4A16A474; Fri, 16 Jun 2006 17:22:21 +0000 (UTC) (envelope-from gordon@FreeBSD.org) Received: from spiff.melthusia.org (spiff.melthusia.org [207.67.244.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56F3E43D49; Fri, 16 Jun 2006 17:22:21 +0000 (GMT) (envelope-from gordon@FreeBSD.org) Received: from [192.168.1.50] (cpe-66-91-238-221.san.res.rr.com [66.91.238.221]) (authenticated bits=0) by spiff.melthusia.org (8.12.10/8.12.10) with ESMTP id k5GHMIiR038251; Fri, 16 Jun 2006 10:22:19 -0700 (PDT) (envelope-from gordon@FreeBSD.org) Message-ID: <4492E8CE.1020405@FreeBSD.org> Date: Fri, 16 Jun 2006 10:22:22 -0700 From: Gordon Tetlow User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Max Laier References: <20060615225312.GB64552@heff.fud.org.nz> <200606161735.33801.max@love2party.net> <200606161805.06651.max@love2party.net> In-Reply-To: <200606161805.06651.max@love2party.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org, Andrew Thompson , Scott Ullrich Subject: Re: enc0 patch for ipsec X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gordon@tetlows.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 17:22:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Max Laier wrote: > On Friday 16 June 2006 17:41, Scott Ullrich wrote: >> On 6/16/06, Max Laier wrote: >>> I think it should get a "device enc" on its own. Some people might >>> consider enc(4) to be a security problem so getting it with FAST_IPSEC >>> automatically isn't preferable. >> You have to specifically create the enc0 interface (ifconfig enc0 >> create) before it becomes active. Otherwise it will not hit the enc >> code path unless the device is created. > > The issue is, if an attacker manages to get root on your box they are > automatically able to read your IPSEC traffic ending at that box. If you > don't have enc(4) compiled in, that would be more difficult to do. Same > reason you don't want SADB_FLUSH on by default. Max is absolutely right here. The snooping interface should be a separate option altogether (a la bpf). - -gordon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEktfGRu2t9DV9ZfsRAvyzAJ9jnUigVW7t2SGV89vXStXAZ30b7QCeJ4tZ tBeTqHk9LofxCRf40uFvpZE= =RGmG -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 17:43:58 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD91616A47C for ; Fri, 16 Jun 2006 17:43:58 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CF4843D46 for ; Fri, 16 Jun 2006 17:43:57 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 13453 invoked from network); 16 Jun 2006 17:44:12 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Jun 2006 17:44:12 -0000 Message-ID: <4492EDDA.6080406@freebsd.org> Date: Fri, 16 Jun 2006 19:43:54 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Max Laier References: <20060615225312.GB64552@heff.fud.org.nz> <200606161735.33801.max@love2party.net> <200606161805.06651.max@love2party.net> In-Reply-To: <200606161805.06651.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org, Andrew Thompson , Scott Ullrich Subject: Re: enc0 patch for ipsec 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, 16 Jun 2006 17:43:58 -0000 Max Laier wrote: > On Friday 16 June 2006 17:41, Scott Ullrich wrote: >> On 6/16/06, Max Laier wrote: >>> I think it should get a "device enc" on its own. Some people might >>> consider enc(4) to be a security problem so getting it with FAST_IPSEC >>> automatically isn't preferable. >> You have to specifically create the enc0 interface (ifconfig enc0 >> create) before it becomes active. Otherwise it will not hit the enc >> code path unless the device is created. > > The issue is, if an attacker manages to get root on your box they are > automatically able to read your IPSEC traffic ending at that box. If you > don't have enc(4) compiled in, that would be more difficult to do. Same > reason you don't want SADB_FLUSH on by default. *If* someone manages to get root on you IPSEC endpoint you've lost anyway. The availability of enc(4) then is no longer of importance. -- Andre From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 18:42:31 2006 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 174BD16A47B for ; Fri, 16 Jun 2006 18:42:31 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 350E243D49 for ; Fri, 16 Jun 2006 18:42:30 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 2069 invoked by uid 399); 16 Jun 2006 18:42:29 -0000 Received: from localhost (HELO ?192.168.0.6?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 16 Jun 2006 18:42:29 -0000 Message-ID: <4492FB95.9050606@FreeBSD.org> Date: Fri, 16 Jun 2006 11:42:29 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Robert Watson References: <20060611141632.Y26634@fledge.watson.org> <20060615175853.Y52950@carver.gumbysoft.com> <20060616102458.N742@fledge.watson.org> In-Reply-To: <20060616102458.N742@fledge.watson.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: MFC of socket/protocol reference improvements 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, 16 Jun 2006 18:42:31 -0000 I'm opposed to this kind of change on principle. The issue of subtle but incompatible changes to the API within a major release branch has come up before as one of the reasons that vendors find it difficult/uninteresting to support FreeBSD. With our new shorter release cycles, I think we need to draw a line in the sand and declare unambiguously that the APIs will NOT change within a release, and then live (and learn) with the consequences. If these (or any other) changes become so compelling that we feel the userbase needs to have them ASAP, I would suggest that this would be justification to move up the release cycle for 7.x, not to break faith in 6.x. Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 18:53:34 2006 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF61716A47B; Fri, 16 Jun 2006 18:53:34 +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 63CF843D45; Fri, 16 Jun 2006 18:53:34 +0000 (GMT) (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 C658646B80; Fri, 16 Jun 2006 14:53:33 -0400 (EDT) Date: Fri, 16 Jun 2006 19:53:33 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Doug Barton In-Reply-To: <4492FB95.9050606@FreeBSD.org> Message-ID: <20060616194310.M742@fledge.watson.org> References: <20060611141632.Y26634@fledge.watson.org> <20060615175853.Y52950@carver.gumbysoft.com> <20060616102458.N742@fledge.watson.org> <4492FB95.9050606@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org Subject: Re: MFC of socket/protocol reference improvements 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, 16 Jun 2006 18:53:34 -0000 On Fri, 16 Jun 2006, Doug Barton wrote: > I'm opposed to this kind of change on principle. The issue of subtle but > incompatible changes to the API within a major release branch has come up > before as one of the reasons that vendors find it difficult/uninteresting to > support FreeBSD. With our new shorter release cycles, I think we need to > draw a line in the sand and declare unambiguously that the APIs will NOT > change within a release, and then live (and learn) with the consequences. > > If these (or any other) changes become so compelling that we feel the > userbase needs to have them ASAP, I would suggest that this would be > justification to move up the release cycle for 7.x, not to break faith in > 6.x. Understand that this is a KPI -- kernel programm interface, and not an API. No applications will be affected by this change, since the sockets API and protocol management APIs for applications are untouched. In general, we don't maintain KPI compatibility in a branch except for some specific kernel interfaces, such as device driver interfaces, which are untouched by the proposed changes. In fact, the third party infiniband stack and the SCTP stack (which will be merged soon) are the first cases I know of where significant third party code bases program against this kernel interface on FreeBSD, other (historically) than early KAME development. And both the SCTP stack and KAME stack required changes to the same KPI changed by these patches, so that's really the Infiniband stack is the only one instance we know of, and is used by a vendor that already extensively modifies the kernel in ways that will be affected by even very minor changes within other parts of the kernel. So I'm not just looking for objection on principle, I'm looking for objection based on practice: do we know of third parties extending the kernel with this KPI who distribute their work and will be affected by this in ways that make it difficult for them to maintain their component? Remember that if they compile their module against the updated kernel, they will get warnings indicating the KPI changes have taken place, since the prototypes of the affected protosw entries will change. The question is really whether we want to rule out any further TCP and socket structural improvements for RELENG_6 based on kernel modules that only hypothetically exist or not. If we can show they exist, then that's another issue, but it requires organizations to have written entire protocol stacks from the ground up, which is (one presumes) relatively rare, and to a KPI that has in the past changed frequently (not the protosw interfaces, but certainly other aspects of socket behavior that are immediately relevant). Also as an FYI: this does not affect consumers of sockets in the kernel, such as distributed file systems, only implementors of protocols themselves, such as TCP/IP, AppleTalk, IPX/SPX, etc. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 19:18:39 2006 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3F9016A47C for ; Fri, 16 Jun 2006 19:18:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id D056643D46 for ; Fri, 16 Jun 2006 19:18:38 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 3004 invoked by uid 399); 16 Jun 2006 19:18:38 -0000 Received: from localhost (HELO ?192.168.0.6?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 16 Jun 2006 19:18:38 -0000 Message-ID: <4493040D.7020707@FreeBSD.org> Date: Fri, 16 Jun 2006 12:18:37 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Robert Watson References: <20060611141632.Y26634@fledge.watson.org> <20060615175853.Y52950@carver.gumbysoft.com> <20060616102458.N742@fledge.watson.org> <4492FB95.9050606@FreeBSD.org> <20060616194310.M742@fledge.watson.org> In-Reply-To: <20060616194310.M742@fledge.watson.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: MFC of socket/protocol reference improvements 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, 16 Jun 2006 19:18:39 -0000 Robert Watson wrote: > So I'm not just looking for objection on principle, I'm looking for > objection based on practice: do we know of third parties extending the > kernel with this KPI who distribute their work and will be affected by > this in ways that make it difficult for them to maintain their > component? Remember that if they compile their module against the > updated kernel, they will get warnings indicating the KPI changes have > taken place, since the prototypes of the affected protosw entries will > change. First off, it's entirely possible that my knowledge of the programming issues involved is not sufficient to make an intelligent judgment on this topic. If that's the case here, I apologize for wasting everyone's time. That said however, I reject your hypothesis that a third party developer who is depending on the status quo has to make themselves known before you're willing to reconsider changing things in RELENG_6. There are any number of reasons why this might be impossible or undesirable, not the least of which is that no one from that vendor is subscribed to -arch. On a more fundamental level, what I'm asking for is a clear bright line, and what you're saying is that it's ok for the line to be fuzzy, where some things can always be changed because they don't affect anyone we know about, other things can sometimes be changed if the pain is minimal, etc. I fully concede that from a developer standpoint, you might be right, and you're in a much better position than I to make that call. However from a business standpoint (and I am forced to where my businessman hat more than my developer hat nowadays, c'est la vie), clear bright lines are good, and fuzzy lines that depend on the (perceived) whims of people I don't know and don't have any authority over are bad. Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 19:34:50 2006 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64A2716A47A; Fri, 16 Jun 2006 19:34:50 +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 EB64F43D46; Fri, 16 Jun 2006 19:34:49 +0000 (GMT) (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 3C4BE46BBE; Fri, 16 Jun 2006 15:34:49 -0400 (EDT) Date: Fri, 16 Jun 2006 20:34:49 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Doug Barton In-Reply-To: <4493040D.7020707@FreeBSD.org> Message-ID: <20060616202844.W742@fledge.watson.org> References: <20060611141632.Y26634@fledge.watson.org> <20060615175853.Y52950@carver.gumbysoft.com> <20060616102458.N742@fledge.watson.org> <4492FB95.9050606@FreeBSD.org> <20060616194310.M742@fledge.watson.org> <4493040D.7020707@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org Subject: Re: MFC of socket/protocol reference improvements 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, 16 Jun 2006 19:34:50 -0000 On Fri, 16 Jun 2006, Doug Barton wrote: > That said however, I reject your hypothesis that a third party developer who > is depending on the status quo has to make themselves known before you're > willing to reconsider changing things in RELENG_6. There are any number of > reasons why this might be impossible or undesirable, not the least of which > is that no one from that vendor is subscribed to -arch. > > On a more fundamental level, what I'm asking for is a clear bright line, and > what you're saying is that it's ok for the line to be fuzzy, where some > things can always be changed because they don't affect anyone we know about, > other things can sometimes be changed if the pain is minimal, etc. I fully > concede that from a developer standpoint, you might be right, and you're in > a much better position than I to make that call. However from a business > standpoint (and I am forced to where my businessman hat more than my > developer hat nowadays, c'est la vie), clear bright lines are good, and > fuzzy lines that depend on the (perceived) whims of people I don't know and > don't have any authority over are bad. I'm also interested in a line, but what I'm trying to determine is where the line falls: if we have a line around the set of "supported KPIs", a line we've never really drawn very well in the past, is the protosw KPI on one side of the line, or the other? The status quot is that the line is fuzzy: in the past, we've changed related KPIs with some frequency, although I wouldn't call it wild abandon. We can't say that no interface in the kernel is ever allowed to change, or what you'd get is a release rather than a branch, with almost no movement at all in the kernel. Instead, we have to pick certain interfaces we choose to keep more static in order to support third party developers where it makes the most sense. In the past, this has almost always meant device driver vendors, although file systems and netgraph modules have generally been treated fairly well. It's made sense for two reasons: first, that it's actually possible and desirable to maintain the staticness of the KPIs, in part because we have large numbers of our own internal consumers and changing them all is apain, and in part because third parties actually have existed who ship products against them (such as video drivers, ethernet drivers, etc). But what about protosw? Do these apply? There are strong technical motivations to not support the protosw interface as a static KPI: this will allow us to continue to mature our network SMP implementation, close races, and add new features, such as SCTP (which relies on expanding the protosw KPI, which will break the ABI, FYI). The question is whether there are strong technical or organizational motivations *not* to break it, such as an awareness that this is a KPI that third party developers actually ever program to and expect to remain static. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 21:21:38 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09F0C16A484 for ; Fri, 16 Jun 2006 21:21:38 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3AA243D64 for ; Fri, 16 Jun 2006 21:21:31 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so29566uge for ; Fri, 16 Jun 2006 14:21:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QNdmAY6uaOMRV4xX9vi4O5mALyKCmc9B41W9yBR+ohUc08gDE6w9g/7EAtviHUQaBFQJ7sZ6F2x4HoHJojj5Sj7QoYYqwFM8rwmXCy9krvz5Dzvv3NWlrrGJO51eHlHKTsAWKlavev48TA9aG747PmhFjGgXD1qEG1mmpLg7Bos= Received: by 10.67.30.6 with SMTP id h6mr2859112ugj; Fri, 16 Jun 2006 08:41:27 -0700 (PDT) Received: by 10.67.28.14 with HTTP; Fri, 16 Jun 2006 08:41:27 -0700 (PDT) Message-ID: Date: Fri, 16 Jun 2006 11:41:27 -0400 From: "Scott Ullrich" To: "Max Laier" In-Reply-To: <200606161735.33801.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060615225312.GB64552@heff.fud.org.nz> <200606161735.33801.max@love2party.net> Cc: freebsd-net@freebsd.org, net@freebsd.org, Andrew Thompson , arch@freebsd.org Subject: Re: enc0 patch for ipsec 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, 16 Jun 2006 21:21:38 -0000 On 6/16/06, Max Laier wrote: > I think it should get a "device enc" on its own. Some people might consider > enc(4) to be a security problem so getting it with FAST_IPSEC automatically > isn't preferable. You have to specifically create the enc0 interface (ifconfig enc0 create) before it becomes active. Otherwise it will not hit the enc code path unless the device is created. Scott From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 21:52:25 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9B2016A47A for ; Fri, 16 Jun 2006 21:52:25 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id E887A43D45 for ; Fri, 16 Jun 2006 21:52:24 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so41412uge for ; Fri, 16 Jun 2006 14:52:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hb566xrx7XnJdRXM676wDgvgW/FAfTKW55zizv3TfbT/tLDwxDoOkNI9qW7EGtqoJO7zJtIvlwDOOFkvsuWHXLE1Pa4WhW6cKvbbk6i7D4//IpXQRhVrouMPW/k6IYHvsfffcEZ+h4+Ct7uN1wme2skGnORDen0krOkES+iREoY= Received: by 10.66.216.6 with SMTP id o6mr1636550ugg; Fri, 16 Jun 2006 09:09:03 -0700 (PDT) Received: by 10.67.28.14 with HTTP; Fri, 16 Jun 2006 09:09:03 -0700 (PDT) Message-ID: Date: Fri, 16 Jun 2006 12:09:03 -0400 From: "Scott Ullrich" To: "Max Laier" In-Reply-To: <200606161805.06651.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060615225312.GB64552@heff.fud.org.nz> <200606161735.33801.max@love2party.net> <200606161805.06651.max@love2party.net> Cc: freebsd-net@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org Subject: Re: enc0 patch for ipsec 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, 16 Jun 2006 21:52:25 -0000 On 6/16/06, Max Laier wrote: > The issue is, if an attacker manages to get root on your box they are > automatically able to read your IPSEC traffic ending at that box. If you > don't have enc(4) compiled in, that would be more difficult to do. Same > reason you don't want SADB_FLUSH on by default. Okay, this makes sense. But couldn't you also argue that if someone gets access to the machine they could also use tcpdump to do the same thing technically on the internal interface? Just playing devils advocate.. :) From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 22:22:49 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 441CA16A47C for ; Fri, 16 Jun 2006 22:22:49 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt8.ihug.co.nz (grunt8.ihug.co.nz [203.109.254.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83B8B43D53 for ; Fri, 16 Jun 2006 22:22:47 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt8.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1FrMiC-0005fj-00; Sat, 17 Jun 2006 10:22:44 +1200 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 062591CC37; Sat, 17 Jun 2006 10:22:44 +1200 (NZST) Date: Sat, 17 Jun 2006 10:22:43 +1200 From: Andrew Thompson To: Max Laier Message-ID: <20060616222243.GC64552@heff.fud.org.nz> References: <20060615225312.GB64552@heff.fud.org.nz> <200606161805.06651.max@love2party.net> <200606161814.19336.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline In-Reply-To: <200606161814.19336.max@love2party.net> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org, Scott Ullrich Subject: Re: enc0 patch for ipsec 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, 16 Jun 2006 22:22:49 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 16, 2006 at 06:14:12PM +0200, Max Laier wrote: > On Friday 16 June 2006 18:09, Scott Ullrich wrote: > > On 6/16/06, Max Laier wrote: > > > The issue is, if an attacker manages to get root on your box they are > > > automatically able to read your IPSEC traffic ending at that box. If you > > > don't have enc(4) compiled in, that would be more difficult to do. Same > > > reason you don't want SADB_FLUSH on by default. > > > > Okay, this makes sense. But couldn't you also argue that if someone > > gets access to the machine they could also use tcpdump to do the same > > thing technically on the internal interface? Just playing devils > > advocate.. :) > > Think tunnel2tunnel or an SA for a local connection, then. Given, if you are > root you *might* have other means to obtain that information, but that is why > we have a switch to turn off bpf, kmem or the like. While the encryption keys are just a setkey -D away, I can see the reason for seperating it out. I have attached another patch with the changes made. Andrew --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipsec_enc.diff" Index: share/man/man4/enc.4 =================================================================== RCS file: share/man/man4/enc.4 diff -N share/man/man4/enc.4 --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ share/man/man4/enc.4 16 Jun 2006 22:04:25 -0000 @@ -0,0 +1,82 @@ +.\" $OpenBSD: enc.4,v 1.22 2006/05/26 08:51:29 jmc Exp $ +.\" +.\" Copyright (c) 1999 Angelos D. Keromytis +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. All advertising materials mentioning features or use of this software +.\" must display the following acknowledgement: +.\" This product includes software developed by Angelos D. Keromytis. +.\" 4. The name of the author may not be used to endorse or promote products +.\" derived from this software without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd June 16, 2006 +.Dt ENC 4 +.Os +.Sh NAME +.Nm enc +.Nd Encapsulating Interface +.Sh SYNOPSIS +.Cd "device enc" +.Sh DESCRIPTION +The +.Nm +interface is a software loopback mechanism that allows hosts or +firewalls to filter +.Xr fast_ipsec 4 +traffic using any firewall package that hooks in via the +.Xr pfil 9 +framework. +.Pp +The +.Nm +interface allows an administrator +to see outgoing packets before they have been processed by +.Xr fast_ipsec 4 , +or incoming packets after they have been similarly processed, via +.Xr tcpdump 8 . +.Pp +The +.Dq enc0 +interface inherits all IPsec traffic. +Thus all IPsec traffic can be filtered based on +.Dq enc0 , +and all IPsec traffic could be seen by invoking +.Xr tcpdump 8 +on the +.Dq enc0 +interface. +.Sh EXAMPLES +To see all outgoing packets before they have been processed via +.Xr fast_ipsec 4 , +or all incoming packets after they have been similarly processed: +.Pp +.Dl # tcpdump -i enc0 +.Sh SEE ALSO +.Xr bpf 4 , +.Xr fast_ipsec 4 , +.Xr ipf 4 , +.Xr ipfw 4 , +.Xr pf 4 , +.Xr tcpdump 8 Index: share/man/man4/fast_ipsec.4 =================================================================== RCS file: /home/ncvs/src/share/man/man4/fast_ipsec.4,v retrieving revision 1.3 diff -u -p -r1.3 fast_ipsec.4 --- share/man/man4/fast_ipsec.4 21 Jan 2005 08:36:37 -0000 1.3 +++ share/man/man4/fast_ipsec.4 15 Jun 2006 22:32:58 -0000 @@ -78,10 +78,16 @@ When the protocols are configured for use, all protocols are included in the system. To selectively enable/disable protocols, use .Xr sysctl 8 . +.Pp +The packets can be passed to a virtual interface, +.Dq enc0 , +to perform packet filtering before outbound encryption and after decapsulation +inbound. .Sh DIAGNOSTICS To be added. .Sh SEE ALSO .Xr crypto 4 , +.Xr enc 4 , .Xr ipsec 4 , .Xr setkey 8 , .Xr sysctl 8 Index: sys/conf/files =================================================================== RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.1125 diff -u -p -r1.1125 files --- sys/conf/files 14 Jun 2006 03:03:08 -0000 1.1125 +++ sys/conf/files 16 Jun 2006 21:13:10 -0000 @@ -1459,6 +1459,7 @@ net/if_bridge.c optional if_bridge net/if_clone.c standard net/if_disc.c optional disc net/if_ef.c optional ef +net/if_enc.c optional enc net/if_ethersubr.c optional ether net/if_faith.c optional faith net/if_fddisubr.c optional fddi Index: sys/conf/options =================================================================== RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.546 diff -u -p -r1.546 options --- sys/conf/options 13 Jun 2006 13:12:55 -0000 1.546 +++ sys/conf/options 16 Jun 2006 21:24:28 -0000 @@ -340,6 +340,7 @@ BOOTP_NFSROOT opt_bootp.h BOOTP_NFSV3 opt_bootp.h BOOTP_WIRED_TO opt_bootp.h DEVICE_POLLING +DEV_ENC opt_enc.h DEV_PF opt_pf.h DEV_PFLOG opt_pf.h DEV_PFSYNC opt_pf.h Index: sys/net/if_enc.c =================================================================== RCS file: sys/net/if_enc.c diff -N sys/net/if_enc.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sys/net/if_enc.c 16 Jun 2006 21:15:45 -0000 @@ -0,0 +1,323 @@ +/*- + * Copyright (c) 2006 The FreeBSD Project. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include "opt_inet6.h" + +#ifdef INET6 +#include +#include +#endif + +#include + +#define ENCMTU (1024+512) +#define ENC_HDRLEN 12 + +/* XXX this define must have the same value as in OpenBSD */ +#define M_CONF 0x0400 /* payload was encrypted (ESP-transport) */ +#define M_AUTH 0x0800 /* payload was authenticated (AH or ESP auth) */ +#define M_AUTH_AH 0x2000 /* header was authenticated (AH) */ + +struct enchdr { + u_int32_t af; + u_int32_t spi; + u_int32_t flags; +}; + +struct ifnet *encif; +struct mtx enc_mtx; + +struct enc_softc { + struct ifnet *sc_ifp; +}; + +int encioctl(struct ifnet *, u_long, caddr_t); +int encoutput(struct ifnet *ifp, struct mbuf *m, + struct sockaddr *dst, struct rtentry *rt); +static int enc_clone_create(struct if_clone *, int); +static void enc_clone_destroy(struct ifnet *); + +IFC_SIMPLE_DECLARE(enc, 1); + +static void +enc_clone_destroy(struct ifnet *ifp) +{ + + KASSERT(encif == ifp, ("%s: unknown ifnet", __func__)); + + mtx_lock(&enc_mtx); + encif = NULL; + mtx_unlock(&enc_mtx); + + bpfdetach(ifp); + if_detach(ifp); + if_free(ifp); + +} + +static int +enc_clone_create(struct if_clone *ifc, int unit) +{ + struct ifnet *ifp; + struct enc_softc *sc; + + mtx_lock(&enc_mtx); + if (encif != NULL) + return (EBUSY); + mtx_unlock(&enc_mtx); + + sc = malloc(sizeof(*sc), M_DEVBUF, M_WAITOK|M_ZERO); + ifp = sc->sc_ifp = if_alloc(IFT_ENC); + if (ifp == NULL) { + free(sc, M_DEVBUF); + return (ENOSPC); + } + + if_initname(ifp, ifc->ifc_name, unit); + ifp->if_mtu = ENCMTU; + ifp->if_ioctl = encioctl; + ifp->if_output = encoutput; + ifp->if_snd.ifq_maxlen = ifqmaxlen; + ifp->if_softc = sc; + if_attach(ifp); + bpfattach(ifp, DLT_ENC, ENC_HDRLEN); + + mtx_lock(&enc_mtx); + encif = ifp; + mtx_unlock(&enc_mtx); + + return (0); +} + +static int +enc_modevent(module_t mod, int type, void *data) +{ + switch (type) { + case MOD_LOAD: + mtx_init(&enc_mtx, "enc mtx", NULL, MTX_DEF); + if_clone_attach(&enc_cloner); + break; + case MOD_UNLOAD: + printf("enc module unload - not possible for this module\n"); + return (EINVAL); + default: + return (EOPNOTSUPP); + } + return (0); +} + +static moduledata_t enc_mod = { + "enc", + enc_modevent, + 0 +}; + +DECLARE_MODULE(enc, enc_mod, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_ANY); + +int +encoutput(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, + struct rtentry *rt) +{ + m_freem(m); + return (0); +} + +/* + * Process an ioctl request. + */ +/* ARGSUSED */ +int +encioctl(struct ifnet *ifp, u_long cmd, caddr_t data) +{ + int error = 0; + + switch (cmd) { + + case SIOCSIFFLAGS: + if (ifp->if_flags & IFF_UP) + ifp->if_drv_flags |= IFF_DRV_RUNNING; + else + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; + + break; + + default: + error = EINVAL; + } + return (error); +} + +int +ipsec_filter(struct mbuf **mp, int dir) +{ + int error, i; + struct ip *ip; + + mtx_lock(&enc_mtx); + if (encif == NULL || (encif->if_drv_flags & IFF_DRV_RUNNING) == 0) { + mtx_unlock(&enc_mtx); + return (0); + } + + /* Skip pfil(9) if no filters are loaded */ + if (inet_pfil_hook.ph_busy_count < 0 +#ifdef INET6 + && inet6_pfil_hook.ph_busy_count < 0 +#endif + ) { + mtx_unlock(&enc_mtx); + return (0); + } + + i = min((*mp)->m_pkthdr.len, max_protohdr); + if ((*mp)->m_len < i) { + *mp = m_pullup(*mp, i); + if (*mp == NULL) { + printf("%s: m_pullup failed\n", __func__); + mtx_unlock(&enc_mtx); + return (-1); + } + } + + error = 0; + ip = mtod(*mp, struct ip *); + switch (ip->ip_v) { + case 4: + /* + * before calling the firewall, swap fields the same as + * IP does. here we assume the header is contiguous + */ + ip->ip_len = ntohs(ip->ip_len); + ip->ip_off = ntohs(ip->ip_off); + + error = pfil_run_hooks(&inet_pfil_hook, mp, + encif, dir, NULL); + + if (*mp == NULL || error != 0) + break; + + /* restore byte ordering */ + ip = mtod(*mp, struct ip *); + ip->ip_len = htons(ip->ip_len); + ip->ip_off = htons(ip->ip_off); + break; + +#ifdef INET6 + case 6: + error = pfil_run_hooks(&inet6_pfil_hook, mp, + encif, dir, NULL); + break; +#endif + default: + printf("%s: unknown IP version\n", __func__); + } + + mtx_unlock(&enc_mtx); + if (*mp == NULL) + return (error); + if (error != 0) + goto bad; + + return (error); + +bad: + mtx_unlock(&enc_mtx); + m_freem(*mp); + *mp = NULL; + return (error); +} + +void +ipsec_bpf(struct mbuf *m, struct secasvar *sav, int af) +{ + int flags; + struct enchdr hdr; + struct mbuf m1; + + KASSERT(sav != NULL, ("%s: sav is null", __func__)); + + mtx_lock(&enc_mtx); + if (encif == NULL || (encif->if_drv_flags & IFF_DRV_RUNNING) == 0) { + mtx_unlock(&enc_mtx); + return; + } + + if (encif->if_bpf) { + flags = 0; + if (sav->alg_enc != SADB_EALG_NONE) + flags |= M_CONF; + if (sav->alg_auth != SADB_AALG_NONE) + flags |= M_AUTH; + + /* + * We need to prepend the address family as a four byte + * field. Cons up a dummy header to pacify bpf. This + * is safe because bpf will only read from the mbuf + * (i.e., it won't try to free it or keep a pointer a + * to it). + */ + hdr.af = af; + hdr.spi = sav->spi; + hdr.flags = flags; + + m1.m_flags = 0; + m1.m_next = m; + m1.m_len = ENC_HDRLEN; + m1.m_data = (char *) &hdr; + + bpf_mtap(encif->if_bpf, &m1); + } + mtx_unlock(&enc_mtx); +} Index: sys/net/if_types.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_types.h,v retrieving revision 1.21 diff -u -p -r1.21 if_types.h --- sys/net/if_types.h 10 Jun 2005 16:49:19 -0000 1.21 +++ sys/net/if_types.h 15 Jun 2006 21:38:18 -0000 @@ -246,6 +246,7 @@ #define IFT_GIF 0xf0 #define IFT_PVC 0xf1 #define IFT_FAITH 0xf2 +#define IFT_ENC 0xf4 #define IFT_PFLOG 0xf6 #define IFT_PFSYNC 0xf7 #define IFT_CARP 0xf8 /* Common Address Redundancy Protocol */ Index: sys/netipsec/ipsec.h =================================================================== RCS file: /home/ncvs/src/sys/netipsec/ipsec.h,v retrieving revision 1.11 diff -u -p -r1.11 ipsec.h --- sys/netipsec/ipsec.h 10 Apr 2006 15:04:36 -0000 1.11 +++ sys/netipsec/ipsec.h 16 Jun 2006 21:21:57 -0000 @@ -417,6 +417,8 @@ extern void m_checkalignment(const char* extern struct mbuf *m_makespace(struct mbuf *m0, int skip, int hlen, int *off); extern caddr_t m_pad(struct mbuf *m, int n); extern int m_striphdr(struct mbuf *m, int skip, int hlen); +extern int ipsec_filter(struct mbuf **, int); +extern void ipsec_bpf(struct mbuf *, struct secasvar *, int); #endif /* _KERNEL */ #ifndef _KERNEL Index: sys/netipsec/ipsec_input.c =================================================================== RCS file: /home/ncvs/src/sys/netipsec/ipsec_input.c,v retrieving revision 1.11 diff -u -p -r1.11 ipsec_input.c --- sys/netipsec/ipsec_input.c 4 Jun 2006 19:32:32 -0000 1.11 +++ sys/netipsec/ipsec_input.c 16 Jun 2006 21:21:19 -0000 @@ -43,6 +43,7 @@ #include "opt_inet.h" #include "opt_inet6.h" #include "opt_ipsec.h" +#include "opt_enc.h" #include #include @@ -442,6 +443,18 @@ ipsec4_common_input_cb(struct mbuf *m, s key_sa_recordxfer(sav, m); /* record data transfer */ +#ifdef DEV_ENC + /* + * Pass the mbuf to enc0 for bpf and pfil. We will filter the IPIP + * packet later after it has been decapsulated. + */ + ipsec_bpf(m, sav, AF_INET); + + if (prot != IPPROTO_IPIP) + if ((error = ipsec_filter(&m, 1)) != 0) + return (error); +#endif + /* * Re-dispatch via software interrupt. */ Index: sys/netipsec/ipsec_output.c =================================================================== RCS file: /home/ncvs/src/sys/netipsec/ipsec_output.c,v retrieving revision 1.11 diff -u -p -r1.11 ipsec_output.c --- sys/netipsec/ipsec_output.c 2 Nov 2005 13:46:32 -0000 1.11 +++ sys/netipsec/ipsec_output.c 16 Jun 2006 21:21:33 -0000 @@ -32,6 +32,7 @@ #include "opt_inet.h" #include "opt_inet6.h" #include "opt_ipsec.h" +#include "opt_enc.h" #include #include @@ -358,6 +359,13 @@ ipsec4_process_packet( goto bad; sav = isr->sav; + +#ifdef DEV_ENC + /* pass the mbuf to enc0 for packet filtering */ + if ((error = ipsec_filter(&m, 2)) != 0) + goto bad; +#endif + if (!tunalready) { union sockaddr_union *dst = &sav->sah->saidx.dst; int setdf; @@ -455,6 +463,11 @@ ipsec4_process_packet( } } +#ifdef DEV_ENC + /* pass the mbuf to enc0 for bpf processing */ + ipsec_bpf(m, sav, AF_INET); +#endif + /* * Dispatch to the appropriate IPsec transform logic. The * packet will be returned for transmission after crypto Index: sys/netipsec/xform_ipip.c =================================================================== RCS file: /home/ncvs/src/sys/netipsec/xform_ipip.c,v retrieving revision 1.12 diff -u -p -r1.12 xform_ipip.c --- sys/netipsec/xform_ipip.c 30 Mar 2006 18:57:04 -0000 1.12 +++ sys/netipsec/xform_ipip.c 16 Jun 2006 21:21:02 -0000 @@ -41,6 +41,7 @@ */ #include "opt_inet.h" #include "opt_inet6.h" +#include "opt_enc.h" #include #include @@ -345,6 +346,12 @@ _ipip_input(struct mbuf *m, int iphlen, /* Statistics */ ipipstat.ipips_ibytes += m->m_pkthdr.len - iphlen; +#ifdef DEV_ENC + /* pass the mbuf to enc0 for packet filtering */ + if (ipsec_filter(&m, 1) != 0) + return; +#endif + /* * Interface pointer stays the same; if no IPsec processing has * been done (or will be done), this will point to a normal --H+4ONPRPur6+Ovig-- From owner-freebsd-arch@FreeBSD.ORG Sat Jun 17 06:57:59 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43DBC16A479; Sat, 17 Jun 2006 06:57:59 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4B3743D46; Sat, 17 Jun 2006 06:57:58 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5H6vQPZ039131; Fri, 16 Jun 2006 23:57:26 -0700 (PDT) Date: Sat, 17 Jun 2006 13:02:31 +0900 Message-ID: From: gnn@freebsd.org To: Robert Watson In-Reply-To: <20060616202844.W742@fledge.watson.org> References: <20060611141632.Y26634@fledge.watson.org> <20060615175853.Y52950@carver.gumbysoft.com> <20060616102458.N742@fledge.watson.org> <4492FB95.9050606@FreeBSD.org> <20060616194310.M742@fledge.watson.org> <4493040D.7020707@FreeBSD.org> <20060616202844.W742@fledge.watson.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.5.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: arch@freebsd.org, Doug Barton Subject: Re: MFC of socket/protocol reference improvements 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: Sat, 17 Jun 2006 06:57:59 -0000 At Fri, 16 Jun 2006 20:34:49 +0100 (BST), rwatson wrote: > I'm also interested in a line, but what I'm trying to determine is > where the line falls: if we have a line around the set of "supported > KPIs", a line we've never really drawn very well in the past, is the > protosw KPI on one side of the line, or the other? The status quot > is that the line is fuzzy: in the past, we've changed related KPIs > with some frequency, although I wouldn't call it wild abandon. We > can't say that no interface in the kernel is ever allowed to change, > or what you'd get is a release rather than a branch, with almost no > movement at all in the kernel. Instead, we have to pick certain > interfaces we choose to keep more static in order to support third > party developers where it makes the most sense. > > In the past, this has almost always meant device driver vendors, > although file systems and netgraph modules have generally been > treated fairly well. It's made sense for two reasons: first, that > it's actually possible and desirable to maintain the staticness of > the KPIs, in part because we have large numbers of our own internal > consumers and changing them all is apain, and in part because third > parties actually have existed who ship products against them (such > as video drivers, ethernet drivers, etc). But what about protosw? > Do these apply? > > There are strong technical motivations to not support the protosw > interface as a static KPI: this will allow us to continue to mature > our network SMP implementation, close races, and add new features, > such as SCTP (which relies on expanding the protosw KPI, which will > break the ABI, FYI). The question is whether there are strong > technical or organizational motivations *not* to break it, such as > an awareness that this is a KPI that third party developers actually > ever program to and expect to remain static. My thoughts on these changes are that, unlike device drivers, there aren't hundreds of protocols that would be effected by a change in the protosw. Certainly there are more than existed in the past, but it is very likely less than 10. I think we need to also consider the fact that these changes, which a lot of us are using/testing in HEAD, do improve the performance and stability of the protocol used most often in FreeBSD, that is TCP. I think that for those two reasons we should do this but ONLY at the end of the current release cycle so as to give people on 6 the maximum amount of time to deal with this issue. Best, George From owner-freebsd-arch@FreeBSD.ORG Sat Jun 17 06:58:38 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6803316A47B; Sat, 17 Jun 2006 06:58:38 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC45C43D49; Sat, 17 Jun 2006 06:58:37 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout3.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5H6vRJw011536; Fri, 16 Jun 2006 23:57:28 -0700 (PDT) Date: Sat, 17 Jun 2006 13:07:10 +0900 Message-ID: From: gnn@freebsd.org To: Andrew Thompson In-Reply-To: <20060616222243.GC64552@heff.fud.org.nz> References: <20060615225312.GB64552@heff.fud.org.nz> <200606161805.06651.max@love2party.net> <200606161814.19336.max@love2party.net> <20060616222243.GC64552@heff.fud.org.nz> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.5.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Max Laier , Scott Ullrich , freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: enc0 patch for ipsec 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: Sat, 17 Jun 2006 06:58:38 -0000 I knew there was something bothering me about enc, now I know what it was. I'm glad someone else caught this and that you fixed it. Thanks. I'll be testing the patch today. Later, George From owner-freebsd-arch@FreeBSD.ORG Sat Jun 17 22:28:35 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45FD516A47A for ; Sat, 17 Jun 2006 22:28:35 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9366143D45 for ; Sat, 17 Jun 2006 22:28:34 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so376709uge for ; Sat, 17 Jun 2006 15:28:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=P1Ya1AeiSPcUdky4eoAhLh8eMbAu4Kr81rOhk64uzqAUISHK3RdgyHC5KRcwT8TnjaMA2TC/Ug4pRwa9vNvtkD0qf4P4+fBmWMrie16fKeRWGFAgeeNJdz3KCMlubIOBjE4Y57jxAhk06dqyKXJGJA57NzZ3OtT/Vm8fXxZf2q0= Received: by 10.67.106.3 with SMTP id i3mr2882344ugm; Fri, 16 Jun 2006 09:15:33 -0700 (PDT) Received: by 10.67.28.14 with HTTP; Fri, 16 Jun 2006 09:15:32 -0700 (PDT) Message-ID: Date: Fri, 16 Jun 2006 12:15:32 -0400 From: "Scott Ullrich" To: "Max Laier" In-Reply-To: <200606161814.19336.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060615225312.GB64552@heff.fud.org.nz> <200606161805.06651.max@love2party.net> <200606161814.19336.max@love2party.net> Cc: freebsd-net@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org Subject: Re: enc0 patch for ipsec 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: Sat, 17 Jun 2006 22:28:35 -0000 On 6/16/06, Max Laier wrote: > Think tunnel2tunnel or an SA for a local connection, then. Given, if you are > root you *might* have other means to obtain that information, but that is why > we have a switch to turn off bpf, kmem or the like. Gotcha. Thanks for clarifying :) Scott