From owner-freebsd-arch@FreeBSD.ORG Sun Sep 10 15:18:47 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 E93C016A40F for ; Sun, 10 Sep 2006 15:18:47 +0000 (UTC) (envelope-from davidt@yadt.co.uk) Received: from outcold.yadt.co.uk (outcold.yadt.co.uk [81.187.204.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6724743D45 for ; Sun, 10 Sep 2006 15:18:47 +0000 (GMT) (envelope-from davidt@yadt.co.uk) Received: from localhost (localhost [127.0.0.1]) by outcold.yadt.co.uk (Postfix) with ESMTP id AC7381DD4C8 for ; Sun, 10 Sep 2006 16:18:45 +0100 (BST) X-Virus-Scanned: amavisd-new 2.4.0 (20060403) at yadt.co.uk Received: from outcold.yadt.co.uk ([127.0.0.1]) by localhost (outcold.yadt.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce4vcAVx0K3e for ; Sun, 10 Sep 2006 16:18:45 +0100 (BST) Received: by outcold.yadt.co.uk (Postfix, from userid 1001) id 6CD241DD4CB; Sun, 10 Sep 2006 16:18:45 +0100 (BST) Date: Sun, 10 Sep 2006 16:18:45 +0100 From: David Taylor To: arch@freebsd.org Message-ID: <20060910151845.GA79571@outcold.yadt.co.uk> Mail-Followup-To: arch@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Modularize kernel 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, 10 Sep 2006 15:18:48 -0000 On Fri, 08 Sep 2006, Howard Su wrote: > On 9/7/06, gnn@freebsd.org wrote: > >At Thu, 7 Sep 2006 13:47:46 +0800, > >Hello Howard, > > > >The monolithic vs. modularized kernel is an old discussion. If you're > >really interested in pursuing this you'll have a lot of work to do, > >mostly in figuring out explicitly all the implicit inter-module > >dependencies. Fascinating and fun, but you likely need a good reason > >to do it. > I listed the advantages I can think about. Can they convince you? They may convince people it is a good idea in principle. But until someone actually comes up with a solid plan showing how it can realistically be done in practice, nothing will happen. -- David Taylor From owner-freebsd-arch@FreeBSD.ORG Mon Sep 11 16:40:59 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 2084E16A407 for ; Mon, 11 Sep 2006 16:40:59 +0000 (UTC) (envelope-from ilee@juniper.net) Received: from kremlin.juniper.net (kremlin.juniper.net [207.17.137.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id C56EE43D45 for ; Mon, 11 Sep 2006 16:40:58 +0000 (GMT) (envelope-from ilee@juniper.net) Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by kremlin.juniper.net with ESMTP; 11 Sep 2006 09:38:57 -0700 X-IronPort-AV: i="4.09,146,1157353200"; d="scan'208,217"; a="581370251:sNHT71823424" Received: from electron.jnpr.net ([172.24.15.21]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 09:40:58 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Sep 2006 09:40:57 -0700 Message-ID: <5EB31780BD297F46812C8F495FA08F620749613D@electron.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCTP in FreeBSD 5.x/current Thread-Index: AcbVwQ4YJsq01YTeRjGhEKdD/7v5qg== From: "Ivan Lee" To: X-OriginalArrivalTime: 11 Sep 2006 16:40:58.0266 (UTC) FILETIME=[0EF01FA0:01C6D5C1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: SCTP in FreeBSD 5.x/current 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, 11 Sep 2006 16:40:59 -0000 Hi Andre, =20 I just happened to bump into one of your "old" e-mail you posted in 2004 on porting of SCTP onto FreeBSD 5.x, the URL of which is:=20 http://lists.freebsd.org/pipermail/freebsd-arch/2004-October/003068.html =20 I was wondering if the porting of SCTP to FreeBSD 5.x has been complete. If it is, could please inform me which version of FreeBSD 5.X now supports SCTP, and where I could download it, such that I could test it in a PC environment prior to adding my application on top? Thank you in advance for your help. =20 Regards, =20 Ivan From owner-freebsd-arch@FreeBSD.ORG Mon Sep 11 17:01:30 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 6841416A412 for ; Mon, 11 Sep 2006 17:01:30 +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 BEF8D43D45 for ; Mon, 11 Sep 2006 17:01:29 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.183.32] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1GMpA01J3S-0003qV; Mon, 11 Sep 2006 19:01:28 +0200 From: Max Laier Organization: FreeBSD To: freebsd-arch@freebsd.org Date: Mon, 11 Sep 2006 19:01:09 +0200 User-Agent: KMail/1.9.3 References: <5EB31780BD297F46812C8F495FA08F620749613D@electron.jnpr.net> In-Reply-To: <5EB31780BD297F46812C8F495FA08F620749613D@electron.jnpr.net> 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="nextPart1549254.TTDOpEYsBM"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200609111901.27540.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Ivan Lee Subject: Re: SCTP in FreeBSD 5.x/current 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, 11 Sep 2006 17:01:30 -0000 --nextPart1549254.TTDOpEYsBM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 11 September 2006 18:40, Ivan Lee wrote: > I just happened to bump into one of your "old" e-mail you posted in > 2004 on porting of SCTP onto FreeBSD 5.x, the URL of which is: > > http://lists.freebsd.org/pipermail/freebsd-arch/2004-October/003068.htm >l > > I was wondering if the porting of SCTP to FreeBSD 5.x has been > complete. If it is, could please inform me which version of FreeBSD 5.X > now supports SCTP, and where I could download it, such that I could > test it in a PC environment prior to adding my application on top? > Thank you in advance for your help. See http://www.sctp.org/ 's download section. =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 --nextPart1549254.TTDOpEYsBM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFBZZnXyyEoT62BG0RAljYAJ0UPlL6WqUqYQaijSANooLy7u3leQCfQGYo TjRcxM66lsK/hDPi1Qvaj+o= =RSqg -----END PGP SIGNATURE----- --nextPart1549254.TTDOpEYsBM-- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 11 17:20:57 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 485C716A416 for ; Mon, 11 Sep 2006 17:20:57 +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 8BE0543D73 for ; Mon, 11 Sep 2006 17:20:56 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 4294 invoked from network); 11 Sep 2006 17:05:00 -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 ; 11 Sep 2006 17:05:00 -0000 Message-ID: <45059AF8.9080102@freebsd.org> Date: Mon, 11 Sep 2006 19:20:56 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Ivan Lee References: <5EB31780BD297F46812C8F495FA08F620749613D@electron.jnpr.net> In-Reply-To: <5EB31780BD297F46812C8F495FA08F620749613D@electron.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: SCTP in FreeBSD 5.x/current 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, 11 Sep 2006 17:20:57 -0000 Ivan Lee wrote: > Hi Andre, > > I just happened to bump into one of your "old" e-mail you posted in 2004 > on porting of SCTP onto FreeBSD 5.x, the URL of which is: > > http://lists.freebsd.org/pipermail/freebsd-arch/2004-October/003068.html > > I was wondering if the porting of SCTP to FreeBSD 5.x has been complete. > If it is, could please inform me which version of FreeBSD 5.X now > supports SCTP, and where I could download it, such that I could test it > in a PC environment prior to adding my application on top? Thank you in > advance for your help. SCTP will be integrated into FreeBSD 7-current in the next few weeks. After that and some stabilization period it will most likely be backported to FreeBSD 6-stable to show up with FreeBSD 6.3 Release next year. It is not planned to backport it to FreeBSD 5 as FreeBSD 6 is our maintained stable for-production-use series. You can find updated SCTP patches relative to FreeBSD 7-current on http://www.sctp.org. -- Andre From owner-freebsd-arch@FreeBSD.ORG Tue Sep 12 11:43:17 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 01DE616A40F; Tue, 12 Sep 2006 11:43:17 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id F119143D6B; Tue, 12 Sep 2006 11:43:15 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k8CBhDQ8009486; Tue, 12 Sep 2006 15:43:13 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k8CBhDEi009485; Tue, 12 Sep 2006 15:43:13 +0400 (MSD) (envelope-from yar) Date: Tue, 12 Sep 2006 15:43:13 +0400 From: Yar Tikhiy To: Andre Oppermann Message-ID: <20060912114312.GE8639@comp.chem.msu.su> References: <450035AD.3040600@freebsd.org> <20060908010835.GA6334@heff.fud.org.nz> <45012EAA.4010303@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45012EAA.4010303@freebsd.org> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org Subject: Re: Moving ethernet VLAN tags into the mbuf packet header (from mtags) 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, 12 Sep 2006 11:43:17 -0000 On Fri, Sep 08, 2006 at 10:49:46AM +0200, Andre Oppermann wrote: > Andrew Thompson wrote: > >On Thu, Sep 07, 2006 at 05:07:25PM +0200, Andre Oppermann wrote: > >>With the recent addition of a 16bit field for TSO into the mbuf packet > >>header we've got 16bits left over. I've reserved these bits for the > >>ethernet VLAN tagging of packet to do away with the allocated mbuf mtag. > >> > >>The change is rather mechanical. Patch available here: > >> > >> http://people.freebsd.org/~andre/vlan_pkthdr-20060907.diff > >> > > > >RCS file: /home/ncvs/src/sys/netgraph/ng_vlan.c,v > >retrieving revision 1.3 > >diff -u -p -r1.3 ng_vlan.c > >--- netgraph/ng_vlan.c 20 Apr 2005 14:19:20 -0000 1.3 > >+++ netgraph/ng_vlan.c 7 Sep 2006 15:03:58 -0000 > > > ><...> > > > >- vlan = EVL_VLANOFTAG(VLAN_TAG_VALUE(mtag)); > >+ vlan = m->m_pkthdr.ether_vlan; > > (void)&evl; /* XXX silence GCC */ > > > >I think this is a typeo, EVL_VLANOFTAG is still needed. I like the > >change and it helps out a few related projects that people are working > >on. > > Fixed. Thanks for the review! It seems to me that the typo just highlighted not-so-optimal naming of the new field. We must distinguish between VLAN ID's and VLAN tags clearly. A VLAN ID is what can be passed to "ifconfig foo0 vlan ___". A VLAN tag is a 16-bit value ready to be stored in the respective field of the 802.1Q header, except for its byte order. I'd rather have the new field renamed to just "vlan_tag" to avoid further confusion. In long perspective, however, stuffing protocol-specific fields in the generic mbuf header is no good. I share Julian's point here. We already can allocate simple mbufs as well as mbufs with m_pkthdr. This scheme is begging to be generalised. Then we should be able to allocate mbufs crafted for a particular protcol at once. Now I can't but do some nitpicking :-) In if_vlan.c, the "inenc" variable is set to 0 or 1 depending on the branch taken in the if-else clause. Then why to initialize it at its definition? I think that the better style would be: int inenc; if (m->m_flags & M_VLAN) { ... inenc = 0; } else { ... inenc = 1; } AFAIK, C compilers are clever enough to avoid false "uninitialized variable" warning for the code. Lastly, I've just noticed that the M_VLAN flag isn't documented in mbuf(9) yet. Could you document it along with the results of your work when it's finished? ;-) -- Yar From owner-freebsd-arch@FreeBSD.ORG Tue Sep 12 12:56: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 25CF916A54D for ; Tue, 12 Sep 2006 12:56:23 +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 330AF43D78 for ; Tue, 12 Sep 2006 12:56:12 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 11854 invoked from network); 12 Sep 2006 12:40:07 -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 ; 12 Sep 2006 12:40:07 -0000 Message-ID: <4506AE6D.1010300@freebsd.org> Date: Tue, 12 Sep 2006 14:56:13 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Yar Tikhiy References: <450035AD.3040600@freebsd.org> <20060908010835.GA6334@heff.fud.org.nz> <45012EAA.4010303@freebsd.org> <20060912114312.GE8639@comp.chem.msu.su> In-Reply-To: <20060912114312.GE8639@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Andrew Thompson , freebsd-arch@freebsd.org Subject: Re: Moving ethernet VLAN tags into the mbuf packet header (from mtags) 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, 12 Sep 2006 12:56:23 -0000 Yar Tikhiy wrote: > On Fri, Sep 08, 2006 at 10:49:46AM +0200, Andre Oppermann wrote: >> Andrew Thompson wrote: >>> On Thu, Sep 07, 2006 at 05:07:25PM +0200, Andre Oppermann wrote: >>>> With the recent addition of a 16bit field for TSO into the mbuf packet >>>> header we've got 16bits left over. I've reserved these bits for the >>>> ethernet VLAN tagging of packet to do away with the allocated mbuf mtag. >>>> >>>> The change is rather mechanical. Patch available here: >>>> >>>> http://people.freebsd.org/~andre/vlan_pkthdr-20060907.diff >>>> >>> RCS file: /home/ncvs/src/sys/netgraph/ng_vlan.c,v >>> retrieving revision 1.3 >>> diff -u -p -r1.3 ng_vlan.c >>> --- netgraph/ng_vlan.c 20 Apr 2005 14:19:20 -0000 1.3 >>> +++ netgraph/ng_vlan.c 7 Sep 2006 15:03:58 -0000 >>> >>> <...> >>> >>> - vlan = EVL_VLANOFTAG(VLAN_TAG_VALUE(mtag)); >>> + vlan = m->m_pkthdr.ether_vlan; >>> (void)&evl; /* XXX silence GCC */ >>> >>> I think this is a typeo, EVL_VLANOFTAG is still needed. I like the >>> change and it helps out a few related projects that people are working >>> on. >> Fixed. Thanks for the review! > > It seems to me that the typo just highlighted not-so-optimal naming > of the new field. We must distinguish between VLAN ID's and VLAN > tags clearly. A VLAN ID is what can be passed to "ifconfig foo0 > vlan ___". A VLAN tag is a 16-bit value ready to be stored in the > respective field of the 802.1Q header, except for its byte order. > I'd rather have the new field renamed to just "vlan_tag" to avoid > further confusion. I'd like to keep the ether_ prefix to make it clear who this pkthdr field belongs to. What do you think of pkthdr.ether_vtag? Is that more descriptive for this purpose to avoid the confusion you are referring to? > In long perspective, however, stuffing protocol-specific fields in > the generic mbuf header is no good. I share Julian's point here. > We already can allocate simple mbufs as well as mbufs with m_pkthdr. > This scheme is begging to be generalised. Then we should be able > to allocate mbufs crafted for a particular protcol at once. What you describe here is not an approach currently done by the BSD mbuf system (that is having protocol specific mbuf headers). The current way of doing these things is to attach mtags to the mbufs as it is currently done with ethernet vlans. The trouble here is the additional overhead for allocating the mtags and the potential cache busting of following an mtag chain. Actually I agree that having protocol specific fields in the mbuf pkthdr is not clean design. But on the other hand it's always a tradeoff between clean design, performance and ugliness. Mach has a very clean design but simply doesn't perform. We have to find a balance without getting into ugly because then the tradeoff gets negative and causes lots of pain and complicated maintenance in the future. > Now I can't but do some nitpicking :-) In if_vlan.c, the "inenc" > variable is set to 0 or 1 depending on the branch taken in the > if-else clause. Then why to initialize it at its definition? I > think that the better style would be: > > int inenc; > > if (m->m_flags & M_VLAN) { > ... > inenc = 0; > } else { > ... > inenc = 1; > } > > AFAIK, C compilers are clever enough to avoid false "uninitialized > variable" warning for the code. Good point. This can certainly be improved. For the first patch I tried to be as mechanical as I could be. > Lastly, I've just noticed that the M_VLAN flag isn't documented in > mbuf(9) yet. Could you document it along with the results of your > work when it's finished? ;-) Sure. Thanks for your comments. -- Andre From owner-freebsd-arch@FreeBSD.ORG Tue Sep 12 16:42:34 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 A9ACD16A416; Tue, 12 Sep 2006 16:42:34 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61C2F43D45; Tue, 12 Sep 2006 16:42:34 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout13/MantshX 4.0) with ESMTP id k8CGgXfh028777; Tue, 12 Sep 2006 09:42:33 -0700 (PDT) Received: from [17.214.13.96] (a17-214-13-96.apple.com [17.214.13.96]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id k8CGgUA6005920; Tue, 12 Sep 2006 09:42:32 -0700 (PDT) In-Reply-To: <4506AE6D.1010300@freebsd.org> References: <450035AD.3040600@freebsd.org> <20060908010835.GA6334@heff.fud.org.nz> <45012EAA.4010303@freebsd.org> <20060912114312.GE8639@comp.chem.msu.su> <4506AE6D.1010300@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2EDD6C39-62ED-4DE1-B5BF-368E8E701B2E@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Tue, 12 Sep 2006 09:42:30 -0700 To: Andre Oppermann X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAQAAA+k= X-Language-Identified: TRUE Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Moving ethernet VLAN tags into the mbuf packet header (from mtags) 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, 12 Sep 2006 16:42:34 -0000 On Sep 12, 2006, at 5:56 AM, Andre Oppermann wrote: >> Now I can't but do some nitpicking :-) In if_vlan.c, the "inenc" >> variable is set to 0 or 1 depending on the branch taken in the >> if-else clause. Then why to initialize it at its definition? I >> think that the better style would be: >> int inenc; >> if (m->m_flags & M_VLAN) { >> ... >> inenc = 0; >> } else { >> ... >> inenc = 1; >> } >> AFAIK, C compilers are clever enough to avoid false "uninitialized >> variable" warning for the code. > > Good point. This can certainly be improved. For the first patch > I tried to be as mechanical as I could be. So long as there does not exist another code path (via break, continue, goto, etc) which can avoid passing one statement or the other-- and so long as nobody later on adds code which changes the underlying assumption. In terms of efficiency, zero'ing a bunch of automatic variables which get put on the stack during function entry is usually cheaper to do than doing conditional initialization later on in the code. It depends on the underlying CPU architecture, but many have an instruction which can perform a bzero() or memset() rapidly. -- -Chuck From owner-freebsd-arch@FreeBSD.ORG Wed Sep 13 14:29:19 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 15B7F16A407; Wed, 13 Sep 2006 14:29:19 +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 D7B1F43D5E; Wed, 13 Sep 2006 14:29:14 +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 12BA846CBD; Wed, 13 Sep 2006 10:29:14 -0400 (EDT) Date: Wed, 13 Sep 2006 15:29:14 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Message-ID: <20060913150912.J1823@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: trustedbsd-discuss@TrustedBSD.org Subject: New in-kernel privilege API: priv(9) 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: Wed, 13 Sep 2006 14:29:19 -0000 Dear all, Over the past few weeks, I've been working on a replacement for the suser(9) API, used to check whether a thread or credential has the privilege to override discretionary access control or perform system configuration operations in the kernel. Currently, these checks use one of two kernel APIs: suser(thread) or: suser_cred(cred, flags) The former is the more common invocation, but the latter is also often used; this is largely because jail(4) requires limits of superuser privilege, so instances of privilege allowed in jail are explicitly marked via the flags field. There are also circumstances in which only a credential is available, perhaps cached from another context, and a very small number of instances (2) where a second flag, forcing use of the ruid instead of the euid, is used. The above API has served FreeBSD well for many years. However, it suffers from a number of architectural and functionality inadequacies. The goal of my work has been to address a particular functional lack: granularity. In particular, there are a number of things that finer granularity in the API would allow us to do: - Make it easier to explore the finer-grained granting of privilege via policy, such as assigning specific useful privileges -- the ability to bind a port, configure a SLIP interface, adjust the time, be exempt from audit requirements, be allowed to attach to a jail, override certain file permissions, set quotas, configure IP addresses, etc, which are cleanly separable (not to mention usefully assignable) privileges. - Make it easier to explore the finer-grained denial of privilege. For example, jail is in large part based on a marking of different privilege checking points as being "allowed in jail" or "not allowed in jail". In some ways this is advantageous: the implementer of each suser check gets to decide whether it's in jail, and that information is available in the context of the check. However, this has several important disadvantages. Not least is that the implementation of jail is highly distributed rather than centralized, making auditing the implementation difficult. Another disadvantage is that configuration options that vary the behavior of jail are also distributed throughout the kernel rather than centralized, as they must vary whether the SUSER_ALLOWJAIL flag is being passed into suser. It would be nice to be able to quickly and easily answer the question "what privileges are granted in jail", and to easily vary the list, which is not possible currently. - Make it easier to identify, categorize, and audit the use of privilege throughout the kernel by actually having a list of the privileges and what they correspond to, as well as making it easier to identify all the places a specific privilege is used. This facilitates auditing of kernel privilege use, and easy comparison of the use of identical privileges in different subsystems. For example, while doing this work, I identified inconsistencies in the application of superuser privilege in different file systems, privileges that were sometimes allowed in jail, but sometimes not, etc. 200 anonymous suser checks are hard to analyze, 160 named privilege checks are much easier to analyze. - Make it easier to modify the audit mechanism to capture a log of exactly what privileges are exercised during operation, a requirement for higher assurance evaluation. What does this all mean in practice? It means replacing suser(9) and suser_cred(9) with calls that express the specific privilege being checked for. I took the most straight forward possible implementation: I reviewed all privilege checks in the kernel, identified all identical privileges and categorized all privileges by subsystem. I then assigned unique numeric constants to each unique privilege, and added a privilege identifier argument to the two new functions, priv_check(9) and priv_check_cred(9). Here are a few sample snippet from the privilege list in src/sys/priv.h: ... PRIV_ACCT, /* Manage process accounting. */ PRIV_MAXFILES, /* Exceed system open files limit. */ PRIV_MAXPROC, /* Exceed system processes limit. */ PRIV_KTRACE, /* Set/accept KTRFAC_ROOT on ktrace. */ PRIV_SETDUMPER, /* Configure dump device (XXX: needs work). */ PRIV_NFSD, /* Can become NFS daemon. */ PRIV_REBOOT, /* Can reboot system. */ PRIV_SWAPON, /* Can swapon(). */ PRIV_SWAPOFF, /* Can swapoff(). */ ... PRIV_PMC_MANAGE, /* Can administer PMC. */ PRIV_PMC_SYSTEM, /* Can allocate a system-wide PMC. */ PRIV_SCHED_DIFFCRED, /* Exempt scheduling other users. */ PRIV_SCHED_SETPRIORITY, /* Can set lower nice value for proc. */ PRIV_SCHED_RTPRIO, /* Can set real time scheduling. */ PRIV_SCHED_SETPOLICY, /* Can set scheduler policy. */ PRIV_SCHED_SET, /* Can set thread scheduler. */ PRIV_SCHED_SETPARAM, /* Can set thread scheduler params. */ ... PRIV_UFS_SETQUOTA, /* setquota(). */ PRIV_UFS_SETUSE, /* setuse(). */ PRIV_UFS_EXCEEDQUOTA, /* Exempt from quota restrictions. */ PRIV_VFS_READ, /* Override vnode DAC read perm. */ PRIV_VFS_WRITE, /* Override vnode DAC write perm. */ PRIV_VFS_ADMIN, /* Override vnode DAC admin perm. */ PRIV_VFS_EXEC, /* Override vnode DAC exec perm. */ PRIV_VFS_LOOKUP, /* Override vnode DAC lookup perm. */ PRIV_VFS_BLOCKRESERVE, /* Can use free block reserve. */ ... As you can see, they break down into both a set of system management privileges, relating to configuring kernel services, and then a set of specific privileges associated with (and sorted by) major kernel subsystems. None of this implies a change in underlying policy -- just that a bit more contextual information is passed into the privilege check. This has some important specific functional benefits: - It makes it possible to migrate the "allowed in jail" decision from the calling context to the privilege management code. This will allow us to gradually eliminate the passing of flags to the privilege check code under almost all circumstances. In my patch, I have added a new function to kern_jail.c, prison_priv_check(), which essentially contains a switch statement listing the privileges allowed in jail, and denying the rest. Configurable privileges, raw socket access, etc, can now occur in one place, and open the door to introducing more easy per-jail configuration of privilege. After these changes, the implementation is much more centralized in kern_jail.c. - It makes it possible for the MAC Framework to restrict access to privilege, a feature required for the SEBSD policy module, which implements the FLASK/Type Enforcement policy environment as found in SELinux. Policy modules can register interest in privilege checks, and then specifically deny access to privileges as they see fit. - It makes it possible for the MAC Framework to allow policies to grant privilege. Policy modules can register interest in privilege checks, and then specifically grant access to privileges as they see fit. In order to demonstrate MAC Framework integration with the privilege system, I have implemented a sample policy module, mac_privs, which allows rule-based granting of privileges to specific uids. Using a command line tool, appropriately privileged processes can modify the rule list, granting named privileges to unprivileged users. This is not a particularly mature example of a privilege-granting policy, as ideally privilege is something that is available but not always exercised -- i.e., similar to a setuid root binary that switches the effective uid to root only when it specifically needs privilege. However, it's quite useful in practice, and demonstrates how configurable policies can interact with kernel privilege decisions. In the past, I've done similar work on two occasions: once in implementing POSIX.1e privileges for FreeBSD as part of the TrustedBSD Project (not merged), and once as part of the SEBSD implementation. This work is functionally similar, but there are several important ways in which this design differs from the POSIX.1e approach (also used in Linux): - The identification of privileges is quite fine-grained. The Linux-extended POSIX.1e privilege set contains high level privileges like "Network privilege", which encapsulates a broad range of different network privilege checks. I have identified over 50 different specific network privileges, each separately named. It would be easy to map these into the POSIX.1e privilege set, which is presumably what the SEBSD policy will need to do in order to produce the narrower set expected by the SELinux code. - The approach is intended to allow the granting as well as denying of privilege. This is an important design choice, and has both some costs and some benefits. One important benefit is that it has historically proven difficult to take rights away from the root user without introducing security vulnerabilities associated with applications written to use root privilege expecting that all privileges be in place. Granting specific privileges implies a fairly different application and policy construction and may well be safer. - Because of the fine-grained naming of privileges, it's possible to encapsulate jail in a way that was not previously possible: the POSIX.1e privilege set was simply too coarse to capture the requirements of jail. - Privileges under this model are not treated as maskable values. In practice, there are very few situations in which it is useful to check multiple privileges at once, and permitting that encourages authors adding new privilege checks to combine privileges in a way that makes it opaque to the privilege mechanism as to which privilege was actually needed. This also has the benefit of making it much easier/more efficient to add new privileges as required, as it doesn't require expanding a bit string representing the privileges. Most POSIX.1e implementations limit the total number of privileges to 32 to 64 in order to have them fit in a bitmask easily. - By assigning new privileges for every privilege with significantly different semantic, the question of "when to add a new privilege" is answered: unless there is an obvious match, you add one. With the POSIX.1e + Linux set, it is necessary to try to figure out how to fit a new check into one of many poorly matching privileges. The result was that almost all privileges not clearly matched to one of the POSIX.1e set ended up in the catch-all CAP_SYS_ADMIN. The status of this work is that a pretty functional prototype can be found in Perforce: //depot/projects/trustedbsd/priv/... A snapshot patch from the branch, excluding mac_privs, can be found here: http://www.watson.org/~robert/freebsd/20060913-trustedbsd-priv.diff In that tree, you'll want particularly to look at: sys/kern/kern_jail.c Revised jail privilege behavior sys/kern/kern_priv.c Privilege check implementation sys/security/mac/mac_priv.c MAC extensions for privileges sys/security/mac_privs/* Sample MAC policy granting privileges sys/sys/priv.h Privilege list, API share/man/man9/priv.9 Draft man page usr.sbin/mac_privs/* Management tool for sample MAC policy It is my intent, following review, discussion, cleanup, etc, to commit the priv(9) work, sans mac_privs, to the 7.x tree in the next couple of weeks. The mac_privs policy is a sample policy that will continue to be maintained as part of the TrustedBSD Project, but not merged into the base tree at this point. Some remaining TODO items are: - Review various XXX comments I added as part of this work. - Complete modification of System V IPC code to properly check privileges. - Update mac_none.c sample policy to include privilege stubs. - Possibly move securelevel support to kern_priv.c, since it largely relates to privilege. - Teach the audit subsystem to collect privilege information during a system call, and add it to audit records using privilege tokens (already present in Solaris). - Complete man page updates, including finalize priv.9, trim down suser.9. - Create further privilege-related regression tests. - Finalize decision on using an enum or an int to identify privileges. Using an enum requires more namespace pollution, and requires hard-coded values anyway in order to avoid ABI issues. Possibly using #defines would be simpler. I'd like to greatfully acknowledge the sponsorship of nCircle Network Security, Inc in performing this work. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Wed Sep 13 18:41:19 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 A59F616A40F; Wed, 13 Sep 2006 18:41:19 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-0-0-cust107.cdif.cable.ntl.com [81.104.168.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FA5E43D49; Wed, 13 Sep 2006 18:41:19 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GNZfg-0009v7-4h; Wed, 13 Sep 2006 19:41:16 +0100 Date: Wed, 13 Sep 2006 19:41:16 +0100 From: Ceri Davies To: Robert Watson Message-ID: <20060913184115.GE93949@submonkey.net> Mail-Followup-To: Ceri Davies , Robert Watson , arch@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org References: <20060913150912.J1823@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <20060913150912.J1823@fledge.watson.org> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.13 (2006-08-11) Sender: Ceri Davies Cc: arch@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org Subject: Re: New in-kernel privilege API: priv(9) 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: Wed, 13 Sep 2006 18:41:19 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 13, 2006 at 03:29:14PM +0100, Robert Watson wrote: > What does this all mean in practice? It means replacing suser(9) and=20 > suser_cred(9) with calls that express the specific privilege being checke= d=20 > for. I took the most straight forward possible implementation: I reviewe= d=20 > all privilege checks in the kernel, identified all identical privileges a= nd=20 > categorized all privileges by subsystem. I then assigned unique numeric= =20 > constants to each unique privilege, and added a privilege identifier=20 > argument to the two new functions, priv_check(9) and priv_check_cred(9).= =20 Is this wilfully different from the privileges(5) model in Solaris 10 (http://docs.sun.com/app/docs/doc/816-5175/6mbba7f3b?a=3Dview) ? It seems that there would be some benefit in having at least a minimal common API and set of privilege names, not least to help with issues such as that raised in http://issues.apache.org/bugzilla/show_bug.cgi?id=3D34671. Having only just started to look over your work, I'll be happy to be put straight if we're talking about completely different things, but on the surface they're looking very similar. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFCFDLocfcwTS3JF8RAnXZAJ9WYU5EpK1WoDq5jOQ4DSSOvrZzDQCgp8sG Hs5o85qX1T2nspBoTDjB6nY= =SZPI -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- From owner-freebsd-arch@FreeBSD.ORG Wed Sep 13 20:28: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 3B3CC16A403; Wed, 13 Sep 2006 20:28: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 4DC1543D55; Wed, 13 Sep 2006 20:28:29 +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 B7AD946C08; Wed, 13 Sep 2006 16:28:24 -0400 (EDT) Date: Wed, 13 Sep 2006 21:28:24 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ceri Davies In-Reply-To: <20060913184115.GE93949@submonkey.net> Message-ID: <20060913194559.U53301@fledge.watson.org> References: <20060913150912.J1823@fledge.watson.org> <20060913184115.GE93949@submonkey.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org Subject: Re: New in-kernel privilege API: priv(9) 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: Wed, 13 Sep 2006 20:28:30 -0000 On Wed, 13 Sep 2006, Ceri Davies wrote: > On Wed, Sep 13, 2006 at 03:29:14PM +0100, Robert Watson wrote: > >> What does this all mean in practice? It means replacing suser(9) and >> suser_cred(9) with calls that express the specific privilege being checked >> for. I took the most straight forward possible implementation: I reviewed >> all privilege checks in the kernel, identified all identical privileges and >> categorized all privileges by subsystem. I then assigned unique numeric >> constants to each unique privilege, and added a privilege identifier >> argument to the two new functions, priv_check(9) and priv_check_cred(9). > > Is this wilfully different from the privileges(5) model in Solaris 10 > (http://docs.sun.com/app/docs/doc/816-5175/6mbba7f3b?a=view) ? > > It seems that there would be some benefit in having at least a minimal > common API and set of privilege names, not least to help with issues such as > that raised in http://issues.apache.org/bugzilla/show_bug.cgi?id=34671. > > Having only just started to look over your work, I'll be happy to be put > straight if we're talking about completely different things, but on the > surface they're looking very similar. A couple of points: First, the system present in Solaris is, in effect, a variant of some draft of POSIX.1e (or possibly vice versa), albeit with differently named constants. All the comments I made regarding POSIX.1e apply to it. Specifically, the priv(9) kernel API offers much more fine-grained assignment of rights relating to system administration, etc, corresponding specifically to the set of privileges defined in our kernel. Second, privileges(5) describes an alternative privilege model exposed to userspace, whereas the work I've described is an in-kernel API for privilege checking. It doesn't imply (or, for that matter, implement) a change in the OS privilege model, although clearly it would facilitate doing that in the future. Since priv(9) is not an application API, it's not clear that application portability is an immediate concern. FYI, we have previously implemented POSIX.1e capabilities (privileges) on FreeBSD as part of the TrustedBSD work, and rejected it for inclusion based on a number of criteria. The most important were: - The risk associated with changing the OS privilege model -- notice that the inheritence/effective/permitted behavior of POSIX.1e is quite complex, not to mention the application compatibility risks (recall the Linux sendmail problem a few years ago). - The lack of granularity is a significant problem for most implementations of POSIX.1e. The base set of privileges is fairly carefully designed to match the instances of privilege in POSIX, and so does fairly well, all systems require extensions to the basic POSIX set (as they all extend POSIX), and the common extensions are generally not fine-grained at all. Witness CAP_SYS_ADMIN on Linux, which is a catch-all for may different privileges. I selected the PRIV_ privilege names in order to avoid conflicting with the POSIX.1e CAP_ naming scheme, so that if that scheme is implemented as a wrapper to the underling priv(9) privilege API in the kernel, there won't be problems. Avoiding conflicts with the Solaris scheme would be useful, but is more tricky (possibly because it is more sensible :-). I think it's useful to compare the Solaris privilege set, and also consider whether in the future we want to adopt a privilege model along similar lines. However, given that the privilege models across various UNIX and non-UNIX systems are all similar and yet completely different, I'm not sure that being similar and yet different from Solaris is particularly a problem -- more, say, than being similar but different from IRIX, Linux, Windows, etc. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Thu Sep 14 00:53:12 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 8870116A403; Thu, 14 Sep 2006 00:53:12 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA98F43D49; Thu, 14 Sep 2006 00:53:11 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.185.148] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1GNfTY1LqT-0004Ll; Thu, 14 Sep 2006 02:53:09 +0200 From: Max Laier Organization: FreeBSD To: freebsd-arch@freebsd.org Date: Thu, 14 Sep 2006 02:52:58 +0200 User-Agent: KMail/1.9.3 References: <20060913150912.J1823@fledge.watson.org> In-Reply-To: <20060913150912.J1823@fledge.watson.org> 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="nextPart1904315.JXRpWPjbaF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200609140253.06818.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: trustedbsd-discuss@trustedbsd.org, Robert Watson Subject: Re: New in-kernel privilege API: priv(9) 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, 14 Sep 2006 00:53:12 -0000 --nextPart1904315.JXRpWPjbaF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 13 September 2006 16:29, Robert Watson wrote: =2E.. > - It makes it possible to migrate the "allowed in jail" decision from > the calling context to the privilege management code. This will allow > us to gradually eliminate the passing of flags to the privilege check > code under almost all circumstances. In my patch, I have added a new > function to kern_jail.c, prison_priv_check(), which essentially > contains a switch statement listing the privileges allowed in jail, and > denying the rest. Configurable privileges, raw socket access, etc, can > now occur in one place, and open the door to introducing more easy > per-jail configuration of privilege. After these changes, the > implementation is much more centralized in kern_jail.c. =2E.. > - Privileges under this model are not treated as maskable values. In > practice, there are very few situations in which it is useful to > check multiple privileges at once, and permitting that encourages > authors adding new privilege checks to combine privileges in a way that > makes it opaque to the privilege mechanism as to which privilege was > actually needed. This also has the benefit of making it much > easier/more efficient to add new privileges as required, as it doesn't > require expanding a bit string representing the privileges. Most > POSIX.1e implementations limit the total number of privileges to 32 to > 64 in order to have them fit in a bitmask easily. I tried to read with care and understand the reason behind not using=20 flags - at least partly. I didn't find any in your email so: Wouldn't=20 it make sense to mask off at least part of it to encode some general=20 decision into the privilege value directly. A la: #define ALLOW_IN_JAIL 0x8000000 #define PRIV_KTRACE (42 | ALLOW_IN_JAIL) Right now, prison_priv_check() is looking rather scary to me. If=20 something else wants to decide on finer granularity, alright, but in my=20 opinion it's easier (more obvious) to keep the "normal" information in=20 the .h file where the privileges are defined and described - as we are=20 aiming for centralization of the decision and information. On top of=20 that the caller could mask off ALLOW_IN_JAIL if they think it's not=20 appropriate in a special use case of the privilege. On an aside, it would be nice to have "optional" privilege checks i.e. in=20 pf we trust the file permissions on /dev/pf (plus securelevel) to decide=20 if someone is allowed to fiddle with the firewall. It would be nice to=20 have a way of allowing MAC (or whatever) to decide this - without=20 disallowing non-root use as long as the policy doesn't care. In code=20 that would mean a "if (flags & SUSER_OPTIONAL) return (0);" just before=20 the "if (suser_enabled) ..."-block. The policy would have it's go in=20 mac_priv_check() above. =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 --nextPart1904315.JXRpWPjbaF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFCKfyXyyEoT62BG0RAm+oAJ0R+b7GOdcs8AWmgcTeH0zKRtcnXACfWJaz N4Ze73ntubwq04t0FmTpn9s= =Gogc -----END PGP SIGNATURE----- --nextPart1904315.JXRpWPjbaF-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 14 06:17:19 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 B3E6316A403; Thu, 14 Sep 2006 06:17:19 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id D553643D45; Thu, 14 Sep 2006 06:17:18 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5D428.dip.t-dialin.net [84.165.212.40]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k8E5t7pn013906; Thu, 14 Sep 2006 07:55:08 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (webmail.Leidinger.net [192.168.1.102]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k8E6HENg001182; Thu, 14 Sep 2006 08:17:14 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 14 Sep 2006 08:17:03 +0200 Message-ID: <20060914081703.umum0k4x3k88k4ko@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 14 Sep 2006 08:17:03 +0200 From: Alexander Leidinger To: Robert Watson References: <20060913150912.J1823@fledge.watson.org> In-Reply-To: <20060913150912.J1823@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-Virus-Scanned: by amavisd-new Cc: arch@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org Subject: Re: New in-kernel privilege API: priv(9) 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, 14 Sep 2006 06:17:19 -0000 Quoting Robert Watson (from Wed, 13 Sep 2006 =20 15:29:14 +0100 (BST)): > privilege list in src/sys/priv.h: > ... > PRIV_UFS_SETQUOTA, /* setquota(). */ > PRIV_UFS_SETUSE, /* setuse(). */ > PRIV_UFS_EXCEEDQUOTA, /* Exempt from quota restrictions. */ Is this something special to UFS, or did you use the UFS part only =20 because no other filesystem in the tree has support for quotas? > - It makes it possible for the MAC Framework to allow policies to grant > privilege. Policy modules can register interest in privilege checks, an= d > then specifically grant access to privileges as they see fit. > > In order to demonstrate MAC Framework integration with the privilege > system, I have implemented a sample policy module, mac_privs, which > allows rule-based granting of privileges to specific uids. Using a > command line tool, appropriately privileged processes can modify the > rule list, granting named privileges to unprivileged users. This is > not a particularly mature example of a privilege-granting policy, as > ideally privilege is something that is available but not always > exercised -- i.e., similar to a setuid root binary that switches the > effective uid to root only when it specifically needs privilege. > However, it's quite useful in practice, and demonstrates how > configurable policies can interact with kernel privilege decisions. > It is my intent, following review, discussion, cleanup, etc, to commit > the priv(9) work, sans mac_privs, to the 7.x tree in the next couple of > weeks. The mac_privs policy is a sample policy that will continue to be > maintained as part of the TrustedBSD Project, but not merged into the > base tree at this point. Is the mac_privs policy just a proof of concept? It would be nice to =20 allow more fine grained access to some users or applications. The =20 later one would need some way to identify the application/binary in a =20 safe way, maybe by using extended attributes in the FS. Bye, Alexander. --=20 Real programmers don't write specs -- users should consider themselves lucky to get any programs at all and take what they get. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-arch@FreeBSD.ORG Thu Sep 14 21:49:24 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 41C0916A492; Thu, 14 Sep 2006 21:49:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A440643D49; Thu, 14 Sep 2006 21:49:21 +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 E9CA946BE2; Thu, 14 Sep 2006 17:49:19 -0400 (EDT) Date: Thu, 14 Sep 2006 22:49:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Max Laier In-Reply-To: <200609140253.06818.max@love2party.net> Message-ID: <20060914224516.G53301@fledge.watson.org> References: <20060913150912.J1823@fledge.watson.org> <200609140253.06818.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: trustedbsd-discuss@trustedbsd.org, freebsd-arch@freebsd.org Subject: Re: New in-kernel privilege API: priv(9) 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, 14 Sep 2006 21:49:24 -0000 On Thu, 14 Sep 2006, Max Laier wrote: > I tried to read with care and understand the reason behind not using flags - > at least partly. I didn't find any in your email so: Wouldn't it make > sense to mask off at least part of it to encode some general decision into > the privilege value directly. A la: > > #define ALLOW_IN_JAIL 0x8000000 > > #define PRIV_KTRACE (42 | ALLOW_IN_JAIL) > > Right now, prison_priv_check() is looking rather scary to me. If something > else wants to decide on finer granularity, alright, but in my opinion it's > easier (more obvious) to keep the "normal" information in the .h file where > the privileges are defined and described - as we are aiming for > centralization of the decision and information. On top of that the caller > could mask off ALLOW_IN_JAIL if they think it's not appropriate in a special > use case of the privilege. I'd like to avoid encoding the behavior of the jail policy into the privilege mechanism if we can avoid it, or changes in prison policy won't be properly propagated to binary modules, etc. Imagine for a moment that the prison_check_priv() function contained none of the commented out privileges, which will be its final state, and with comments explaining which particular clusters of privileges are allowed (and are safe) in Jail. The commented out privileges listed there are primarily so I can make sure all the privileges are in sync during development, and not required in the long term. > On an aside, it would be nice to have "optional" privilege checks i.e. in pf > we trust the file permissions on /dev/pf (plus securelevel) to decide if > someone is allowed to fiddle with the firewall. It would be nice to have a > way of allowing MAC (or whatever) to decide this - without disallowing > non-root use as long as the policy doesn't care. In code that would mean a > "if (flags & SUSER_OPTIONAL) return (0);" just before the "if > (suser_enabled) ..."-block. The policy would have it's go in > mac_priv_check() above. Just to make sure I understnad what you're describing: you would like a way to tell the kernel that specific privileges can have a relaxed policy for granting the privilege? I.e., throwing a global flag that grants the privilege to arbitrary credentials, rather than just root credentials? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Thu Sep 14 21:53:41 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 6CF6216A407; Thu, 14 Sep 2006 21:53:41 +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 0DFBE43D46; Thu, 14 Sep 2006 21:53:41 +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 55E7546BE2; Thu, 14 Sep 2006 17:53:40 -0400 (EDT) Date: Thu, 14 Sep 2006 22:53:40 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Leidinger In-Reply-To: <20060914081703.umum0k4x3k88k4ko@webmail.leidinger.net> Message-ID: <20060914224925.W53301@fledge.watson.org> References: <20060913150912.J1823@fledge.watson.org> <20060914081703.umum0k4x3k88k4ko@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org Subject: Re: New in-kernel privilege API: priv(9) 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, 14 Sep 2006 21:53:41 -0000 On Thu, 14 Sep 2006, Alexander Leidinger wrote: > Quoting Robert Watson (from Wed, 13 Sep 2006 15:29:14 > +0100 (BST)): > >> privilege list in src/sys/priv.h: > >> ... >> PRIV_UFS_SETQUOTA, /* setquota(). */ >> PRIV_UFS_SETUSE, /* setuse(). */ >> PRIV_UFS_EXCEEDQUOTA, /* Exempt from quota restrictions. */ > > Is this something special to UFS, or did you use the UFS part only because > no other filesystem in the tree has support for quotas? They were labeled as UFS because they are currently somewhat UFS-specific, but you're right: it might well make sense to rename them to VFS as other file systems may gain support in the future. I'll make this change in P4. >> It is my intent, following review, discussion, cleanup, etc, to commit the >> priv(9) work, sans mac_privs, to the 7.x tree in the next couple of weeks. >> The mac_privs policy is a sample policy that will continue to be maintained >> as part of the TrustedBSD Project, but not merged into the base tree at >> this point. > > Is the mac_privs policy just a proof of concept? It would be nice to allow > more fine grained access to some users or applications. The later one would > need some way to identify the application/binary in a safe way, maybe by > using extended attributes in the FS. Yes, I consider it a proof of concept. Per my comments in a previous e-mail, I'm hesitant to rush into a modified privilege policy that either restricts the root user, or grants privileges to other processes, without a lot of careful thinking. The POSIX.1e-like privilege models used in many operating systems contain many subtleties, and in prior work on FreeBSD to experiment with those models, it was clear the level of risk in such a change was high. You can see some of this complexity by looking at the inheritence/etc logic in the linux POSIX.1e code, the Solaris privileges(5) man page, or the POSIX.1e draft specs. A lot of the complexity comes out of the binding of privileges to files (similar to setuid) and the details of the inheritence and compatibility support for "unaware" applications. If you take a glance at the trustedbsd_cap branch, you can find an implementation of POSIX.1e capabilities on FreeBSD from several years ago. I'm not opposed to revisiting this general issue, and in fact, the priv(9) work is intended to facilitate exactly that sort of work, but we need to do it very carefully. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Fri Sep 15 00:08: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 B763316A407; Fri, 15 Sep 2006 00:08:58 +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 0E33F43D46; Fri, 15 Sep 2006 00:08:57 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.182.121] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1GO1GJ0KnT-0002n7; Fri, 15 Sep 2006 02:08:56 +0200 From: Max Laier Organization: FreeBSD To: Robert Watson Date: Fri, 15 Sep 2006 02:08:45 +0200 User-Agent: KMail/1.9.3 References: <20060913150912.J1823@fledge.watson.org> <200609140253.06818.max@love2party.net> <20060914224516.G53301@fledge.watson.org> In-Reply-To: <20060914224516.G53301@fledge.watson.org> 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="nextPart1696485.Dd1bkIxD5j"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200609150208.53002.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: trustedbsd-discuss@trustedbsd.org, freebsd-arch@freebsd.org Subject: Re: New in-kernel privilege API: priv(9) 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, 15 Sep 2006 00:08:58 -0000 --nextPart1696485.Dd1bkIxD5j Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 14 September 2006 23:49, Robert Watson wrote: > On Thu, 14 Sep 2006, Max Laier wrote: > > I tried to read with care and understand the reason behind not using > > flags - at least partly. I didn't find any in your email so:=20 > > Wouldn't it make sense to mask off at least part of it to encode some > > general decision into the privilege value directly. A la: > > > > #define ALLOW_IN_JAIL 0x8000000 > > > > #define PRIV_KTRACE (42 | ALLOW_IN_JAIL) > > > > Right now, prison_priv_check() is looking rather scary to me. If > > something else wants to decide on finer granularity, alright, but in > > my opinion it's easier (more obvious) to keep the "normal" > > information in the .h file where the privileges are defined and > > described - as we are aiming for centralization of the decision and > > information. On top of that the caller could mask off ALLOW_IN_JAIL > > if they think it's not appropriate in a special use case of the > > privilege. > > I'd like to avoid encoding the behavior of the jail policy into the > privilege mechanism if we can avoid it, or changes in prison policy > won't be properly propagated to binary modules, etc. Imagine for a > moment that the prison_check_priv() function contained none of the > commented out privileges, which will be its final state, and with > comments explaining which particular clusters of privileges are allowed > (and are safe) in Jail. The commented out privileges listed there are > primarily so I can make sure all the privileges are in sync during > development, and not required in the long term. Okay. It just looks strange/scary and I though that a flag would be a=20 good way to solve/work around that. Might be a matter of taste, though. > > On an aside, it would be nice to have "optional" privilege checks > > i.e. in pf we trust the file permissions on /dev/pf (plus > > securelevel) to decide if someone is allowed to fiddle with the > > firewall. It would be nice to have a way of allowing MAC (or > > whatever) to decide this - without disallowing non-root use as long > > as the policy doesn't care. In code that would mean a "if (flags & > > SUSER_OPTIONAL) return (0);" just before the "if (suser_enabled) > > ..."-block. The policy would have it's go in mac_priv_check() above. > > Just to make sure I understnad what you're describing: you would like a > way to tell the kernel that specific privileges can have a relaxed > policy for granting the privilege? I.e., throwing a global flag that > grants the privilege to arbitrary credentials, rather than just root > credentials? I would like to give additional policy checks (such as MAC) a chance to=20 deny privileges that do not necessarily require root right now, but might=20 be interesting nontheless. In the case of pf you might want to chown /dev/pf to "firewall operator"=20 and be able to enforce this with your policy module additionally. Right=20 now, the only way to restrict/check access to /dev/pf is the filesystem=20 privileges on it + securelevel settings. I'm coming from this very restricted use case, but I though it might be=20 worth noting that there are places where privileges are coming from=20 somewhere else. A privilege policy module might want to have a look=20 still. =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 --nextPart1696485.Dd1bkIxD5j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFCe8UXyyEoT62BG0RApgQAJ4p1qVaNAOrOcylhEf/GYWwRb6YIwCcCG1y aByQQOSxv+Id/Oc0tBf3OKc= =zSTZ -----END PGP SIGNATURE----- --nextPart1696485.Dd1bkIxD5j-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 15 08:33:58 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 5362516A412; Fri, 15 Sep 2006 08:33:58 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-0-0-cust107.cdif.cable.ntl.com [81.104.168.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE89543D45; Fri, 15 Sep 2006 08:33:57 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GO991-0001lN-K4; Fri, 15 Sep 2006 09:33:55 +0100 Date: Fri, 15 Sep 2006 09:33:55 +0100 From: Ceri Davies To: Robert Watson Message-ID: <20060915083355.GK93949@submonkey.net> Mail-Followup-To: Ceri Davies , Robert Watson , arch@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org References: <20060913150912.J1823@fledge.watson.org> <20060913184115.GE93949@submonkey.net> <20060913194559.U53301@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TmwHKJoIRFM7Mu/A" Content-Disposition: inline In-Reply-To: <20060913194559.U53301@fledge.watson.org> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.13 (2006-08-11) Sender: Ceri Davies Cc: arch@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org Subject: Re: New in-kernel privilege API: priv(9) 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, 15 Sep 2006 08:33:58 -0000 --TmwHKJoIRFM7Mu/A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 13, 2006 at 09:28:24PM +0100, Robert Watson wrote: > A couple of points: >=20 > First, the system present in Solaris is, in effect, a variant of some dra= ft=20 > of POSIX.1e (or possibly vice versa), albeit with differently named=20 > constants. All the comments I made regarding POSIX.1e apply to it. =20 > Specifically, the priv(9) kernel API offers much more fine-grained=20 > assignment of rights relating to system administration, etc, correspondin= g=20 > specifically to the set of privileges defined in our kernel. Agreed. > Second, privileges(5) describes an alternative privilege model exposed to= =20 > userspace, whereas the work I've described is an in-kernel API for=20 > privilege checking. It doesn't imply (or, for that matter, implement) a= =20 > change in the OS privilege model, although clearly it would facilitate=20 > doing that in the future. Since priv(9) is not an application API, it's= =20 > not clear that application portability is an immediate concern. That's the difference I was looking for, thanks. > I think it's useful to compare the Solaris privilege set, and also consid= er=20 > whether in the future we want to adopt a privilege model along similar=20 > lines. However, given that the privilege models across various UNIX and= =20 > non-UNIX systems are all similar and yet completely different, I'm not su= re=20 > that being similar and yet different from Solaris is particularly a probl= em=20 > -- more, say, than being similar but different from IRIX, Linux, Windows,= =20 > etc. True enough. Thanks. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --TmwHKJoIRFM7Mu/A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFCmVzocfcwTS3JF8RAm2WAJ0VyFfVnLFaUhqJNnAr2AcVYkEiYwCZAZXd Osof4g2d8KRP9U5HbWH/JSA= =4dhl -----END PGP SIGNATURE----- --TmwHKJoIRFM7Mu/A-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 15 14:26:30 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 21E0B16A416 for ; Fri, 15 Sep 2006 14:26:30 +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 8652443D6E for ; Fri, 15 Sep 2006 14:26:28 +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 890F1EB3158 for ; Fri, 15 Sep 2006 22:26:26 +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 yr3fP9fSaL46 for ; Fri, 15 Sep 2006 22:26:23 +0800 (CST) Received: from [192.168.1.32] (unknown [221.216.126.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 51047EB3100 for ; Fri, 15 Sep 2006 22:26:23 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:content-type:content-transfer-encoding; b=jRQHxjAoh3x62TVqXkfzRlwPdZNQlyzLLGXozcPsh1KmHwDNHccmwqHG3P9wDIHlQ sLRkR8j1LrGPSUIenwsTA== Message-ID: <450AB80B.1050100@delphij.net> Date: Fri, 15 Sep 2006 22:26:19 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: How to map a page with userland program? 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, 15 Sep 2006 14:26:30 -0000 Dear folks, Is there a continent and MI way to map a kernel page into userland address space under the same virtual address? It seems that this can be implemented through some routines in MD part of pmap, but is it possible to use higher level VM routines to do the job? Cheers, -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! From owner-freebsd-arch@FreeBSD.ORG Fri Sep 15 14:34:28 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 B68BF16A412 for ; Fri, 15 Sep 2006 14:34:28 +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 3EC4B43D45 for ; Fri, 15 Sep 2006 14:34:28 +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 3967FEB2F47; Fri, 15 Sep 2006 22:34:26 +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 8UZMSc2ufZZc; Fri, 15 Sep 2006 22:34:20 +0800 (CST) Received: from [192.168.1.32] (unknown [221.216.126.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 76F20EB3159; Fri, 15 Sep 2006 22:34:20 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type:content-transfer-encoding; b=okD24IG0+RfldrDonF+hJvRzJcG096OIUlehNs/2WBXPYQKO44atPiecNCpgWnjhn 1rXnpd0bdaj7ikrwdJbjQ== Message-ID: <450AB9E7.7080302@delphij.net> Date: Fri, 15 Sep 2006 22:34:15 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: LI Xin References: <450AB80B.1050100@delphij.net> In-Reply-To: <450AB80B.1050100@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: How to map a page with userland program? 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, 15 Sep 2006 14:34:28 -0000 Oops, I mean map a page into userland address space. -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! From owner-freebsd-arch@FreeBSD.ORG Fri Sep 15 14:46:47 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 2EFD616A58D for ; Fri, 15 Sep 2006 14:46:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29C8843D5F for ; Fri, 15 Sep 2006 14:46:40 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8FEkD7A051402; Fri, 15 Sep 2006 10:46:19 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 15 Sep 2006 10:35:11 -0400 User-Agent: KMail/1.9.1 References: <450AB80B.1050100@delphij.net> In-Reply-To: <450AB80B.1050100@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609151035.12069.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Fri, 15 Sep 2006 10:46:19 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1885/Fri Sep 15 07:19:10 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: LI Xin Subject: Re: How to map a page with userland program? 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, 15 Sep 2006 14:46:47 -0000 On Friday 15 September 2006 10:26, LI Xin wrote: > Dear folks, > > Is there a continent and MI way to map a kernel page into userland > address space under the same virtual address? It seems that this can be > implemented through some routines in MD part of pmap, but is it possible > to use higher level VM routines to do the job? Not to the same userland virtual address. Why do you need the same virtual address anyway? If it's for pointers use offsets relative to the start of the page instead. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Sep 15 15:21:48 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 8B05A16A403; Fri, 15 Sep 2006 15:21:48 +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 1234A43D4C; Fri, 15 Sep 2006 15:21:47 +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 675ABEB3198; Fri, 15 Sep 2006 23:21:43 +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 09pp2GK66bDq; Fri, 15 Sep 2006 23:21:38 +0800 (CST) Received: from [192.168.1.32] (unknown [221.216.126.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 57A68EB1BE1; Fri, 15 Sep 2006 23:21:38 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type:content-transfer-encoding; b=FEOv/iV8eBzB/wU/U/XWKJC6HCrPHSLTJXcYmc64B4K8ns6Dogv04WeHzC0dwhsmD tv/TvymDAJfYAiwz7UjEA== Message-ID: <450AC4FE.6070303@delphij.net> Date: Fri, 15 Sep 2006 23:21:34 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: John Baldwin References: <450AB80B.1050100@delphij.net> <200609151035.12069.jhb@freebsd.org> In-Reply-To: <200609151035.12069.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: How to map a page with userland program? 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, 15 Sep 2006 15:21:48 -0000 John Baldwin wrote: > On Friday 15 September 2006 10:26, LI Xin wrote: >> Dear folks, >> >> Is there a continent and MI way to map a kernel page into userland >> address space under the same virtual address? It seems that this can be >> implemented through some routines in MD part of pmap, but is it possible >> to use higher level VM routines to do the job? > > Not to the same userland virtual address. Why do you need the same > virtual address anyway? If it's for pointers use offsets relative to > the start of the page instead. That would make it easier to implement some sort of VSYSCALL, which is in fact executed in userland. Or, is there any better way? :-) Cheers, -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! From owner-freebsd-arch@FreeBSD.ORG Fri Sep 15 16:44:02 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 D2AE716A40F; Fri, 15 Sep 2006 16:44:02 +0000 (UTC) (envelope-from John.Giacomoni@colorado.edu) Received: from serl.cs.colorado.edu (serl.cs.colorado.edu [128.138.207.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 102CD43D53; Fri, 15 Sep 2006 16:43:52 +0000 (GMT) (envelope-from John.Giacomoni@colorado.edu) Received: from [IPv6???1] (localhost [127.0.0.1]) by serl.cs.colorado.edu (Postfix) with ESMTP id 1E7F812BC9; Fri, 15 Sep 2006 10:43:26 -0600 (MDT) In-Reply-To: <200609151035.12069.jhb@freebsd.org> References: <450AB80B.1050100@delphij.net> <200609151035.12069.jhb@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/mixed; boundary=Apple-Mail-3--357219016 Message-Id: From: John Giacomoni Date: Fri, 15 Sep 2006 10:43:27 -0600 To: freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.752.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: LI Xin Subject: Re: How to map a page with userland program? 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, 15 Sep 2006 16:44:02 -0000 --Apple-Mail-3--357219016 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Sep 15, 2006, at 8:35 AM, John Baldwin wrote: > On Friday 15 September 2006 10:26, LI Xin wrote: >> Dear folks, >> >> Is there a continent and MI way to map a kernel page into userland >> address space under the same virtual address? It seems that this >> can be >> implemented through some routines in MD part of pmap, but is it >> possible >> to use higher level VM routines to do the job? > > Not to the same userland virtual address. Why do you need the same > virtual address anyway? If it's for pointers use offsets relative to > the start of the page instead. For what it is worth, I also have need of the same functionality. Specifically I'd like for the region's address space to be at the same offset for the kernel and multiple user-space applications. I'm passing messages around in shared memory and would prefer to eliminate the offset calculations for performance reasons. John G -- John.Giacomoni@colorado.edu University of Colorado at Boulder Department of Computer Science Engineering Center, ECCR 1B50 430 UCB Boulder, CO 80303-0430 USA --Apple-Mail-3--357219016 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed --Apple-Mail-3--357219016-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 15 17:08:50 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 7C24116A412 for ; Fri, 15 Sep 2006 17:08:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id C69BE43D60 for ; Fri, 15 Sep 2006 17:08:49 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8FH89i7052169; Fri, 15 Sep 2006 13:08:28 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: LI Xin Date: Fri, 15 Sep 2006 12:51:16 -0400 User-Agent: KMail/1.9.1 References: <450AB80B.1050100@delphij.net> <200609151035.12069.jhb@freebsd.org> <450AC4FE.6070303@delphij.net> In-Reply-To: <450AC4FE.6070303@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609151251.16371.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 15 Sep 2006 13:08:28 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1885/Fri Sep 15 07:19:10 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: How to map a page with userland program? 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, 15 Sep 2006 17:08:50 -0000 On Friday 15 September 2006 11:21, LI Xin wrote: > John Baldwin wrote: > > On Friday 15 September 2006 10:26, LI Xin wrote: > >> Dear folks, > >> > >> Is there a continent and MI way to map a kernel page into userland > >> address space under the same virtual address? It seems that this can be > >> implemented through some routines in MD part of pmap, but is it possible > >> to use higher level VM routines to do the job? > > > > Not to the same userland virtual address. Why do you need the same > > virtual address anyway? If it's for pointers use offsets relative to > > the start of the page instead. > > That would make it easier to implement some sort of VSYSCALL, which is > in fact executed in userland. Or, is there any better way? :-) If you want to stick code in the page, make the code PIC, the same as is done for shared libraries. Alternatively, if you wanted to be very, very evil and can have the page read-only once it is initialized, flip the user/supervisor bit in the kernel PTE for that page such that it is treated as a user page rather than a kernel page (even though it's in KVA), and then userland processes can access that page via it's kernel VA. Making the code PIC would probably be better though. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Sep 15 17:51:04 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 DECE416A407; Fri, 15 Sep 2006 17:51:04 +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 47BDB43D49; Fri, 15 Sep 2006 17:51:04 +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 B5137EB323E; Sat, 16 Sep 2006 01:51:02 +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 LkBDUxT7obNy; Sat, 16 Sep 2006 01:51:00 +0800 (CST) Received: from [192.168.1.32] (unknown [221.216.126.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 38FE8EB0BD2; Sat, 16 Sep 2006 01:50:59 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type:content-transfer-encoding; b=paRvf6W31vTmH0uuzvHdeaffdy/Hrm1PhKBxi0cq4la/KnnKugMZg4fUcEJhvBADJ zSDBwaE5nGl5Fnbmbjx8w== Message-ID: <450AE7FE.5000905@delphij.net> Date: Sat, 16 Sep 2006 01:50:54 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: John Baldwin References: <450AB80B.1050100@delphij.net> <200609151035.12069.jhb@freebsd.org> <450AC4FE.6070303@delphij.net> <200609151251.16371.jhb@freebsd.org> In-Reply-To: <200609151251.16371.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: How to map a page with userland program? 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, 15 Sep 2006 17:51:05 -0000 John Baldwin wrote: > On Friday 15 September 2006 11:21, LI Xin wrote: >> John Baldwin wrote: >>> On Friday 15 September 2006 10:26, LI Xin wrote: >>>> Dear folks, >>>> >>>> Is there a continent and MI way to map a kernel page into userland >>>> address space under the same virtual address? It seems that this can be >>>> implemented through some routines in MD part of pmap, but is it possible >>>> to use higher level VM routines to do the job? >>> Not to the same userland virtual address. Why do you need the same >>> virtual address anyway? If it's for pointers use offsets relative to >>> the start of the page instead. >> That would make it easier to implement some sort of VSYSCALL, which is >> in fact executed in userland. Or, is there any better way? :-) > > If you want to stick code in the page, make the code PIC, the same as is done > for shared libraries. Alternatively, if you wanted to be very, very evil and > can have the page read-only once it is initialized, flip the user/supervisor > bit in the kernel PTE for that page such that it is treated as a user page > rather than a kernel page (even though it's in KVA), and then userland > processes can access that page via it's kernel VA. Making the code PIC would > probably be better though. I see... So, what if I want to make some data available to userland? Is flipping the user/supervisor bit the only way? Cheers, -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! From owner-freebsd-arch@FreeBSD.ORG Fri Sep 15 20:44:43 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 3AC8716A407 for ; Fri, 15 Sep 2006 20:44:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 843BF43D46 for ; Fri, 15 Sep 2006 20:44:42 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8FKiNst053364; Fri, 15 Sep 2006 16:44:24 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: LI Xin Date: Fri, 15 Sep 2006 16:44:26 -0400 User-Agent: KMail/1.9.1 References: <450AB80B.1050100@delphij.net> <200609151251.16371.jhb@freebsd.org> <450AE7FE.5000905@delphij.net> In-Reply-To: <450AE7FE.5000905@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609151644.27040.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 15 Sep 2006 16:44:24 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1885/Fri Sep 15 07:19:10 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: How to map a page with userland program? 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, 15 Sep 2006 20:44:43 -0000 On Friday 15 September 2006 13:50, LI Xin wrote: > John Baldwin wrote: > > On Friday 15 September 2006 11:21, LI Xin wrote: > >> John Baldwin wrote: > >>> On Friday 15 September 2006 10:26, LI Xin wrote: > >>>> Dear folks, > >>>> > >>>> Is there a continent and MI way to map a kernel page into userland > >>>> address space under the same virtual address? It seems that this can be > >>>> implemented through some routines in MD part of pmap, but is it possible > >>>> to use higher level VM routines to do the job? > >>> Not to the same userland virtual address. Why do you need the same > >>> virtual address anyway? If it's for pointers use offsets relative to > >>> the start of the page instead. > >> That would make it easier to implement some sort of VSYSCALL, which is > >> in fact executed in userland. Or, is there any better way? :-) > > > > If you want to stick code in the page, make the code PIC, the same as is done > > for shared libraries. Alternatively, if you wanted to be very, very evil and > > can have the page read-only once it is initialized, flip the user/supervisor > > bit in the kernel PTE for that page such that it is treated as a user page > > rather than a kernel page (even though it's in KVA), and then userland > > processes can access that page via it's kernel VA. Making the code PIC would > > probably be better though. > > I see... So, what if I want to make some data available to userland? > Is flipping the user/supervisor bit the only way? Well, it's a quicker hack than the much more complicated way. Otherwise, you have to make sure everyone agrees on the same address. Hmm, I suppose actually you could just use a simple dummy device driver that creates a /dev/foo and mmap it using MMAP_FIXED with your chosen userland virtual address. Then in your driver you just need to malloc a page and use vtophys() to get a phys_addr to hand back in your d_mmap() routine. -- John Baldwin