From owner-freebsd-arch@FreeBSD.ORG Sun Aug 10 07:14:33 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58ECB106564A; Sun, 10 Aug 2008 07:14:33 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1DCAC8FC13; Sun, 10 Aug 2008 07:14:32 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 99265170E4; Sun, 10 Aug 2008 07:14:31 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m7A7EV8J001688; Sun, 10 Aug 2008 07:14:31 GMT (envelope-from phk@critter.freebsd.dk) To: John Baldwin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 09 Aug 2008 16:37:33 -0400." <200808091637.33820.jhb@freebsd.org> Date: Sun, 10 Aug 2008 07:14:31 +0000 Message-ID: <1687.1218352471@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: Make MOD_QUIESCE a bit more useful.. 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 Aug 2008 07:14:33 -0000 In message <200808091637.33820.jhb@freebsd.org>, John Baldwin writes: >So currently the MOD_QUIESCE event is posted to a module when unloading a kld >so it can veto non-forced unloads. However, the current implementation in >the kernel linker is to run through all the modules in a file, posting >MOD_QUIESCE followed by MOD_UNLOAD on each module serially. Thus, if you >have multiple modules in a single kld and one of the modules veto's an unload >request via MOD_QUIESCE, you don't know as the module author if any of your >modules were unloaded via MOD_UNLOAD or not. I think a better approach would >be to change the kernel linker to invoke MOD_QUIESCE on all modules in a >single pass first. If none of those fail (or it's a forced unload), then it can do a second pass invoking MOD_UNLOAD on all the modules. I thought it already worked that way, so no objection. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sun Aug 10 12:21:09 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94D511065670 for ; Sun, 10 Aug 2008 12:21:09 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from luidgi.portaone.com (luidgi.portaone.com [195.138.219.143]) by mx1.freebsd.org (Postfix) with ESMTP id 7E5618FC16 for ; Sun, 10 Aug 2008 12:21:09 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from mail.pbxpress.com ([65.61.203.142] helo=leaf.pbxpress.com) by luidgi.portaone.com (8.11.3/8.11.3) with ESMTP (TLSv1:AES256-SHA:256)id 1KS9v1-000DUi-O5; Sun, 10 Aug 2008 05:21:07 -0700 Received: from jeeves.bluezbox.com (k3-gw.portaone.com [193.28.87.193]) (authenticated bits=0) by leaf.pbxpress.com (8.13.3/8.13.3) with ESMTP id m7ACO9g4005721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Aug 2008 05:24:15 -0700 (PDT) (envelope-from gonzo@freebsd.org) Message-ID: <489EDD2F.9080302@freebsd.org> Date: Sun, 10 Aug 2008 15:21:03 +0300 From: Oleksandr Tymoshenko User-Agent: Thunderbird 2.0.0.14 (X11/20080704) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <20080729.161303.709402272.imp@bsdimp.com> <86r69buar0.fsf@ds4.des.no> <489B08F6.8060605@freebsd.org> <867iasfmrh.fsf@ds4.des.no> In-Reply-To: <867iasfmrh.fsf@ds4.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, recieved from trusted server Cc: arch@freebsd.org Subject: Re: Need a code review 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 Aug 2008 12:21:09 -0000 Dag-Erling Smørgrav wrote: > Oleksandr Tymoshenko writes: >> openpam detects static modules build using cpp(1) condition: >> #if defined(__GNUC__) && !defined(__PIC__) && !defined(NO_STATIC_MODULES) >> The problem is that gcc MIPS option -mabi-calls assumes -fpic for both >> static and dynamic builds. So the question is: would defining >> NO_STATIC_MODULES for MIPS be enough or it should be addressed >> upstream? > > "upstream" in this case means me. Here is new fix: http://people.freebsd.org/~gonzo/mips2/libpam2.diff The idea is to set define explicitly for dynamic case rather then rely on __PIC__. -- gonzo From owner-freebsd-arch@FreeBSD.ORG Sun Aug 10 20:51:44 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 883A8106572E; Sun, 10 Aug 2008 20:51:44 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 06EAF8FC1E; Sun, 10 Aug 2008 20:51:44 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 042242049; Sun, 10 Aug 2008 22:51:41 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id D72E48449B; Sun, 10 Aug 2008 22:51:41 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Oleksandr Tymoshenko References: <20080729.161303.709402272.imp@bsdimp.com> <86r69buar0.fsf@ds4.des.no> <489B08F6.8060605@freebsd.org> <867iasfmrh.fsf@ds4.des.no> <489EDD2F.9080302@freebsd.org> Date: Sun, 10 Aug 2008 22:51:41 +0200 In-Reply-To: <489EDD2F.9080302@freebsd.org> (Oleksandr Tymoshenko's message of "Sun, 10 Aug 2008 15:21:03 +0300") Message-ID: <86myjkbnky.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Need a code review 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 Aug 2008 20:51:44 -0000 Oleksandr Tymoshenko writes: > Here is new fix: http://people.freebsd.org/~gonzo/mips2/libpam2.diff > The idea is to set define explicitly for dynamic case rather then rely > on __PIC__. This is completely backwards. Dynamic is the default option, and in fact the only supported option on many (non-FreeBSD) systems. If it were up to me, I would remove support for statically linked modules entirely. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sun Aug 10 22:55:37 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDFC0106566B; Sun, 10 Aug 2008 22:55:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 917548FC13; Sun, 10 Aug 2008 22:55:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7AMrDsQ095398; Sun, 10 Aug 2008 16:53:13 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 10 Aug 2008 16:53:33 -0600 (MDT) Message-Id: <20080810.165333.232928772.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <200808091637.33820.jhb@freebsd.org> References: <200808091637.33820.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: Make MOD_QUIESCE a bit more useful.. 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 Aug 2008 22:55:37 -0000 In message: <200808091637.33820.jhb@freebsd.org> John Baldwin writes: : So currently the MOD_QUIESCE event is posted to a module when unloading a kld : so it can veto non-forced unloads. However, the current implementation in : the kernel linker is to run through all the modules in a file, posting : MOD_QUIESCE followed by MOD_UNLOAD on each module serially. Thus, if you : have multiple modules in a single kld and one of the modules veto's an unload : request via MOD_QUIESCE, you don't know as the module author if any of your : modules were unloaded via MOD_UNLOAD or not. I think a better approach would : be to change the kernel linker to invoke MOD_QUIESCE on all modules in a : single pass first. If none of those fail (or it's a forced unload), then it : can do a second pass invoking MOD_UNLOAD on all the modules. That sounds great to me. I'm a bit surprised it is implemented the way you say... Warner From owner-freebsd-arch@FreeBSD.ORG Mon Aug 11 04:58:51 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 323DC1065671 for ; Mon, 11 Aug 2008 04:58:51 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outy.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id 13D0D8FC16 for ; Mon, 11 Aug 2008 04:58:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 9383D24E4; Sun, 10 Aug 2008 21:59:36 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id DE6642D6109; Sun, 10 Aug 2008 21:58:49 -0700 (PDT) Message-ID: <489FC706.7050306@elischer.org> Date: Sun, 10 Aug 2008 21:58:46 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: "M. Warner Losh" References: <200808091637.33820.jhb@freebsd.org> <20080810.165333.232928772.imp@bsdimp.com> In-Reply-To: <20080810.165333.232928772.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, jhb@FreeBSD.org Subject: Re: Make MOD_QUIESCE a bit more useful.. 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 Aug 2008 04:58:51 -0000 M. Warner Losh wrote: > In message: <200808091637.33820.jhb@freebsd.org> > John Baldwin writes: > : So currently the MOD_QUIESCE event is posted to a module when unloading a kld > : so it can veto non-forced unloads. However, the current implementation in > : the kernel linker is to run through all the modules in a file, posting > : MOD_QUIESCE followed by MOD_UNLOAD on each module serially. Thus, if you > : have multiple modules in a single kld and one of the modules veto's an unload > : request via MOD_QUIESCE, you don't know as the module author if any of your > : modules were unloaded via MOD_UNLOAD or not. I think a better approach would > : be to change the kernel linker to invoke MOD_QUIESCE on all modules in a > : single pass first. If none of those fail (or it's a forced unload), then it > : can do a second pass invoking MOD_UNLOAD on all the modules. > > That sounds great to me. I'm a bit surprised it is implemented the > way you say... me++ > > Warner > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Mon Aug 11 11:06:54 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFB5D1065682 for ; Mon, 11 Aug 2008 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C10158FC26 for ; Mon, 11 Aug 2008 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7BB6stg047136 for ; Mon, 11 Aug 2008 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7BB6sSD047132 for freebsd-arch@FreeBSD.org; Mon, 11 Aug 2008 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Aug 2008 11:06:54 GMT Message-Id: <200808111106.m7BB6sSD047132@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org 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 Aug 2008 11:06:55 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon Aug 11 15:44:56 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61CE21065675 for ; Mon, 11 Aug 2008 15:44:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D82D48FC2A for ; Mon, 11 Aug 2008 15:44:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7BFhtSJ064616; Mon, 11 Aug 2008 11:44:08 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Mon, 11 Aug 2008 11:43:49 -0400 User-Agent: KMail/1.9.7 References: <200808091637.33820.jhb@freebsd.org> <20080810.165333.232928772.imp@bsdimp.com> In-Reply-To: <20080810.165333.232928772.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200808111143.50023.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 11 Aug 2008 11:44:08 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8007/Mon Aug 11 09:51:54 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org Subject: Re: Make MOD_QUIESCE a bit more useful.. 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 Aug 2008 15:44:56 -0000 On Sunday 10 August 2008 06:53:33 pm M. Warner Losh wrote: > In message: <200808091637.33820.jhb@freebsd.org> > John Baldwin writes: > : So currently the MOD_QUIESCE event is posted to a module when unloading a kld > : so it can veto non-forced unloads. However, the current implementation in > : the kernel linker is to run through all the modules in a file, posting > : MOD_QUIESCE followed by MOD_UNLOAD on each module serially. Thus, if you > : have multiple modules in a single kld and one of the modules veto's an unload > : request via MOD_QUIESCE, you don't know as the module author if any of your > : modules were unloaded via MOD_UNLOAD or not. I think a better approach would > : be to change the kernel linker to invoke MOD_QUIESCE on all modules in a > : single pass first. If none of those fail (or it's a forced unload), then it > : can do a second pass invoking MOD_UNLOAD on all the modules. > > That sounds great to me. I'm a bit surprised it is implemented the > way you say... So was I. What happens now is that the kernel linker does a for loop over all the modules calling 'module_unload()'. module_unload() invokes both MOD_QUIESCE and MOD_UNLOAD back to back. Hmm, so fixing this brings up one extra note: Do we need a new module event (say MOD_UNLOAD_ABORTED, MOD_AWAKEN, or MOD_DEQUIESCE) that would get invoked when a kldunload is veto'd by a MOD_QUIESCE event that would get posted to all the modules that had successfully QUIESCED so far? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Aug 11 18:28:18 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72F6C1065681 for ; Mon, 11 Aug 2008 18:28:18 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from luidgi.portaone.com (luidgi.portaone.com [195.138.219.143]) by mx1.freebsd.org (Postfix) with ESMTP id 549DA8FC16 for ; Mon, 11 Aug 2008 18:28:18 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from mail.pbxpress.com ([65.61.203.142] helo=leaf.pbxpress.com) by luidgi.portaone.com (8.11.3/8.11.3) with ESMTP (TLSv1:AES256-SHA:256)id 1KSc7t-00016d-F3; Mon, 11 Aug 2008 11:28:17 -0700 Received: from jeeves.bluezbox.com (k3-gw.portaone.com [193.28.87.193]) (authenticated bits=0) by leaf.pbxpress.com (8.13.3/8.13.3) with ESMTP id m7BIVJbY040180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 11:31:26 -0700 (PDT) (envelope-from gonzo@freebsd.org) Message-ID: <48A084C0.4040105@freebsd.org> Date: Mon, 11 Aug 2008 21:28:16 +0300 From: Oleksandr Tymoshenko User-Agent: Thunderbird 2.0.0.14 (X11/20080704) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <20080729.161303.709402272.imp@bsdimp.com> <86r69buar0.fsf@ds4.des.no> <489B08F6.8060605@freebsd.org> <867iasfmrh.fsf@ds4.des.no> <489EDD2F.9080302@freebsd.org> <86myjkbnky.fsf@ds4.des.no> In-Reply-To: <86myjkbnky.fsf@ds4.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, recieved from trusted server Cc: arch@freebsd.org Subject: Re: Need a code review 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 Aug 2008 18:28:18 -0000 Dag-Erling Smørgrav wrote: > Oleksandr Tymoshenko writes: >> Here is new fix: http://people.freebsd.org/~gonzo/mips2/libpam2.diff >> The idea is to set define explicitly for dynamic case rather then rely >> on __PIC__. > > This is completely backwards. Dynamic is the default option, and in > fact the only supported option on many (non-FreeBSD) systems. If it > were up to me, I would remove support for statically linked modules > entirely. OK, so the static case is the one to be marked explicitly. Here is the next patch: http://people.freebsd.org/~gonzo/mips2/libpam3.diff Drop NO_STATIC_MODULES since it's a default and add PAM_STATIC_MODULES to request static modules build. -- gonzo From owner-freebsd-arch@FreeBSD.ORG Tue Aug 12 01:20:07 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CADB1065672 for ; Tue, 12 Aug 2008 01:20:07 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 92E148FC0A for ; Tue, 12 Aug 2008 01:20:06 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl107-230.kln.forthnet.gr [77.49.226.230]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id m7C1Jejh020200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Aug 2008 04:19:56 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m7C1JZeO085211; Tue, 12 Aug 2008 04:19:35 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m7C1JQZY085210; Tue, 12 Aug 2008 04:19:26 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Oleksandr Tymoshenko References: <20080729.161303.709402272.imp@bsdimp.com> <86r69buar0.fsf@ds4.des.no> <489B08F6.8060605@freebsd.org> <867iasfmrh.fsf@ds4.des.no> <489EDD2F.9080302@freebsd.org> <86myjkbnky.fsf@ds4.des.no> <48A084C0.4040105@freebsd.org> Date: Tue, 12 Aug 2008 04:19:24 +0300 In-Reply-To: <48A084C0.4040105@freebsd.org> (Oleksandr Tymoshenko's message of "Mon, 11 Aug 2008 21:28:16 +0300") Message-ID: <874p5rt4gz.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MailScanner-ID: m7C1Jejh020200 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.823, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.58, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , arch@freebsd.org Subject: Re: Need a code review 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 Aug 2008 01:20:07 -0000 On Mon, 11 Aug 2008 21:28:16 +0300, Oleksandr Tymoshenko wrote: > Dag-Erling Sm=F8rgrav wrote: >> Oleksandr Tymoshenko writes: >>> Here is new fix: http://people.freebsd.org/~gonzo/mips2/libpam2.diff >>> The idea is to set define explicitly for dynamic case rather then rely >>> on __PIC__. >> >> This is completely backwards. Dynamic is the default option, and in >> fact the only supported option on many (non-FreeBSD) systems. If it >> were up to me, I would remove support for statically linked modules >> entirely. > > OK, so the static case is the one to be marked explicitly. Here is the > next patch: http://people.freebsd.org/~gonzo/mips2/libpam3.diff Drop > NO_STATIC_MODULES since it's a default and add PAM_STATIC_MODULES to > request static modules build. IMHO, since the #ifdef'ed part in openpam.h mentions "gcc static linking", it would probably be nice to keep the __GNUC__ part in -#if defined(__GNUC__) && !defined(__PIC__) && !defined(NO_STATIC_MODULES) +#if defined(PAM_STATIC_MODULES) /* gcc, static linking */ and write it as -#if defined(__GNUC__) && !defined(__PIC__) && !defined(NO_STATIC_MODULES) +#if defined(__GNUC__) && defined(PAM_STATIC_MODULES) /* gcc, static linking */ From owner-freebsd-arch@FreeBSD.ORG Wed Aug 13 14:45:26 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 341041065683; Wed, 13 Aug 2008 14:45:26 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id B48158FC21; Wed, 13 Aug 2008 14:45:25 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) id <0K5J00B0AKVOWU00@smtpauth2.wiscmail.wisc.edu>; Wed, 13 Aug 2008 08:45:24 -0500 (CDT) Received: from trantor.tachypleus.net (adsl-75-42-235-192.dsl.mdsnwi.sbcglobal.net [75.42.235.192]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K5J00M9BKVJJH80@smtpauth2.wiscmail.wisc.edu>; Wed, 13 Aug 2008 08:45:20 -0500 (CDT) Date: Wed, 13 Aug 2008 08:48:26 -0500 From: Nathan Whitehorn In-reply-to: <200808051024.27043.jhb@freebsd.org> To: John Baldwin Message-id: <48A2E62A.9060604@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=75.42.235.192 X-Spam-PmxInfo: Server=avs-9, Version=5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.8.13.132817, SenderIP=75.42.235.192 References: <48981C19.8060009@freebsd.org> <200808051024.27043.jhb@freebsd.org> User-Agent: Thunderbird 2.0.0.14 (X11/20080628) Cc: freebsd-arch@freebsd.org Subject: Re: UMA MD Small Allocator Runtime Switching 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 Aug 2008 14:45:26 -0000 John Baldwin wrote: > On Tuesday 05 August 2008 05:23:37 am Nathan Whitehorn wrote: >> I'm working on the PowerPC G5 port right now, and have run into a >> problem with the way the UMA small allocator works. On G3/G4 systems, >> there is a direct physical->virtual mapping, and on G5s there isn't. All >> of the infrastructure is in place to support both types of system with a >> single kernel image, except that UMA_MD_SMALL_ALLOC must be switched >> on/off at runtime. >> >> One solution is to put if (direct_map) use_nonsmall_case() into the MD >> small_alloc/free() routines and define UMA_MD_SMALL_ALLOC everywhere. >> This works well, except that the MI UMA code then sets booted = 1 too >> early in the boot process, before the kmem_alloc*() routines are available. >> >> Basically, I need to find a way have an MD UMA allocator without the MI >> UMA code assuming anything about how it works internally. Maybe adding a >> UMA_MD_ALLOC_LATE define to prevent setting booted=1 early on? >> -Nathan > > Have you considered creating an artificial direct map region in the address > space on the G5? Some of the other 64-bit ports (amd64 and sparc64) do this > to gain the benefits of the direct map even though it isn't a mandated part > of the architecture like it is on some other platforms (alpha and mips). I thought about it, but we can only use 4K pages on the G5 so this would put a large amount of pressure on the page table. IBM removed the block translation mechanism from the G5 and the CPU's superpage support is not available in the 32-bit compatibility mode under which we currently run. -Nathan From owner-freebsd-arch@FreeBSD.ORG Wed Aug 13 16:59:52 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71DC9106566B; Wed, 13 Aug 2008 16:59:52 +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 540CF8FC08; Wed, 13 Aug 2008 16:59:52 +0000 (UTC) (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 A126746BB4; Wed, 13 Aug 2008 12:59:51 -0400 (EDT) Date: Wed, 13 Aug 2008 17:59:51 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: arch@FreeBSD.org Subject: Advanced warning: virtualization work will be afoot 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 Aug 2008 16:59:52 -0000 Dear all: This weekend is the FreeBSD Developer Summit in Cambridge, UK, and one of the focuses of the meetings will be the on-going network stack virtualization. We hope to have several days in a row to focus on known issues, understand (and possible address) various concerns about the approach, and possibly expand the focus to further subsystems. We also hope to explore doing some amount of virtualization below the language level, and hopefully have the right set of people there to talk about that. With all this in mind, it may well be that we begin some of the heavy lifting on virtualization in the base Subversion tree, whereas to date this work has occurred almost entirely in Perforce. The outcome of the meetings will depend a lot on what we find and what progress we make, so this isn't exactly a "HEADS UP: Virtualization going into SVN", but it could well be that there is quite a bit of committing going on. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Wed Aug 13 17:21:37 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0F591065673; Wed, 13 Aug 2008 17:21:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id EF7898FC14; Wed, 13 Aug 2008 17:21:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7DHLNUi094237; Wed, 13 Aug 2008 13:21:30 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Nathan Whitehorn Date: Wed, 13 Aug 2008 12:14:43 -0400 User-Agent: KMail/1.9.7 References: <48981C19.8060009@freebsd.org> <200808051024.27043.jhb@freebsd.org> <48A2E62A.9060604@freebsd.org> In-Reply-To: <48A2E62A.9060604@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808131214.43326.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 13 Aug 2008 13:21:30 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8026/Wed Aug 13 09:03:11 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS 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: UMA MD Small Allocator Runtime Switching 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 Aug 2008 17:21:37 -0000 On Wednesday 13 August 2008 09:48:26 am Nathan Whitehorn wrote: > John Baldwin wrote: > > On Tuesday 05 August 2008 05:23:37 am Nathan Whitehorn wrote: > >> I'm working on the PowerPC G5 port right now, and have run into a > >> problem with the way the UMA small allocator works. On G3/G4 systems, > >> there is a direct physical->virtual mapping, and on G5s there isn't. All > >> of the infrastructure is in place to support both types of system with a > >> single kernel image, except that UMA_MD_SMALL_ALLOC must be switched > >> on/off at runtime. > >> > >> One solution is to put if (direct_map) use_nonsmall_case() into the MD > >> small_alloc/free() routines and define UMA_MD_SMALL_ALLOC everywhere. > >> This works well, except that the MI UMA code then sets booted = 1 too > >> early in the boot process, before the kmem_alloc*() routines are available. > >> > >> Basically, I need to find a way have an MD UMA allocator without the MI > >> UMA code assuming anything about how it works internally. Maybe adding a > >> UMA_MD_ALLOC_LATE define to prevent setting booted=1 early on? > >> -Nathan > > > > Have you considered creating an artificial direct map region in the address > > space on the G5? Some of the other 64-bit ports (amd64 and sparc64) do this > > to gain the benefits of the direct map even though it isn't a mandated part > > of the architecture like it is on some other platforms (alpha and mips). > > I thought about it, but we can only use 4K pages on the G5 so this would > put a large amount of pressure on the page table. IBM removed the block > translation mechanism from the G5 and the CPU's superpage support is not > available in the 32-bit compatibility mode under which we currently run. Hmm, I didn't know you weren't running in full 64-bit mode. Is that a property of the G5 CPU that it only supports the 32-bit compat mode with 64-bit extensions? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Aug 13 17:36:25 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B217106564A for ; Wed, 13 Aug 2008 17:36:25 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (ice.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id CAB088FC14 for ; Wed, 13 Aug 2008 17:36:24 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id EC46086CB1; Wed, 13 Aug 2008 12:36:23 -0500 (CDT) Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (ice.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 08558-02; Wed, 13 Aug 2008 12:36:23 -0500 (CDT) Received: from wanderer.tachypleus.net (i3-dhcp-172-16-223-165.icecube.wisc.edu [172.16.223.165]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 426D686B19; Wed, 13 Aug 2008 12:36:23 -0500 (CDT) Message-ID: <48A31B9A.6040705@freebsd.org> Date: Wed, 13 Aug 2008 19:36:26 +0200 From: Nathan Whitehorn User-Agent: Thunderbird 2.0.0.16 (X11/20080804) MIME-Version: 1.0 To: John Baldwin References: <48981C19.8060009@freebsd.org> <200808051024.27043.jhb@freebsd.org> <48A2E62A.9060604@freebsd.org> <200808131214.43326.jhb@freebsd.org> In-Reply-To: <200808131214.43326.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at ice.icecube.wisc.edu Cc: freebsd-arch@freebsd.org Subject: Re: UMA MD Small Allocator Runtime Switching 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 Aug 2008 17:36:25 -0000 John Baldwin wrote: > > [snipped bit about faking a direct map] >> I thought about it, but we can only use 4K pages on the G5 so this would >> put a large amount of pressure on the page table. IBM removed the block >> translation mechanism from the G5 and the CPU's superpage support is not >> available in the 32-bit compatibility mode under which we currently run. >> > > Hmm, I didn't know you weren't running in full 64-bit mode. Is that a > property of the G5 CPU that it only supports the 32-bit compat mode with > 64-bit extensions? > No, it supports full 64-bit mode as well, and likes that much better. In fact, you have to do a fair bit of work to keep it in the compatibility mode: it switches to the full 64-bit mode whenever it takes a trap, for instance. The initial porting target is the compatibility mode because (a) I'm lazy and didn't want to simultaneously do a brand new 64-bit port and deal with changes for the G5 and (b) it would be nice to have a single 32-bit PPC install CD that works on all machines with 32-bit operating system support. It's the trying to avoid any #ifdef G5 that creates this problem with the UMA allocator. I'm gotten this completely working using a bunch of dynamic switching stuff (I can boot multiuser and build world on both my G3 and G5 machine with the same kernel), but to do it I need to remove where it sets booted = 1 as an optimization when the MI UMA subsystem is initializing. -Nathan From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 13:05:19 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00641106564A; Fri, 15 Aug 2008 13:05:18 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 981338FC1B; Fri, 15 Aug 2008 13:05:18 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 3B0A8744248; Fri, 15 Aug 2008 15:48:29 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM7H0tuh+l1S; Fri, 15 Aug 2008 15:48:29 +0300 (EEST) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [91.198.50.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 9B4A27441EC; Fri, 15 Aug 2008 15:48:28 +0300 (EEST) Message-ID: <48A57B1B.4000903@icyb.net.ua> Date: Fri, 15 Aug 2008 15:48:27 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.16 (X11/20080805) MIME-Version: 1.0 To: Rui Paulo References: <48A300B9.5090105@icyb.net.ua> <20080813162931.GC718@epsilon.local> In-Reply-To: <20080813162931.GC718@epsilon.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-arch@freebsd.org Subject: Re: tilt/horizontal scroll support 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 Aug 2008 13:05:19 -0000 on 13/08/2008 19:29 Rui Paulo said the following: > > Well, perhaps the best way is to teach sysmouse about horizontal scrolling > and then add a quirk WRT your mouse ? > > sysmouse(4) really needs to grow horizontal scrolling since nowadays every > mouse has it. Rui, I agree, this would be a perfect solution. What scares me is backward compatibility. I think that I do not understand how to do it right. So that older userland software works with newer kernels and newer userland works with older kernels. As I understand there are interfaces of hardware mouse drivers, then there is moused, then there is sysmouse interface and then there are user applications like X server. Knowledge of horizontal scrolling needs to be added to all components in the chain and it is better be done in backward-compatible fashion. And I really do not know to do this properly. Would it be just adding some new bytes to the protocol or growing a new protocol (level) or something else... P.S. I replaced usb ml with arch@ in cc. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 14:25:51 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3818106567F; Fri, 15 Aug 2008 14:25:51 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 66B8D8FC0A; Fri, 15 Aug 2008 14:25:51 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 42F91158B2D; Fri, 15 Aug 2008 10:09:55 -0400 (EDT) Received: from web6.messagingengine.com ([10.202.2.215]) by compute2.internal (MEProxy); Fri, 15 Aug 2008 10:09:55 -0400 Received: by web6.messagingengine.com (Postfix, from userid 99) id 2424F7453F; Fri, 15 Aug 2008 10:09:54 -0400 (EDT) Message-Id: <1218809394.10612.1268815905@webmail.messagingengine.com> X-Sasl-Enc: yxJT5xInxqlYrTbjB+mKOJcp2us/6NFDy8EGjlHVnPc2 1218809394 From: "Darren Reed" To: "Robert Watson" , current@FreeBSD.org Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface References: In-Reply-To: Date: Fri, 15 Aug 2008 16:09:54 +0200 Cc: arch@FreeBSD.org Subject: Re: Advanced warning: virtualization work will be afoot X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: darrenr@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2008 14:25:51 -0000 Robert, Do you have any more information about what the details of this virtualization work will be? e.g. will it be similar to what Solaris has with zones? The reason that I ask is that I've just finished getting the ipfilter code (non-Sun code) converted to being zone aware. What does that mean? Lots of global variables are gone, replaced by soft-context structures that are allocated and free'd when zones come alive/die. For BSD, while all of the code paths are the same, I'm currently only using a single soft context and just pass around a pointer to it. If you're going to be doing similar work for FreeBSD, I will try and get this into the tree sooner, rather than later, so that there's one less component that you need to worry about. Cheers, Darren -- Darren Reed darrenr@fastmail.net From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 15:43:10 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 544A71065676; Fri, 15 Aug 2008 15:43:10 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0117C8FC15; Fri, 15 Aug 2008 15:43:09 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 22AE5207F; Fri, 15 Aug 2008 17:43:09 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 086B3844A8; Fri, 15 Aug 2008 17:43:09 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: darrenr@freebsd.org References: <1218809394.10612.1268815905@webmail.messagingengine.com> Date: Fri, 15 Aug 2008 17:43:08 +0200 In-Reply-To: <1218809394.10612.1268815905@webmail.messagingengine.com> (Darren Reed's message of "Fri, 15 Aug 2008 16:09:54 +0200") Message-ID: <86fxp6wagj.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@FreeBSD.org, Robert Watson , current@FreeBSD.org Subject: Re: Advanced warning: virtualization work will be afoot 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 Aug 2008 15:43:10 -0000 "Darren Reed" writes: > Do you have any more information about what the details of this > virtualization work will be? This has been discussed extensively on various mailing lists and at various BSD conferences over the past ~5 years. Search the archives for "vimage". DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 15:55:36 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBDE2106566B; Fri, 15 Aug 2008 15:55:36 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 591E78FC0A; Fri, 15 Aug 2008 15:55:36 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A558C1.dip.t-dialin.net [84.165.88.193]) by redbull.bpaserver.net (Postfix) with ESMTP id 97AA82E06D; Fri, 15 Aug 2008 17:30:34 +0200 (CEST) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id 3218D7099A; Fri, 15 Aug 2008 17:30:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1218814230; bh=FDWbE/6TSuPv3VTq7LHb+d+cogyA4pszx ysy+UDK9CQ=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To: References:Mime-Version:Content-Type:Content-Transfer-Encoding; b=ITm3HdHBpTTNn8Ppov4oDARmHs6iwbumY5ZqiUQGhv3lYHrleCLTCwn8gRdiG1G++ /QDIEzCuHtqboCRs/TlWFbepQ7KkX9IyTueGsTLtNpu1mWEC5gucRxGKTZmnyiBK8yi VWJ3TG2Hi/LoLNFv1PegKtltgCqDnxKD8hnhDwc1ECrxknzQ0RrLKqB05JG11X4Ll60 xq/D7DLuJGlFbMDaJ1xgbXb/z704XKjuv6MjsbScMECQqUK8Hg7px5dkQmIveS0XXOR ctE3f2uCkeKOR0xRRBe2UGiaGqU0luEzsDeyr6XTlTr1l7REIV/98w8a9AVZucJZXfi th7LOstYg== Date: Fri, 15 Aug 2008 17:30:29 +0200 From: Alexander Leidinger To: darrenr@freebsd.org Message-ID: <20080815173029.4a9a9f59@deskjail> In-Reply-To: <1218809394.10612.1268815905@webmail.messagingengine.com> References: <1218809394.10612.1268815905@webmail.messagingengine.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i686-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 97AA82E06D.5BB45 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.9, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: arch@FreeBSD.org, Robert Watson , current@FreeBSD.org Subject: Re: Advanced warning: virtualization work will be afoot 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 Aug 2008 15:55:36 -0000 Quoting "Darren Reed" (Fri, 15 Aug 2008 16:09:54 +0200): > Robert, > > Do you have any more information about what the details of > this virtualization work will be? e.g. will it be similar > to what Solaris has with zones? It's like the Solaris Crossbow project. Virtual network stacks. I don't know if you refer to this or to the normal operation of zones since Solaris 10. The later one we will get for jails too, but this is just a side effect (sort of, there are patches floating around to get multi-IPs into jails in a different way before the VNET stuff, so that we can have the multi-IPS for jails in 7.x too). Bye, Alexander. -- "Planet Express: our crew is replaceable, your package isn't." -Advertisement http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 16:10:41 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 000841065678 for ; Fri, 15 Aug 2008 16:10:40 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 38EBE8FC0A for ; Fri, 15 Aug 2008 16:10:40 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1653123fgb.35 for ; Fri, 15 Aug 2008 09:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=FVgdCEjj3pybjjqJ34y39x9UyI3F0d5Cbrrxuo479Mw=; b=IS1kuqvho+gpqMBP2SGchzOkyKD4YwwO7PaGqZE2qjfroCP95hWVvr6/deot6GgJ3U FRXGnAWCgGhB0f62nA6CqDHTkimDAe5wdMLdRDpEVp0GdTI6r73q+ccoPRVbQENI4i8v cUjkyIfJrZCYh0ZMdXg6hiPieDqtzrm4Y7N3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=nqUpd0loukLOM5ZdN8PCzeKmkZ0zyAGbPiCu5RD3qS+jUyKq3aosK+LjZ0xHfYXqC1 eQ+sV1tnPFtcGRBJz5tvZXFJ43sENA5j+KgQOuIE4WXmH3e8D27mGrzWPPDSx1PRbhk9 YCVJ7pCcYO7fpbCheYmVHvoEaX6cR9C+yUOws= Received: by 10.86.28.2 with SMTP id b2mr2057344fgb.31.1218814923779; Fri, 15 Aug 2008 08:42:03 -0700 (PDT) Received: by 10.86.78.14 with HTTP; Fri, 15 Aug 2008 08:42:03 -0700 (PDT) Message-ID: <3bbf2fe10808150842mf8ab204u5a5ef13b894e32e2@mail.gmail.com> Date: Fri, 15 Aug 2008 17:42:03 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 9c284c7781802333 Cc: Jeff Roberson Subject: [PATCH] Deadlock detection on production environments 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 Aug 2008 16:10:41 -0000 Below is reported a patch which should identify deadlocks (or, better, a class of them) in system thought to run in production environments (so with no addictional overhead or no addictional debugging options like WITNESS). The main idea is to check for times spent by threads sleeping on a sleepqueue or blocking on a turnstile. If these times exceed an exagerated threshold, we can say the threads deadlocked. This seems a very effective way of identify deadlocks in particular if considering the following things: - LOR can happen only between locks within the same class (for example, sleepqueued locks (sx, lockmgr), turnstiled locks (mtx, rwlock) and spinlocks). - spinlocks alredy have a way to identify deadlocks between eachother. As scanning all the threads in the system is an operation which requires some locking, the operation is deferred into a specific context, the "deadlock resolver" which will periodically (with 1 second interval) check for sleep times and block times of any thread and it will report threshold exceedings. In order to implement this idea I had to fill some gaps in the basic support. For example, sleep ticks were saved once the thread was entering the sleepqueue, but blocking ticks weren't in the turnstiles. In order to cope with this, in the patch turnstiles save / clean the block times. There were no way to differentiate a thread sleeping on a sleepqueue linked to a lock or a waitchannel (msleep, condvar, etc.). In order to cope with this, I added sleepq_type() which returns the type of the waitchannel. The implementation has been pretty much straightforward if not for a LOR which was present between the threadlock and the sleepq_type(). Now it should be solved. Note that actually the default threshold is 30 min for sleepqueues and 15 mins for turnstiles. This approach doesn't solve all kind of deadlocks. For example, it won't solve the problem of missed wakeups on a waitchannel. Theoretically, we could check for sleepqueue linked to a waitchannel too, but it would not be simple to differentiate between a volountary, long, sleeping (ie: users input waiting) and a deadlock. If you have good ideas about it, please let me know. A case where this approach will lead to a false positive is the case of bugged code. For example, if a thread owns a sxlock and then performs a very long sleep on a waitchannel (for example, the users input waiting) with the sx held. In this case, the lock should be dropped before to perform the sleeping and there is no way to cope with badly written code. Also we should cope with the general ticks counter overflowing. What if ticks counter overflows? it is right we should add heuristic in order to identify such case and workaround it? For the moment I left it out. The final concern is about a possible deadlock for the thread lock resolver when acquiring the allproc_lock. The solution for this should be mainly MD, I guess, and it should involve the NMI (or a relative concept for architectures different from IA32). On ia32 systems, for example, we could use a NMI handler, linked to a watchdog, performing appropriate checks on the resolver runtimes, in order to verify that it didn't break out. The patch has been reviewed and discussed by jeff@ and has been developed on the behalf of Nokia. Thanks, Attilio ================================== --- /usr/src/sys/kern/kern_clock.c 2008-05-31 23:42:15.000000000 +0200 +++ src/sys/kern/kern_clock.c 2008-08-15 15:34:51.000000000 +0200 @@ -48,14 +48,16 @@ #include #include #include -#include +#include #include +#include #include #include #include #include #include #include +#include #include #include #include @@ -159,6 +161,117 @@ SYSCTL_PROC(_kern, OID_AUTO, cp_times, CTLTYPE_LONG|CTLFLAG_RD, 0,0, sysctl_kern_cp_times, "LU", "per-CPU time statistics"); +static int slptime_threshold = 1800; +static int blktime_threshold = 900; + +static void +deadlkres(void) +{ + struct proc *p; + struct thread *td; + void *wchan; + int blkticks, slpticks, slptype, tticks; + + for (;;) { + blkticks = blktime_threshold * hz; + slpticks = slptime_threshold * hz; + sx_slock(&allproc_lock); + FOREACH_PROC_IN_SYSTEM(p) { + PROC_SLOCK(p); + FOREACH_THREAD_IN_PROC(p, td) { + thread_lock(td); + if (TD_ON_LOCK(td)) { + + /* + * The thread should be blocked on a + * turnstile, so just check if the + * turnstile channel is in good state. + */ + MPASS(td->td_blocked != NULL); + tticks = ticks - td->td_blktick; + if (tticks > blkticks) { + + /* + * A thread stuck for too long + * on a turnstile. Act as + * appropriate. + */ + thread_unlock(td); + PROC_SUNLOCK(p); + sx_sunlock(&allproc_lock); + panic("%s: deadlock detected for %p, blocked for %d ticks\n", + __func__, td, tticks); + } + } else if (TD_ON_SLEEPQ(td)) { + + /* + * Check if the thread is sleeping + * on a lock, otherwise skip the check. + * Drop the thread lock in order to + * avoid a LOR with sq_chain spinlock. + * Note that the proc spinlock will + * prevent the thread from exiting. + */ + wchan = td->td_wchan; + thread_unlock(td); + slptype = sleepq_type(wchan); + thread_lock(td); + + /* + * Check if we lost the race for + * accessing again the thread. + */ + if (!TD_ON_SLEEPQ(td) || + wchan != td->td_wchan || + slptype == -1) { + thread_unlock(td); + continue; + } + tticks = ticks - td->td_slptick; + if ((slptype == SLEEPQ_SX || + slptype == SLEEPQ_LK) && + tticks > slpticks) { + + /* + * A thread stuck for too long + * on a sleepqueue linked to + * a lock. Act as appropriate. + */ + thread_unlock(td); + PROC_SUNLOCK(p); + sx_sunlock(&allproc_lock); + panic("%s: deadlock detected for %p, blocked for %d ticks\n", + __func__, td, tticks); + } + } + thread_unlock(td); + } + PROC_SUNLOCK(p); + } + sx_sunlock(&allproc_lock); + + /* + * Sleep for one second, than try again to find deadlocks. + */ + pause("deadlkres", 1 * hz); + } +} + +static struct kthread_desc deadlkres_kd = { + "deadlkres", + deadlkres, + (struct thread **)NULL +}; +SYSINIT(deadlkres, SI_SUB_CLOCKS, SI_ORDER_ANY, kthread_start, &deadlkres_kd); + +SYSCTL_NODE(_debug, OID_AUTO, deadlock, CTLFLAG_RW, 0, "Deadlock detection"); +SYSCTL_INT(_debug_deadlock, OID_AUTO, slptime_threshold, CTLFLAG_RW, + &slptime_threshold, 0, + "Number of seconds within is valid to sleep on a sleepqueue"); +SYSCTL_INT(_debug_deadlock, OID_AUTO, blktime_threshold, CTLFLAG_RW, + &blktime_threshold, 0, + "Number of seconds within is valid to block on a turnstile"); + void read_cpu_time(long *cp_time) { --- /usr/src/sys/kern/subr_sleepqueue.c 2008-08-13 18:41:11.000000000 +0200 +++ src/sys/kern/subr_sleepqueue.c 2008-08-15 15:30:10.000000000 +0200 @@ -121,8 +121,8 @@ LIST_ENTRY(sleepqueue) sq_hash; /* (c) Chain and free list. */ LIST_HEAD(, sleepqueue) sq_free; /* (c) Free queues. */ void *sq_wchan; /* (c) Wait channel. */ -#ifdef INVARIANTS int sq_type; /* (c) Queue type. */ +#ifdef INVARIANTS struct lock_object *sq_lock; /* (c) Associated lock. */ #endif }; @@ -313,7 +313,6 @@ ("thread's sleep queue has a non-empty free list")); KASSERT(sq->sq_wchan == NULL, ("stale sq_wchan pointer")); sq->sq_lock = lock; - sq->sq_type = flags & SLEEPQ_TYPE; #endif #ifdef SLEEPQUEUE_PROFILING sc->sc_depth++; @@ -326,6 +325,7 @@ sq = td->td_sleepqueue; LIST_INSERT_HEAD(&sc->sc_queues, sq, sq_hash); sq->sq_wchan = wchan; + sq->sq_type = flags & SLEEPQ_TYPE; } else { MPASS(wchan == sq->sq_wchan); MPASS(lock == sq->sq_lock); @@ -644,6 +644,29 @@ } /* + * Returns the type of sleepqueue given a waitchannel. + */ +int +sleepq_type(void *wchan) +{ + struct sleepqueue *sq; + int type; + + MPASS(wchan != NULL); + + sleepq_lock(wchan); + sq = sleepq_lookup(wchan); + if (sq == NULL) { + sleepq_release(wchan); + return (-1); + } + type = sq->sq_type; + sleepq_release(wchan); + + return (type); +} + +/* * Removes a thread from a sleep queue and makes it * runnable. */ @@ -1144,8 +1167,8 @@ return; found: db_printf("Wait channel: %p\n", sq->sq_wchan); -#ifdef INVARIANTS db_printf("Queue type: %d\n", sq->sq_type); +#ifdef INVARIANTS if (sq->sq_lock) { lock = sq->sq_lock; db_printf("Associated Interlock: %p - (%s) %s\n", lock, --- /usr/src/sys/kern/subr_turnstile.c 2008-05-31 23:42:15.000000000 +0200 +++ src/sys/kern/subr_turnstile.c 2008-08-15 15:30:10.000000000 +0200 @@ -732,6 +732,7 @@ td->td_tsqueue = queue; td->td_blocked = ts; td->td_lockname = lock->lo_name; + td->td_blktick = ticks; TD_SET_LOCK(td); mtx_unlock_spin(&tc->tc_lock); propagate_priority(td); @@ -924,6 +925,7 @@ MPASS(TD_CAN_RUN(td)); td->td_blocked = NULL; td->td_lockname = NULL; + td->td_blktick = 0; #ifdef INVARIANTS td->td_tsqueue = 0xff; #endif --- /usr/src/sys/sys/proc.h 2008-08-13 18:42:06.000000000 +0200 +++ src/sys/sys/proc.h 2008-08-15 15:30:10.000000000 +0200 @@ -213,6 +213,7 @@ struct ucred *td_ucred; /* (k) Reference to credentials. */ u_int td_estcpu; /* (t) estimated cpu utilization */ u_int td_slptick; /* (t) Time at sleep. */ + u_int td_blktick; /* (t) Time spent blocked. */ struct rusage td_ru; /* (t) rusage information */ uint64_t td_incruntime; /* (t) Cpu ticks to transfer to proc. */ uint64_t td_runtime; /* (t) How many cpu ticks we've run. */ --- /usr/src/sys/sys/sleepqueue.h 2008-08-13 18:42:06.000000000 +0200 +++ src/sys/sys/sleepqueue.h 2008-08-15 15:30:10.000000000 +0200 @@ -109,6 +109,7 @@ void sleepq_set_timeout(void *wchan, int timo); int sleepq_timedwait(void *wchan, int pri); int sleepq_timedwait_sig(void *wchan, int pri); +int sleepq_type(void *wchan); void sleepq_wait(void *wchan, int pri); int sleepq_wait_sig(void *wchan, int pri); From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 16:50:22 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE9781065675; Fri, 15 Aug 2008 16:50:22 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 6A7CF8FC16; Fri, 15 Aug 2008 16:50:22 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id B6C8A2090; Fri, 15 Aug 2008 18:50:21 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 9AA87844A8; Fri, 15 Aug 2008 18:50:21 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sam Fourman Jr." References: <1218809394.10612.1268815905@webmail.messagingengine.com> <86fxp6wagj.fsf@ds4.des.no> <11167f520808150930h7b1e307eu8b7f5032d177fcbe@mail.gmail.com> Date: Fri, 15 Aug 2008 18:50:21 +0200 In-Reply-To: <11167f520808150930h7b1e307eu8b7f5032d177fcbe@mail.gmail.com> (Sam Fourman, Jr.'s message of "Fri, 15 Aug 2008 11:30:28 -0500") Message-ID: <86y72yuss2.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: darrenr@freebsd.org, arch@freebsd.org, Robert Watson , current@freebsd.org Subject: Re: Advanced warning: virtualization work will be afoot 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 Aug 2008 16:50:22 -0000 "Sam Fourman Jr." writes: > I am confused, is vimage actually in -CURRENT now? my guess is no > because there is no man page No, this is why Robert was saying we were going to work on it this weekend. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 16:56:32 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D3F2106564A for ; Fri, 15 Aug 2008 16:56:32 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id F3F2E8FC0C for ; Fri, 15 Aug 2008 16:56:31 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1627741rvf.43 for ; Fri, 15 Aug 2008 09:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=cCcMxzuvFW/4KhnV8Ze3jBLW+bvTa07+qeU/1Sigows=; b=f44KvcmvK3xBgw6aywhnp2tTY1xEgKfBdsHeB3X668xzNI0PLDsOjYvua47BOIT0gH WcwY4o+y2NXqQCr4MkOg+ZXcb234bFJosuF8lYL67wuJV7/x31kRmBOjoDAjg9t8qExL yzlcjZkaCPvJsREn6ZPzFMX+0GOJn5Eg0Y+bE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=wfYsYnVwH6JDt94XW9TrSWOqF+9ihWzCnODoS26RoGOtpj9OmzG26ez+nfQq5nwvmi 3KxD62ZEeTCs5kEViwB6JKnx4qOZFVPAdWUIu9IpoDOBQEAamleNUD769cpIgrkJ6CHS ge2Lg7eSx5gzgdGCZaOivOMpufPTgUeBWcnUc= Received: by 10.141.170.10 with SMTP id x10mr1622937rvo.140.1218817828672; Fri, 15 Aug 2008 09:30:28 -0700 (PDT) Received: by 10.141.186.2 with HTTP; Fri, 15 Aug 2008 09:30:28 -0700 (PDT) Message-ID: <11167f520808150930h7b1e307eu8b7f5032d177fcbe@mail.gmail.com> Date: Fri, 15 Aug 2008 11:30:28 -0500 From: "Sam Fourman Jr." To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86fxp6wagj.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1218809394.10612.1268815905@webmail.messagingengine.com> <86fxp6wagj.fsf@ds4.des.no> Cc: darrenr@freebsd.org, arch@freebsd.org, Robert Watson , current@freebsd.org Subject: Re: Advanced warning: virtualization work will be afoot 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 Aug 2008 16:56:32 -0000 > This has been discussed extensively on various mailing lists and at > various BSD conferences over the past ~5 years. Search the archives for > "vimage". I am confused, is vimage actually in -CURRENT now? my guess is no because there is no man page Sam Fourman Jr. From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 18:33:19 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 685B2106567B for ; Fri, 15 Aug 2008 18:33:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outJ.internet-mail-service.net (outj.internet-mail-service.net [216.240.47.233]) by mx1.freebsd.org (Postfix) with ESMTP id 4A70F8FC18 for ; Fri, 15 Aug 2008 18:33:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 193C22385; Fri, 15 Aug 2008 11:33:19 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 653A72D6093; Fri, 15 Aug 2008 11:33:18 -0700 (PDT) Message-ID: <48A5CBEE.6090603@elischer.org> Date: Fri, 15 Aug 2008 11:33:18 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: darrenr@freebsd.org References: <1218809394.10612.1268815905@webmail.messagingengine.com> In-Reply-To: <1218809394.10612.1268815905@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, Robert Watson , current@FreeBSD.org Subject: Re: Advanced warning: virtualization work will be afoot 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 Aug 2008 18:33:19 -0000 Darren Reed wrote: > Robert, > > Do you have any more information about what the details of > this virtualization work will be? e.g. will it be similar > to what Solaris has with zones? > > The reason that I ask is that I've just finished getting > the ipfilter code (non-Sun code) converted to being zone > aware. What does that mean? Lots of global variables are > gone, replaced by soft-context structures that are allocated > and free'd when zones come alive/die. For BSD, while all > of the code paths are the same, I'm currently only using > a single soft context and just pass around a pointer to > it. > > If you're going to be doing similar work for FreeBSD, I > will try and get this into the tree sooner, rather than > later, so that there's one less component that you need > to worry about. > > Cheers, > Darren look at the following document: http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/vimage/porting_to_vimage.txt sorry if that wraps there are patches at: also look at the patches in the ipfilter files in that branch. If you are doingthe work for zones then that will be applicable. BTW you might look at dropping all teh suport for freeBSD 3.x in your files :-) the aggregate diff can be found at: http://www.freebsd.org/~julian/vimage.diff. If you want to handle ipfilter yourself then we'd be happy to let you do it. From owner-freebsd-arch@FreeBSD.ORG Sat Aug 16 11:18:26 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACF1F106567A for ; Sat, 16 Aug 2008 11:18:26 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 519398FC14 for ; Sat, 16 Aug 2008 11:18:26 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id F1C511CDC3; Sat, 16 Aug 2008 13:18:24 +0200 (CEST) Date: Sat, 16 Aug 2008 13:18:24 +0200 From: Ed Schouten To: FreeBSD Arch Message-ID: <20080816111824.GL99951@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0DcgAuOrObJpcAxl" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Jille Timmermans Subject: [Reviews requested] kern/121073: chroot for non-root users X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2008 11:18:26 -0000 --0DcgAuOrObJpcAxl Content-Type: multipart/mixed; boundary="3MtLaQwm2ZGHj8IC" Content-Disposition: inline --3MtLaQwm2ZGHj8IC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, When I visited FOSDEM back in February, I was talking with Jille Timmermans about the chroot() call. After discussing that the problem with chroot() is that it cannot be safely be executed by non-root users w.r.t. setuid binaries*, we wrote this patchset for the kernel to add something similar to `MNT_NOSUID' to the process flags. The result being: http://bugs.FreeBSD.org/121073 The patch even adds a small security improvement to the system. Say, you'd change the typical chroot() + setuid() order the other way around, you're guaranteed the chrooted process will never change users afterwards, because it won't honour set[ug]id binaries anymore. Our security officer was wise enough to add the following to the PR: +----------------------------------------------------------+ |UNDER NO CONDITIONS SHOULD THIS PATCH BE COMMITTED WITHOUT| |EXPLICIT APPROVAL FROM THE FREEBSD SECURITY OFFICER. | +----------------------------------------------------------+ After having a discussion with Colin on IRC, there are a couple of questions we would like to be answered (or discussed) before getting this in the tree: - Are there any comments on the patch itself? - Colin was concerned if turned on, would it be possible for the user to do things which it normally couldn't and shouldn't? It would be great to get many reviews on this before we'd land it in the source tree. I've attached the patch to this email as well. Thanks! --=20 Ed Schouten WWW: http://80386.nl/ * Hardlink a setuid binary to a directory containing a fake C library and executing it. --3MtLaQwm2ZGHj8IC Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="chroot.diff" Content-Transfer-Encoding: quoted-printable --- lib/libc/sys/chroot.2 +++ lib/libc/sys/chroot.2 @@ -61,7 +61,13 @@ .Fn chroot has no effect on the process's current directory. .Pp -This call is restricted to the super-user. +By default, this call is restricted to the super-user. If +.Ql kern.chroot_allow_unprivileged +is set to a non-zero value, all users are capable of performing the +.Fn chroot +call. When called by an unprivileged user, the process and its children +won't honor the setuid and setgid bits when performing an +.Xr execve 2 . .Pp Depending on the setting of the .Ql kern.chroot_allow_open_directories @@ -140,3 +146,8 @@ open directories, or a MAC check), it is possible that this system call may return an error, with the working directory of the process left changed. +.Pp +When a call to +.Fn chroot +fails when invoked by an unprivileged user, the process is not properly +capable of executing setuid or setgid applications anymore. --- sys/kern/kern_exec.c +++ sys/kern/kern_exec.c @@ -633,7 +633,7 @@ =20 if (credential_changing && (imgp->vp->v_mount->mnt_flag & MNT_NOSUID) =3D=3D 0 && - (p->p_flag & P_TRACED) =3D=3D 0) { + (p->p_flag & (P_NOSUGID|P_TRACED)) =3D=3D 0) { /* * Turn off syscall tracing for set-id programs, except for * root. Record any set-id flags first to make sure that --- sys/kern/kern_fork.c +++ sys/kern/kern_fork.c @@ -595,7 +595,7 @@ * Preserve some more flags in subprocess. P_PROFIL has already * been preserved. */ - p2->p_flag |=3D p1->p_flag & P_SUGID; + p2->p_flag |=3D p1->p_flag & P_INHERITED; td2->td_pflags |=3D td->td_pflags & TDP_ALTSTACK; SESS_LOCK(p1->p_session); if (p1->p_session->s_ttyvp !=3D NULL && p1->p_flag & P_CONTROLT) --- sys/kern/vfs_syscalls.c +++ sys/kern/vfs_syscalls.c @@ -860,9 +860,12 @@ */ =20 static int chroot_allow_open_directories =3D 1; +static int chroot_allow_unprivileged =3D 0; =20 SYSCTL_INT(_kern, OID_AUTO, chroot_allow_open_directories, CTLFLAG_RW, &chroot_allow_open_directories, 0, ""); +SYSCTL_INT(_kern, OID_AUTO, chroot_allow_unprivileged, CTLFLAG_RW, + &chroot_allow_unprivileged, 0, ""); =20 /* * Change notion of root (``/'') directory. @@ -880,12 +883,27 @@ } */ *uap; { int error; + struct proc *p; struct nameidata nd; int vfslocked; =20 error =3D priv_check(td, PRIV_VFS_CHROOT); - if (error) - return (error); + if (error) { + if (!chroot_allow_unprivileged) + return (error); + + /* + * Disallow this process and its children to use setuid + * bits. Users could hardlink setuid applications into a + * chroot which contains a fake C library to obtain + * super-user privileges. + */ + p =3D td->td_proc; + PROC_LOCK(p); + p->p_flag |=3D P_NOSUGID; + PROC_UNLOCK(p); + } + NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF | MPSAFE | AUDITVNODE1, UIO_USERSPACE, uap->path, td); error =3D namei(&nd); --- sys/sys/proc.h +++ sys/sys/proc.h @@ -575,7 +575,9 @@ #define P_INMEM 0x10000000 /* Loaded into memory. */ #define P_SWAPPINGOUT 0x20000000 /* Process is being swapped out. */ #define P_SWAPPINGIN 0x40000000 /* Process is being swapped in. */ +#define P_NOSUGID 0x80000000 /* Ignore set[ug]id on exec. */ =20 +#define P_INHERITED (P_SUGID|P_NOSUGID) #define P_STOPPED (P_STOPPED_SIG|P_STOPPED_SINGLE|P_STOPPED_TRACE) #define P_SHOULDSTOP(p) ((p)->p_flag & P_STOPPED) =20 --3MtLaQwm2ZGHj8IC-- --0DcgAuOrObJpcAxl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkimt4AACgkQ52SDGA2eCwV9uQCfWMRPwbvuyvLsCphhfFMKUxEL 9UgAnixkKdX13A6U77mFgHL47RIJ/0GY =z37V -----END PGP SIGNATURE----- --0DcgAuOrObJpcAxl-- From owner-freebsd-arch@FreeBSD.ORG Sat Aug 16 12:31:58 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64BAF1065676 for ; Sat, 16 Aug 2008 12:31:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 065F58FC1E for ; Sat, 16 Aug 2008 12:31:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KUKcO-000P2z-IS; Sat, 16 Aug 2008 15:10:52 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7GCAncI065219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Aug 2008 15:10:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7GCAnH5081161; Sat, 16 Aug 2008 15:10:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m7GCAnFe081159; Sat, 16 Aug 2008 15:10:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 16 Aug 2008 15:10:49 +0300 From: Kostik Belousov To: Ed Schouten Message-ID: <20080816121049.GU1803@deviant.kiev.zoral.com.ua> References: <20080816111824.GL99951@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hLTC+yGFJlatjToQ" Content-Disposition: inline In-Reply-To: <20080816111824.GL99951@hoeg.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KUKcO-000P2z-IS 5c1f80f1d427fdbd45411981ab8161c8 X-Terabit: YES Cc: Jille Timmermans , FreeBSD Arch Subject: Re: [Reviews requested] kern/121073: chroot for non-root users X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2008 12:31:58 -0000 --hLTC+yGFJlatjToQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 16, 2008 at 01:18:24PM +0200, Ed Schouten wrote: > Hello everyone, >=20 > When I visited FOSDEM back in February, I was talking with Jille > Timmermans about the chroot() call. After discussing that the problem > with chroot() is that it cannot be safely be executed by non-root users > w.r.t. setuid binaries*, we wrote this patchset for the kernel to add > something similar to `MNT_NOSUID' to the process flags. The result > being: >=20 > http://bugs.FreeBSD.org/121073 >=20 > The patch even adds a small security improvement to the system. Say, > you'd change the typical chroot() + setuid() order the other way around, > you're guaranteed the chrooted process will never change users > afterwards, because it won't honour set[ug]id binaries anymore. >=20 > Our security officer was wise enough to add the following to the PR: >=20 > +----------------------------------------------------------+ > |UNDER NO CONDITIONS SHOULD THIS PATCH BE COMMITTED WITHOUT| > |EXPLICIT APPROVAL FROM THE FREEBSD SECURITY OFFICER. | > +----------------------------------------------------------+ >=20 > After having a discussion with Colin on IRC, there are a couple of > questions we would like to be answered (or discussed) before getting > this in the tree: >=20 > - Are there any comments on the patch itself? >=20 > - Colin was concerned if turned on, would it be possible for the user to > do things which it normally couldn't and shouldn't? >=20 > It would be great to get many reviews on this before we'd land it in the > source tree. I've attached the patch to this email as well. Thanks! >=20 > --=20 > Ed Schouten > WWW: http://80386.nl/ >=20 > * Hardlink a setuid binary to a directory containing a fake C library > and executing it. I think that the patch gives instant root. FreeBSD provides a rfork(2) system call. This call allows the processes to share filedesc table, that, among other information, contains the root of the filesystem namespace for the process. So, the scenario is to rfork() a process without RFFDG flag, and then for one of the resulting processes to perform a chroot. Now, second one has chrooted root, but no P_NOSUGID flag set. --hLTC+yGFJlatjToQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkimw8gACgkQC3+MBN1Mb4iFugCgkzmftWO/S+WwsmJU+4Omdd2X k3YAoOu98iMq4l7LfjQh05m6fGw09PRm =VlkQ -----END PGP SIGNATURE----- --hLTC+yGFJlatjToQ-- From owner-freebsd-arch@FreeBSD.ORG Sat Aug 16 13:05:33 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E66D106566B; Sat, 16 Aug 2008 13:05:33 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5879E8FC08; Sat, 16 Aug 2008 13:05:33 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id CFFAA1589C2; Sat, 16 Aug 2008 09:05:31 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 16 Aug 2008 09:05:31 -0400 X-Sasl-enc: B5VDFt4auON9J5ARbzCZag+MydjGxuxeqPjkhBYqSYTx 1218891931 Received: from [192.168.1.235] (76-191-150-176.dsl.dynamic.sonic.net [76.191.150.176]) by mail.messagingengine.com (Postfix) with ESMTPSA id CAB4722968; Sat, 16 Aug 2008 09:05:30 -0400 (EDT) Message-ID: <48A6D104.2010704@freebsd.org> Date: Sat, 16 Aug 2008 06:07:16 -0700 From: Darren Reed User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Julian Elischer References: <1218809394.10612.1268815905@webmail.messagingengine.com> <48A5CBEE.6090603@elischer.org> In-Reply-To: <48A5CBEE.6090603@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, Robert Watson , current@FreeBSD.org Subject: Re: Advanced warning: virtualization work will be afoot X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2008 13:05:33 -0000 Julian Elischer wrote: > Darren Reed wrote: >> Robert, >> >> Do you have any more information about what the details of >> this virtualization work will be? e.g. will it be similar >> to what Solaris has with zones? >> >> The reason that I ask is that I've just finished getting >> the ipfilter code (non-Sun code) converted to being zone >> aware. What does that mean? Lots of global variables are >> gone, replaced by soft-context structures that are allocated >> and free'd when zones come alive/die. For BSD, while all >> of the code paths are the same, I'm currently only using >> a single soft context and just pass around a pointer to >> it. >> >> If you're going to be doing similar work for FreeBSD, I >> will try and get this into the tree sooner, rather than >> later, so that there's one less component that you need >> to worry about. >> >> Cheers, >> Darren > > > > look at the following document: > > http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/vimage/porting_to_vimage.txt > > > sorry if that wraps > > there are patches at: > > also look at the patches in the ipfilter files in that branch. So the only changes I could see are V_* things for inet global variables that ipfilter abuses. Was there something else that I'm missing? > If you are doingthe work for zones then that will be applicable. It's now close to complete. There are 3 "layers" of data structure initilisation to get it running: - load (initialise all of the globals) - create (create the soft context structure) - init (build tables, register callbacks to get packets, etc.) > ... > the aggregate diff can be found at: > > http://www.freebsd.org/~julian/vimage.diff. > > If you want to handle ipfilter yourself then we'd be happy to let you > do it. At the moment, those diffs for IPFIlter only have some V_* changes for dealing with the global inet variables that it abuses. Is there more hidden somewhere? To get a proper idea of the changes I've been working on you should download this guy: http://coombs.anu.edu.au/~avalon/ip_fil5.0.3.tar.gz Nearly all of the global variables are gone, with bits and pieces hanging off ipf_*_softc_t structures now. So far as ipfilter/ipfw/pf go, for them to be meaningfully virtualised, the pfil code that currently supports them needs to be enhanced further such that they can "listen" for the creation of vimages, etc...that is if people want to delegate (partial) control of such to vimages. Darren From owner-freebsd-arch@FreeBSD.ORG Sat Aug 16 14:03:23 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E0F9106566B; Sat, 16 Aug 2008 14:03:23 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id E25D48FC0A; Sat, 16 Aug 2008 14:03:22 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 29BA7207E; Sat, 16 Aug 2008 16:03:22 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 0370B844AB; Sat, 16 Aug 2008 16:03:22 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Julian Elischer References: <1218809394.10612.1268815905@webmail.messagingengine.com> <48A5CBEE.6090603@elischer.org> Date: Sat, 16 Aug 2008 16:03:21 +0200 In-Reply-To: <48A5CBEE.6090603@elischer.org> (Julian Elischer's message of "Fri, 15 Aug 2008 11:33:18 -0700") Message-ID: <863al583bq.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: darrenr@freebsd.org, arch@FreeBSD.org, Robert Watson , current@FreeBSD.org Subject: Re: Advanced warning: virtualization work will be afoot X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2008 14:03:23 -0000 Julian Elischer writes: > the aggregate diff can be found at: > > http://www.freebsd.org/~julian/vimage.diff. > > If you want to handle ipfilter yourself then we'd be happy to let you > do it. There are a number of issues with the ipfilter parts of the vimage patch. I will commit an improved version to p4 shortly. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sat Aug 16 15:48:57 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 264AA1065693 for ; Sat, 16 Aug 2008 15:48:57 +0000 (UTC) (envelope-from jille@quis.cx) Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by mx1.freebsd.org (Postfix) with ESMTP id 850E88FC24 for ; Sat, 16 Aug 2008 15:48:56 +0000 (UTC) (envelope-from jille@quis.cx) Received: (qmail 27853 invoked by uid 0); 16 Aug 2008 15:22:14 -0000 Received: from ip83-113-174-82.adsl2.static.versatel.nl (HELO istud.quis.cx) ([82.174.113.83]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 16 Aug 2008 15:22:14 -0000 Received: from [192.168.1.11] (unknown [192.168.1.11]) by istud.quis.cx (Postfix) with ESMTP id 2426C5C1E; Sat, 16 Aug 2008 17:22:14 +0200 (CEST) Message-ID: <48A6F0A5.7070208@quis.cx> Date: Sat, 16 Aug 2008 17:22:13 +0200 From: Jille Timmermans User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Kostik Belousov References: <20080816111824.GL99951@hoeg.nl> <20080816121049.GU1803@deviant.kiev.zoral.com.ua> In-Reply-To: <20080816121049.GU1803@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.95.7 Content-Type: multipart/mixed; boundary="------------080102010200070804050806" Cc: Ed Schouten , FreeBSD Arch Subject: Re: [Reviews requested] kern/121073: chroot for non-root users X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2008 15:48:57 -0000 This is a multi-part message in MIME format. --------------080102010200070804050806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Confirming Kostik, using rfork(RFPROC) instead of rfork(RFPROC|RFFDG) and chrooting in the child also chroot's the parent, without giving him the flag. An option might be to store the P_NOSUGID flag somewhere in the desc table ? Attached patch will show the difference between w/ and w/o RFFDG. jille@elvis:~$ cc -o chroot-rfork chroot-rfork.c jille@elvis:~$ sudo ./chroot-rfork /COPYRIGHT does not exist (chrooted) /COPYRIGHT does not exist (chrooted) jille@elvis:~$ cc -o chroot-rfork chroot-rfork.c -DWITH_RFFDG_FLAG jille@elvis:~$ sudo ./chroot-rfork /COPYRIGHT does not exist (chrooted) /COPYRIGHT exists (not chrooted) -- Jille Kostik Belousov wrote: > On Sat, Aug 16, 2008 at 01:18:24PM +0200, Ed Schouten wrote: > >> Hello everyone, >> >> When I visited FOSDEM back in February, I was talking with Jille >> Timmermans about the chroot() call. After discussing that the problem >> with chroot() is that it cannot be safely be executed by non-root users >> w.r.t. setuid binaries*, we wrote this patchset for the kernel to add >> something similar to `MNT_NOSUID' to the process flags. The result >> being: >> >> http://bugs.FreeBSD.org/121073 >> >> The patch even adds a small security improvement to the system. Say, >> you'd change the typical chroot() + setuid() order the other way around, >> you're guaranteed the chrooted process will never change users >> afterwards, because it won't honour set[ug]id binaries anymore. >> >> Our security officer was wise enough to add the following to the PR: >> >> +----------------------------------------------------------+ >> |UNDER NO CONDITIONS SHOULD THIS PATCH BE COMMITTED WITHOUT| >> |EXPLICIT APPROVAL FROM THE FREEBSD SECURITY OFFICER. | >> +----------------------------------------------------------+ >> >> After having a discussion with Colin on IRC, there are a couple of >> questions we would like to be answered (or discussed) before getting >> this in the tree: >> >> - Are there any comments on the patch itself? >> >> - Colin was concerned if turned on, would it be possible for the user to >> do things which it normally couldn't and shouldn't? >> >> It would be great to get many reviews on this before we'd land it in the >> source tree. I've attached the patch to this email as well. Thanks! >> >> -- >> Ed Schouten >> WWW: http://80386.nl/ >> >> * Hardlink a setuid binary to a directory containing a fake C library >> and executing it. >> > > I think that the patch gives instant root. FreeBSD provides a rfork(2) > system call. This call allows the processes to share filedesc table, that, > among other information, contains the root of the filesystem namespace > for the process. > > So, the scenario is to rfork() a process without RFFDG flag, and then > for one of the resulting processes to perform a chroot. Now, second one > has chrooted root, but no P_NOSUGID flag set. > --------------080102010200070804050806 Content-Type: text/plain; name="chroot-rfork.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="chroot-rfork.c" #include #include #include #include #ifdef WITH_RFFDG_FLAG #define RFORK_FLAGS RFPROC|RFFDG #else #define RFORK_FLAGS RFPROC #endif int main(int argc, char **argv) { struct stat sb; switch(rfork(RFORK_FLAGS)) { case -1: err(1, "rfork()"); case 0: if(chroot("/tmp")!=0) err(1, "chroot()"); if(stat("/COPYRIGHT", &sb)==0) printf("/COPYRIGHT exists (not chrooted)\n"); else printf("/COPYRIGHT does not exist (chrooted)\n"); break; default: sleep(1); if(stat("/COPYRIGHT", &sb)==0) printf("/COPYRIGHT exists (not chrooted)\n"); else printf("/COPYRIGHT does not exist (chrooted)\n"); } } --------------080102010200070804050806--