From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 19 13:10:57 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86DB81065676; Sun, 19 Jul 2009 13:10:57 +0000 (UTC) (envelope-from prvs=14510a8469=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id EEA0D8FC0A; Sun, 19 Jul 2009 13:10:56 +0000 (UTC) (envelope-from prvs=14510a8469=killing@multiplay.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1248008401; x=1248613201; q=dns/txt; h=Received: Message-ID:From:To:Subject:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; bh=0wU2AMaw0VXaA3wr2kiTHo5IOSoWl7KpXK N+Wd5F70g=; b=oXteWa/1ksb3eo0wDWnyVc7yw/ehjPprPZpdKHkNnvjEQ6qiIY ejHzJjWjHP/17VS3peaAlp4Z7xdWML4LIXUJzZgcxb7d1Ikt7iOCpUkh8WzjfVW0 r8P49UgNrNMXoWGJVgp+M8l8ITqs+jG/xvjNBEgtjLqJMNvicXrx2c1XU= X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 19 Jul 2009 14:00:01 +0100 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50007892340.msg; Sun, 19 Jul 2009 14:00:00 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 19 Jul 2009 14:00:00 +0100 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.97 X-Return-Path: prvs=14510a8469=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <34D8564661E84455B8DA136799C649ED@multiplay.co.uk> From: "Steven Hartland" To: , Date: Sun, 19 Jul 2009 14:00:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Subject: i386_set_ldt on FreeBSD 7.x amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 13:10:57 -0000 I'm trying to convert some audio streams and the only app which seems to be capable of this mplayer with the w32codecs Unfortunately the machine is 7.1 amd64. I've compiled the binaries up on an old i386 box but when running said bins on the amd64 box it errors with: Opening audio decoder: [dmo] Win32/DMO decoders install_fs: Invalid argument Couldn't install fs segment, expect segfault Looking at the code the call to i386_set_ldt is failing is there any know workaround? Looking on Google there is a thread: i386_set_ldt and wine on AMD64 which mentions some patches by kib but no mention if this ever worked. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=233316+0+archive/2008/freebsd-amd64/20081214.freebsd-amd64 The latest version I can find is: http://people.freebsd.org/~kib/misc/amd64_ldt-pre.4.patch Anyone info appreciated. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 19 14:04:34 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C098106564A for ; Sun, 19 Jul 2009 14:04:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id A7FD18FC0C for ; Sun, 19 Jul 2009 14:04:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 n6JDmotx018892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 16:48:50 +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.3/8.14.3) with ESMTP id n6JDmodA074285; Sun, 19 Jul 2009 16:48:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n6JDmoaw074284; Sun, 19 Jul 2009 16:48:50 +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: Sun, 19 Jul 2009 16:48:50 +0300 From: Kostik Belousov To: Steven Hartland Message-ID: <20090719134850.GX55190@deviant.kiev.zoral.com.ua> References: <34D8564661E84455B8DA136799C649ED@multiplay.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+mxGJWuoTNnwmYgC" Content-Disposition: inline In-Reply-To: <34D8564661E84455B8DA136799C649ED@multiplay.co.uk> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at 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 Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: i386_set_ldt on FreeBSD 7.x amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 14:04:34 -0000 --+mxGJWuoTNnwmYgC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 19, 2009 at 02:00:00PM +0100, Steven Hartland wrote: > I'm trying to convert some audio streams and the only app > which seems to be capable of this mplayer with the w32codecs >=20 > Unfortunately the machine is 7.1 amd64. I've compiled the > binaries up on an old i386 box but when running said bins > on the amd64 box it errors with: >=20 > Opening audio decoder: [dmo] Win32/DMO decoders > install_fs: Invalid argument > Couldn't install fs segment, expect segfault >=20 > Looking at the code the call to i386_set_ldt is failing > is there any know workaround? >=20 > Looking on Google there is a thread: > i386_set_ldt and wine on AMD64 which mentions some patches by kib > but no mention if this ever worked. > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D233316+0+archive/2008/free= bsd-amd64/20081214.freebsd-amd64 >=20 > The latest version I can find is: > http://people.freebsd.org/~kib/misc/amd64_ldt-pre.4.patch >=20 > Anyone info appreciated. The patches were committed to HEAD. mplayer/win32 codecs were tested, it was one of the goal of the patch to have these codecs working on amd64. No MFC to 7.x is planned. --+mxGJWuoTNnwmYgC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEUEARECAAYFAkpjJEIACgkQC3+MBN1Mb4guwwCXRAoJ6mAcg0GlFx/+raJkL3CE YwCgnSR5epkm6IhtThiOZ13smDRyXak= =fswh -----END PGP SIGNATURE----- --+mxGJWuoTNnwmYgC-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 19 14:29:52 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03393106566C; Sun, 19 Jul 2009 14:29:52 +0000 (UTC) (envelope-from prvs=14510a8469=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 672F78FC1F; Sun, 19 Jul 2009 14:29:51 +0000 (UTC) (envelope-from prvs=14510a8469=killing@multiplay.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1248013791; x=1248618591; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=UX9A2m8dTuplS3RrUrD25 k7DkcKsh47RcXFs733RE30=; b=InImSqzXPMm/ECm+epk4cllWWIq+RS2BzWEht UCdFqsxb1Y1h0HMZFggdkCW/foJOqD3c+iBB8XFjrQzeCAhfW6PQrMqS0yRFEIi1 z2+h3eG3r0g0GEkWMnQTym1wMks3OU/JOgDcAEGrfP4aJGH751DAbiLGDXiCpdII CjjfrE= X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 19 Jul 2009 15:29:51 +0100 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50007892646.msg; Sun, 19 Jul 2009 15:29:51 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 19 Jul 2009 15:29:51 +0100 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.97 X-Return-Path: prvs=14510a8469=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Kostik Belousov" References: <34D8564661E84455B8DA136799C649ED@multiplay.co.uk> <20090719134850.GX55190@deviant.kiev.zoral.com.ua> Date: Sun, 19 Jul 2009 15:29:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: i386_set_ldt on FreeBSD 7.x amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 14:29:52 -0000 ----- Original Message ----- From: "Kostik Belousov" >> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=233316+0+archive/2008/freebsd-amd64/20081214.freebsd-amd64 >> >> The latest version I can find is: >> http://people.freebsd.org/~kib/misc/amd64_ldt-pre.4.patch > > Anyone info appreciated. > The patches were committed to HEAD. mplayer/win32 codec's were tested, > it was one of the goal of the patch to have these codec's working on amd64. > > No MFC to 7.x is planned. Thanks for the confirmation Kostik. Do you believe there is any reason to stop that patch working on 7.X if manually applied? Is the patch above the final version that went into HEAD? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 19 15:11:47 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AA671065670; Sun, 19 Jul 2009 15:11:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 833BF8FC15; Sun, 19 Jul 2009 15:11:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 n6JFBfJi025766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 18:11:41 +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.3/8.14.3) with ESMTP id n6JFBfE4074841; Sun, 19 Jul 2009 18:11:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n6JFBfSm074840; Sun, 19 Jul 2009 18:11:41 +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: Sun, 19 Jul 2009 18:11:41 +0300 From: Kostik Belousov To: Steven Hartland Message-ID: <20090719151141.GZ55190@deviant.kiev.zoral.com.ua> References: <34D8564661E84455B8DA136799C649ED@multiplay.co.uk> <20090719134850.GX55190@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F3GCS0dLSoPc8JYq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at 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 Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: i386_set_ldt on FreeBSD 7.x amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 15:11:47 -0000 --F3GCS0dLSoPc8JYq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 19, 2009 at 03:29:51PM +0100, Steven Hartland wrote: > ----- Original Message -----=20 > From: "Kostik Belousov" > >>http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D233316+0+archive/2008/fr= eebsd-amd64/20081214.freebsd-amd64 > >> > >>The latest version I can find is: > >>http://people.freebsd.org/~kib/misc/amd64_ldt-pre.4.patch > > > >Anyone info appreciated. > >The patches were committed to HEAD. mplayer/win32 codec's were tested, > >it was one of the goal of the patch to have these codec's working on amd= 64. > > > >No MFC to 7.x is planned. >=20 > Thanks for the confirmation Kostik. Do you believe there is any reason to > stop that patch working on 7.X if manually applied? Is the patch above the > final version that went into HEAD? No and no, but I think that back-porting is not that trivial. Upgrade is probably easier then backport. --F3GCS0dLSoPc8JYq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpjN6wACgkQC3+MBN1Mb4iaygCdFSSZkiQxtSHyoaJrthrs+KBf lG8An0UjxiM4i2C57bW2rkNW+LtKsXzf =Yr4I -----END PGP SIGNATURE----- --F3GCS0dLSoPc8JYq-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 19 16:28:30 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B820B1065673; Sun, 19 Jul 2009 16:28:30 +0000 (UTC) (envelope-from prvs=14510a8469=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 26C8C8FC1A; Sun, 19 Jul 2009 16:28:29 +0000 (UTC) (envelope-from prvs=14510a8469=killing@multiplay.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1248020909; x=1248625709; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=VZD/seS9onDsC3keW+HVv gAqSE/MAIU8EYi92zn/oqo=; b=JKTeSNAWIWkzMM3kcT0lJnGongxOioodDBGJs M0VS3VL2ryn9BLr3bmQ64LpvO4l+DeUrGcCln0A5tu1DcYnLX5MzdihLs1MLVvgK 32XKxVfY/7unxs2rofYN+CiKRGZ8fdvNWzew5ZQSqID3hFD589jHDuP/T7VTfSXP opDmDE= X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 19 Jul 2009 17:28:29 +0100 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50007893007.msg; Sun, 19 Jul 2009 17:28:27 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 19 Jul 2009 17:28:27 +0100 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.97 X-Return-Path: prvs=14510a8469=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Kostik Belousov" References: <34D8564661E84455B8DA136799C649ED@multiplay.co.uk> <20090719134850.GX55190@deviant.kiev.zoral.com.ua> <20090719151141.GZ55190@deviant.kiev.zoral.com.ua> Date: Sun, 19 Jul 2009 17:28:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: i386_set_ldt on FreeBSD 7.x amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 16:28:31 -0000 ----- Original Message ----- From: "Kostik Belousov" >> Thanks for the confirmation Kostik. Do you believe there is any reason to >> stop that patch working on 7.X if manually applied? Is the patch above the >> final version that went into HEAD? > > No and no, but I think that back-porting is not that trivial. > Upgrade is probably easier then backport. When you say HEAD would that require an upgrade to 7-STABLE or 8-CURRENT? I never did get what the official meaning of HEAD is, as it seems to be used by different people to mean both of the above. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 19 20:07:36 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5320106564A; Sun, 19 Jul 2009 20:07:36 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 7C6C08FC19; Sun, 19 Jul 2009 20:07:36 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 910221CF3C; Sun, 19 Jul 2009 22:07:35 +0200 (CEST) Date: Sun, 19 Jul 2009 22:07:35 +0200 From: Ed Schouten To: Steven Hartland Message-ID: <20090719200735.GG68469@hoeg.nl> References: <34D8564661E84455B8DA136799C649ED@multiplay.co.uk> <20090719134850.GX55190@deviant.kiev.zoral.com.ua> <20090719151141.GZ55190@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: i386_set_ldt on FreeBSD 7.x amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 20:07:37 -0000 Hi Steven, * Steven Hartland wrote: > When you say HEAD would that require an upgrade to 7-STABLE or 8-CURRENT? Right now HEAD (or head/ in SVN) is 8-CURRENT. RELENG_7 (or stable/7) is 7-STABLE. -- Ed Schouten WWW: http://80386.nl/ From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 20 05:18:38 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23DB91065674 for ; Mon, 20 Jul 2009 05:18:37 +0000 (UTC) (envelope-from kaduk@MIT.EDU) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by mx1.freebsd.org (Postfix) with ESMTP id 927248FC08 for ; Mon, 20 Jul 2009 05:18:37 +0000 (UTC) (envelope-from kaduk@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n6K56t5U025719 for ; Mon, 20 Jul 2009 01:06:55 -0400 (EDT) Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n6K56sqN019852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 20 Jul 2009 01:06:55 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id n6K56rcZ023489; Mon, 20 Jul 2009 01:06:53 -0400 (EDT) Date: Mon, 20 Jul 2009 01:06:53 -0400 (EDT) From: Benjamin Kaduk To: freebsd-hackers@freebsd.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Subject: add missing content to locking.9 ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 05:18:38 -0000 Hi all, In trying to track down an unrelated issue, I happened to note that locking.9 needed a bit of help. They easy changes went into docs/136918, but I am less confident about my reading of the posix semaphore code. Would anyone care to comment on the following?: --- locking.9 2009-07-20 00:34:46.000000000 -0400 +++ locking.9.new 2009-07-20 00:31:27.000000000 -0400 @@ -215,6 +215,11 @@ a turnstile, its priority can propagate to the thread that holds the lock, helping to avoid a deadlock situation. .Ss Semaphores +.Tn POSIX +semaphores provide a wait channel in the filesystem namespace +whereby different threads can communicate with each other (by waiting +on the semaphore, and waking up the thread(s) waiting on that semaphore). +They are currently implemented on top of condition variables. .Ss Condition variables Condition variables are used in conjunction with mutexes to wait for conditions to occur. It should also be noted that there remains a comment "I don't know what the downsides are but I'm sure someone will fill in this part" regarding lockmgr locks ... I am not up for reading the code enough to comment, tonight, though. Thanks, Ben Kaduk From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 20 06:27:26 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79401106564A for ; Mon, 20 Jul 2009 06:27:26 +0000 (UTC) (envelope-from mel.flynn+fbsd.hackers@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1D6348FC0A for ; Mon, 20 Jul 2009 06:27:25 +0000 (UTC) (envelope-from mel.flynn+fbsd.hackers@mailing.thruhere.net) Received: from mx1.sbmail.office-on-the.net (mx1.sbmail.office-on-the.net [192.168.2.107]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 6370B7E818 for ; Sun, 19 Jul 2009 22:27:25 -0800 (AKDT) Received: by mx1.sbmail.office-on-the.net (Postfix, from userid 125) id CEEB1C2C800; Sun, 19 Jul 2009 22:33:53 -0800 (AKDT) Received: from dspam.sbmail.office-on-the.net (mx1.sbmail.office-on-the.net [192.168.2.107]) by mx1.sbmail.office-on-the.net (Postfix) with SMTP id 45F38C2C802 for ; Sun, 19 Jul 2009 22:13:51 -0800 (AKDT) Received: from webmail.testbox.ath.cx (mx1.sbmail.office-on-the.net [192.168.2.107]) by mx1.sbmail.office-on-the.net (Postfix) with ESMTP id F237DC2C800; Sun, 19 Jul 2009 22:13:48 -0800 (AKDT) MIME-Version: 1.0 Date: Sun, 19 Jul 2009 22:13:48 -0800 From: Mel Flynn To: John Baldwin In-Reply-To: <200907131639.10346.jhb@freebsd.org> References: <200907131428.08923.jhb@freebsd.org> <200907132133.52217.tijl@ulyssis.org> <200907131639.10346.jhb@freebsd.org> Message-ID: X-Sender: mel.flynn+fbsd.hackers@mailing.thruhere.net User-Agent: RoundCube Webmail/0.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun Jul 19 22:13:50 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689407 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 54,4a640b1e44756072160320 X-DSPAM-Factors: 27, "uap+>len, 0.40000, Received*Sun+19, 0.40000, ccache+CALL, 0.40000, ccache+CALL, 0.40000, On+Monday, 0.40000, On+Monday, 0.40000, right, 0.40000, smoochies+rachie, 0.40000, smoochies+rachie, 0.40000, so+excuse, 0.40000, 2009+16, 0.40000, 229, 0.40000, 229, 0.40000, tree+recently, 0.40000, John+Baldwin, 0.40000, John+Baldwin, 0.40000, Cc*hackers+freebsd.org>, 0.40000, into+numeric, 0.40000, Cc*Best, 0.40000, an, 0.40000, Cc*Coosemans+, 0.40000, Received*webmail.testbox.ath.cx, 0.40000, from, 0.40000, from, 0.40000, 16+39, 0.40000 Cc: Nate Eldredge , Tijl Coosemans , Alexander Best , Alan Cox , freebsd-hackers@freebsd.org Subject: Re: mmap/munmap with zero length X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 06:27:26 -0000 On Mon, 13 Jul 2009 16:39:09 -0400, John Baldwin wrote: > On Monday 13 July 2009 3:33:51 pm Tijl Coosemans wrote: >> On Monday 13 July 2009 20:28:08 John Baldwin wrote: >> > On Sunday 05 July 2009 3:32:25 am Alexander Best wrote: >> >> so mmap differs from the POSIX recommendation right. the malloc.con= f >> >> option seems more like a workaround/hack. imo it's confusing to hav= e >> >> mmap und munmap deal differently with len=3D0. being able to >> >> succesfully alocate memory which cannot be removed doesn't seem >> >> logical to me. >> >=20 >> > This should fix it: >> >=20 >> > --- //depot/user/jhb/acpipci/vm/vm_mmap.c >> > +++ /home/jhb/work/p4/acpipci/vm/vm_mmap.c >> > @@ -229,7 +229,7 @@ >> >=20 >> > fp =3D NULL; >> > /* make sure mapping fits into numeric range etc */ >> > - if ((ssize_t) uap->len < 0 || >> > + if ((ssize_t) uap->len <=3D 0 || >> > ((flags & MAP_ANON) && uap->fd !=3D -1)) >> > return (EINVAL); >>=20 >> Why not "uap->len =3D=3D 0"? Sizes of 2GiB and more (32bit) shouldn't = cause >> an error. >=20 > I don't actually disagree and know of locally modified versions of FreeBSD=20 > that remove this check for precisely that reason. If this has hit the tree recently, I think it broke ccache. Since I've also done make delete-old-libs and was about to rebuild all my ports on my laptop, I'll investigate, as I'm not looking forward to doing this twice for all dependants of libtool :(. Failed to mmap /var/db/ccache/mel/tmp.cpp_stderr.smoochies.rachie.is-a-geek.net.27934 kdump: 27934 ccache CALL open(0x28201280,O_RDONLY,0x1) 27934 ccache NAMI=20 "/var/db/ccache/mel/tmp.cpp_stderr.smoochies.rachie.is-a-geek.net.27934" 27934 ccache RET open 4 27934 ccache CALL fstat(0x4,0xbfbfe7fc) 27934 ccache STRU struct stat {dev=3D105, ino=3D895320, mode=3D-rw-r-= -r-- , nlink=3D1, uid=3D1003, gid=3D0, rdev=3D0, atime=3D1248069251, stime=3D124= 8069251, ctime=3D1248069251, birthtime=3D1248069251, size=3D0, blksize=3D4096, blo= cks=3D0, flags=3D0x0 } 27934 ccache RET fstat 0 27934 ccache CALL mmap(0,0,PROT_READ,MAP_PRIVATE,0x4,0,0) 27934 ccache RET mmap -1 errno 22 Invalid argument Sent from webmail, so excuse any formatting issues. --=20 Mel From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 20 07:07:31 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7A671065672 for ; Mon, 20 Jul 2009 07:07:31 +0000 (UTC) (envelope-from mel.flynn+fbsd.hackers@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 7E4EA8FC17 for ; Mon, 20 Jul 2009 07:07:31 +0000 (UTC) (envelope-from mel.flynn+fbsd.hackers@mailing.thruhere.net) Received: from mx1.sbmail.office-on-the.net (mx1.sbmail.office-on-the.net [192.168.2.107]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 0C3147E82C for ; Sun, 19 Jul 2009 23:07:31 -0800 (AKDT) Received: from dspam.sbmail.office-on-the.net (mx1.sbmail.office-on-the.net [192.168.2.107]) by mx1.sbmail.office-on-the.net (Postfix) with SMTP id CAE89C2C801 for ; Sun, 19 Jul 2009 23:07:30 -0800 (AKDT) Received: from webmail.testbox.ath.cx (mx1.sbmail.office-on-the.net [192.168.2.107]) by mx1.sbmail.office-on-the.net (Postfix) with ESMTP id 99397C2C800; Sun, 19 Jul 2009 23:07:27 -0800 (AKDT) MIME-Version: 1.0 Date: Sun, 19 Jul 2009 23:07:27 -0800 From: Mel Flynn To: John Baldwin In-Reply-To: References: <200907131428.08923.jhb@freebsd.org> <200907132133.52217.tijl@ulyssis.org> <200907131639.10346.jhb@freebsd.org> Message-ID: <55daf4085f8ce3b4e383e36ba502bdec@sbmail.office-on-the.net> X-Sender: mel.flynn+fbsd.hackers@mailing.thruhere.net User-Agent: RoundCube Webmail/0.2 Content-Type: multipart/mixed; boundary="=_c8a6da3ff5ed2d176ffac65707f6706f" X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun Jul 19 23:07:30 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689407 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 54,4a6417b244757508476556 X-DSPAM-Factors: 27, Sun, 0.40000, "uap+>len, 0.40000, Received*Sun+19, 0.40000, Content-Type*application/octet+stream, 0.40000, ccache+CALL, 0.40000, ccache+CALL, 0.40000, On+Monday, 0.40000, On+Monday, 0.40000, right, 0.40000, smoochies+rachie, 0.40000, smoochies+rachie, 0.40000, >+"/var/db/ccache/mel/tmp, 0.40000, 2009+16, 0.40000, 229, 0.40000, 229, 0.40000, tree+recently, 0.40000, John+Baldwin, 0.40000, John+Baldwin, 0.40000, Cc*hackers+freebsd.org>, 0.40000, into+numeric, 0.40000, Cc*Best, 0.40000, an, 0.40000, Cc*Coosemans+>>, 0.40000, Received*webmail.testbox.ath.cx, 0.40000 Cc: ahze@freebsd.org, Alan Cox , freebsd-hackers@freebsd.org, ports@freebsd.org, Alexander Best , Nate Eldredge , Tijl Coosemans Subject: Re: mmap/munmap with zero length X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 07:07:32 -0000 --=_c8a6da3ff5ed2d176ffac65707f6706f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 19 Jul 2009 22:13:48 -0800, Mel Flynn wrote: > On Mon, 13 Jul 2009 16:39:09 -0400, John Baldwin wrot= e: >> On Monday 13 July 2009 3:33:51 pm Tijl Coosemans wrote: >>> On Monday 13 July 2009 20:28:08 John Baldwin wrote: >>> > On Sunday 05 July 2009 3:32:25 am Alexander Best wrote: >>> >> so mmap differs from the POSIX recommendation right. the malloc.co= nf >>> >> option seems more like a workaround/hack. imo it's confusing to ha= ve >>> >> mmap und munmap deal differently with len=3D0. being able to >>> >> succesfully alocate memory which cannot be removed doesn't seem >>> >> logical to me. >>> >=20 >>> > This should fix it: >>> >=20 >>> > --- //depot/user/jhb/acpipci/vm/vm_mmap.c >>> > +++ /home/jhb/work/p4/acpipci/vm/vm_mmap.c >>> > @@ -229,7 +229,7 @@ >>> >=20 >>> > fp =3D NULL; >>> > /* make sure mapping fits into numeric range etc */ >>> > - if ((ssize_t) uap->len < 0 || >>> > + if ((ssize_t) uap->len <=3D 0 || >>> > ((flags & MAP_ANON) && uap->fd !=3D -1)) >>> > return (EINVAL); >>>=20 >>> Why not "uap->len =3D=3D 0"? Sizes of 2GiB and more (32bit) shouldn't= cause >>> an error. >>=20 >> I don't actually disagree and know of locally modified versions of > FreeBSD=20 >> that remove this check for precisely that reason. >=20 > If this has hit the tree recently, I think it broke ccache. >=20 > Since I've also done make delete-old-libs and was about to rebuild all = my > ports on my laptop, I'll investigate, as I'm not looking forward to doi= ng > this twice for all dependants of libtool :(. >=20 > Failed to mmap > /var/db/ccache/mel/tmp.cpp_stderr.smoochies.rachie.is-a-geek.net.27934 >=20 > kdump: > 27934 ccache CALL open(0x28201280,O_RDONLY,0x1) > 27934 ccache NAMI=20 > "/var/db/ccache/mel/tmp.cpp_stderr.smoochies.rachie.is-a-geek.net.27934= " > 27934 ccache RET open 4 > 27934 ccache CALL fstat(0x4,0xbfbfe7fc) > 27934 ccache STRU struct stat {dev=3D105, ino=3D895320, mode=3D-rw-= r--r-- , > nlink=3D1, uid=3D1003, gid=3D0, rdev=3D0, atime=3D1248069251, stime=3D1= 248069251, > ctime=3D1248069251, birthtime=3D1248069251, size=3D0, blksize=3D4096, b= locks=3D0, > flags=3D0x0 } > 27934 ccache RET fstat 0 > 27934 ccache CALL mmap(0,0,PROT_READ,MAP_PRIVATE,0x4,0,0) > 27934 ccache RET mmap -1 errno 22 Invalid argument Confirmed, attached patch fixes ccache. Probably should be patched in patch-md4. --=20 Mel --=_c8a6da3ff5ed2d176ffac65707f6706f Content-Transfer-Encoding: base64 Content-Type: application/octet-stream; charset="UTF-8"; name="patch-mmap"; Content-Disposition: attachment; filename="patch-mmap"; LS0tIGhhc2guYy5vcmlnCTIwMDktMDctMTkgMjI6NDY6MTguMDAwMDAwMDAwIC0wODAwCisrKyBo YXNoLmMJMjAwOS0wNy0xOSAyMjo0NjoxMy4wMDAwMDAwMDAgLTA4MDAKQEAgLTY3LDEyICs2Nywx NiBAQAogICAgICAgICAgICAgICAgY2xvc2UoZmQpOwogICAgICAgICAgICAgICAgZmF0YWwoX19G VU5DVElPTl9fKTsKICAgICAgICB9Ci0gICAgICAgYnVmID0gbW1hcChOVUxMLCBzdGF0cy5zdF9z aXplLCBQUk9UX1JFQUQsIE1BUF9QUklWQVRFLCBmZCwgMCk7IAotICAgICAgIGlmIChidWYgPT0g TUFQX0ZBSUxFRCkgewotICAgICAgICAgICAgICAgY2NfbG9nKCJGYWlsZWQgdG8gbW1hcCAlc1xu IiwgZm5hbWUpOwotICAgICAgICAgICAgICAgY2xvc2UoZmQpOwotICAgICAgICAgICAgICAgZmF0 YWwoX19GVU5DVElPTl9fKTsKLSAgICAgICAgfSAgICAgICAKKyAgICAgICBpZiggc3RhdHMuc3Rf c2l6ZSA9PSAwICkKKwkgICAgICAgYnVmID0gTlVMTDsKKyAgICAgICBlbHNlIHsKKwkgICAgICAg YnVmID0gbW1hcChOVUxMLCBzdGF0cy5zdF9zaXplLCBQUk9UX1JFQUQsIE1BUF9QUklWQVRFLCBm ZCwgMCk7IAorCSAgICAgICBpZiAoYnVmID09IE1BUF9GQUlMRUQpIHsKKwkJICAgICAgIGNjX2xv ZygiRmFpbGVkIHRvIG1tYXAgJXNcbiIsIGZuYW1lKTsKKwkJICAgICAgIGNsb3NlKGZkKTsKKwkJ ICAgICAgIGZhdGFsKF9fRlVOQ1RJT05fXyk7CisJCX0gICAgICAgCisgICAgICAgfQogCiAgICAg ICAgIGhhc2hfYnVmZmVyKGJ1Ziwgc3RhdHMuc3Rfc2l6ZSk7CiAJY2xvc2UoZmQpOwo= --=_c8a6da3ff5ed2d176ffac65707f6706f-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 20 11:17:29 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F1B7106588F; Mon, 20 Jul 2009 11:17:29 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5C3F88FC0C; Mon, 20 Jul 2009 11:17:28 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA16392; Mon, 20 Jul 2009 14:05:35 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A644F7E.2000107@icyb.net.ua> Date: Mon, 20 Jul 2009 14:05:34 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Andre Albsmeier References: <20090717190450.GA4697@curry.mchp.siemens.de> <4A60D6D1.3050703@elischer.org> <20090718081011.GA6920@curry.mchp.siemens.de> <4A61D6FB.2090904@elischer.org> In-Reply-To: <4A61D6FB.2090904@elischer.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Rui Paulo , Julian Elischer Subject: Re: Reading acpi memory from a driver attached to hostb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 11:17:49 -0000 on 18/07/2009 17:06 Julian Elischer said the following: > Andre Albsmeier wrote: >> But in order to attach to acpi0, I need to say >> >> DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, >> NULL ); >> >> instead of >> >> DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, >> NULL ); > > try both with different devclass and other args. Just to expand on Julian's words. You can create eccmon and e.g. eccmon_acpi such that they are different drivers (on different buses) in newbus sense, but logically they can share data or otherwise cooperate. /sys/dev/cpufreq/ichss.c prior to rev. 177041 used to be like that. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 20 12:36:09 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8A361065670 for ; Mon, 20 Jul 2009 12:36:09 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0B18FC1E for ; Mon, 20 Jul 2009 12:36:09 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 32A291CD9F; Mon, 20 Jul 2009 14:36:08 +0200 (CEST) Date: Mon, 20 Jul 2009 14:36:08 +0200 From: Ed Schouten To: Benjamin Kaduk Message-ID: <20090720123607.GI68469@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="e5bfZ/T2xnjpUIbw" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: add missing content to locking.9 ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 12:36:10 -0000 --e5bfZ/T2xnjpUIbw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Benjamin, * Benjamin Kaduk wrote: > +.Tn POSIX > +semaphores provide ... it looks like you described the semaphores that are used in userspace. The Semaphores section of the locking(9) man page should describe in-kernel semaphores (kern_sema.c). They are implemented by a mutex and a conditional variable. Even though it's nice to have some utility functions in our kernel, I always wondered why we have them. There isn't a lot of code in the tree that uses them... --=20 Ed Schouten WWW: http://80386.nl/ --e5bfZ/T2xnjpUIbw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpkZLcACgkQ52SDGA2eCwVOZgCfcBM0q829T6mTGw4U8FmpqvaA G68An3AEr3tnU9v2/TsVkwnk71VUWX44 =PSf8 -----END PGP SIGNATURE----- --e5bfZ/T2xnjpUIbw-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 20 15:14:06 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E8AB106566C for ; Mon, 20 Jul 2009 15:14:06 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-ew0-f222.google.com (mail-ew0-f222.google.com [209.85.219.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2E4308FC2C for ; Mon, 20 Jul 2009 15:14:05 +0000 (UTC) (envelope-from brampton@gmail.com) Received: by ewy22 with SMTP id 22so671121ewy.43 for ; Mon, 20 Jul 2009 08:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=BEzqYvfqIGWCmNasZ43g3ojXjA70oBq8SFQVaXtmJvs=; b=Z4TvfaimmYapstcKsbio8UXWLQgQUrqcFJ/E/HP7S4CvfZrJ4GFiGxaaV1CfwKxH54 ka+gC5jauQAOWaZ2jQCDYXSCmTzxn3iXul8Xz2bgmpb3loxcHFbZP+4pwvkY2mvq6Iky fQPfTTJziAFr8SwyQUaxhE9FpAp/cHoPJDc4M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=NU2ycDAStCgMUSwRP0OwBpx+IPb0XH4paOJdFa/mBYGs5EwEFBNVcNpPU8uV+GCucg Sj+X//n3usXi4QEp1eDuxTEf/YYWt8Hlmd073ePBJ27pwddTAWPOlsT35dXskkgQxtZs 0YHB2ML1CGmAbJsT0LGWv/uXqtHMTa2zgpOBY= MIME-Version: 1.0 Sender: brampton@gmail.com Received: by 10.216.13.84 with SMTP id a62mr1171190wea.219.1248102842373; Mon, 20 Jul 2009 08:14:02 -0700 (PDT) Date: Mon, 20 Jul 2009 16:14:02 +0100 X-Google-Sender-Auth: 7413f4f806531362 Message-ID: From: Andrew Brampton To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: vm_map_protect / pmap_protect Can't lower protection X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 15:14:07 -0000 Hi, I've been playing with memguard(9) and so far it works well until it starts to run out of memory. For those who don't know, memguard is a replacement debugging malloc for the kernel, which is designed to catch use after free errors. It achieves this by setting any free'd pages to read-only, therefore any writes to the page should generate a page fault, and a backtrace allowing you to figure out where your code is using freed memory. To stop memguard using all your system's RAM and setting every page to read-only, it begins to recycle previously freed pages. To do this it must first make the page read-write, and then return it from malloc. The problem I am facing is when memguard, unguards a page (ie changes the page to read-write) it does not actually do this, and the page remains read-only. I have tracked the problem down but I don't know how to fix it. memguard_guard calls vm_map_protect with a read-only flag. vm_map_protect updates the vm_map_entry, and then calls pmap_protect to set the actual pte. pmap_protect successfully sets the pte to read-only and everything works as it should. However, memguard_unguard doesn't work correctly. It first calls vm_map_protect with a read-write flag. vm_map_protect correctly updates the vm_map_entry, and then calls pmap_protect to set the actual pte. pmap_protect is lazy and notices that we are reducing the protection on the page and therefore does nothing. It assumes that later that a page fault will occur, call vm_fault, and then fix up the pte then. The problem I seem to be having is that vm_fault is not called, because when the page fault occurs, calltrap then trap gets called, but it falls into trap_fatal because a non-sleepable lock is held. So my question is, can I call a function which sets the pte in a non-lazy way? I considered rewriting pmap_protect to do this, but I thought it be best to do it another way. Another idea I had was to call vm_fault myself straight after vm_map_protect, but I was unsure if that was allowed. Also, some googling found the function pmap_page_protect claims to do what I want, but has long been missing from FreeBSD. In case it matters, I'm using FreeBSD 7.2, on a amd64 machine. I've looked at HEAD and the relevant code looks the same, so I suspect I will still have problems with that. thanks for any help Andrew From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 20 18:26:25 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08B741065679; Mon, 20 Jul 2009 18:26:25 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9398FC22; Mon, 20 Jul 2009 18:26:24 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n6KIQLYD028912; Mon, 20 Jul 2009 20:26:21 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n6KIQLsL017428; Mon, 20 Jul 2009 20:26:21 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.3/8.14.3) id n6KIQKAW094489; Date: Mon, 20 Jul 2009 20:26:20 +0200 From: Andre Albsmeier To: Andriy Gapon Message-ID: <20090720182620.GA90731@curry.mchp.siemens.de> References: <20090717190450.GA4697@curry.mchp.siemens.de> <4A60D6D1.3050703@elischer.org> <20090718081011.GA6920@curry.mchp.siemens.de> <4A61D6FB.2090904@elischer.org> <4A644F7E.2000107@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A644F7E.2000107@icyb.net.ua> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, Rui Paulo , Julian Elischer , Andre Albsmeier Subject: Re: Reading acpi memory from a driver attached to hostb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 18:26:25 -0000 On Mon, 20-Jul-2009 at 14:05:34 +0300, Andriy Gapon wrote: > on 18/07/2009 17:06 Julian Elischer said the following: > > Andre Albsmeier wrote: > >> But in order to attach to acpi0, I need to say > >> > >> DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, > >> NULL ); > >> > >> instead of > >> > >> DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, > >> NULL ); > > > > try both with different devclass and other args. > > Just to expand on Julian's words. > You can create eccmon and e.g. eccmon_acpi such that they are different drivers > (on different buses) in newbus sense, but logically they can share data or > otherwise cooperate. Very interesting code, I still haven't understood all of it but we will see... This could be the solution -- however, if somebody knows a more simple way, please let me know. Thanks, -Andre > > /sys/dev/cpufreq/ichss.c prior to rev. 177041 used to be like that. > > -- > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Amateurs like Linux, but professionals prefer FreeBSD. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 20 21:35:59 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18839106566B; Mon, 20 Jul 2009 21:35:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C9BEF8FC0A; Mon, 20 Jul 2009 21:35:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 618CA46B5C; Mon, 20 Jul 2009 17:35:58 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id C00398A09E; Mon, 20 Jul 2009 17:35:57 -0400 (EDT) From: John Baldwin To: Andre Albsmeier Date: Mon, 20 Jul 2009 10:46:58 -0400 User-Agent: KMail/1.9.7 References: <20090717190450.GA4697@curry.mchp.siemens.de> <20090718133938.GA7802@curry.mchp.siemens.de> In-Reply-To: <20090718133938.GA7802@curry.mchp.siemens.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907201046.58558.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 20 Jul 2009 17:35:57 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_06_12,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, Rui Paulo , Julian Elischer Subject: Re: Reading acpi memory from a driver attached to hostb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 21:35:59 -0000 On Saturday 18 July 2009 9:39:38 am Andre Albsmeier wrote: > On Sat, 18-Jul-2009 at 10:25:06 +0100, Rui Paulo wrote: > > On 18 Jul 2009, at 09:10, Andre Albsmeier wrote: > > > > > On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote: > > >> Andre Albsmeier wrote: > > >>> [CC'ing this to Rui Paulo since he tried to help me a while ago] > > >>> > > >>> Since my driver is a child of hostb0, I have no idea of how to > > >>> access > > >>> acpi0's memory area. Here is a devinfo -r to make things clear: > > >>> > > >> ... > > >>> > > >>> Earlier, I was given the hint to attach as a child of acpi (see the > > >>> old mail attached below) but in this case I didn't have access to > > >>> the > > >>> hostb registers which I need as well. > > >>> > > >>> The only thing I see is: Attach two drivers -- one as child of acpi > > >>> and another as child of hostb and let them communicate somehow (no > > >>> idea how to do this). > > >>> > > >>> I have also done crazy things like searching for acpi0 and trying > > >>> to bus_alloc_resource() the memory I am interested in but this also > > >>> failed. > > >>> > > >>> Or is it possible to free(!) somehow the address space from acpi0 > > >>> and pass it to hostb0 so I can bus_alloc_resource() it? > > >>> > > >> > > >> You can probably make two drivers in one which cooperate to > > >> allow access to both sets of resources. > > > > > > Hmm, that's what I meant by: Attach two drivers -- one as child of > > > acpi > > > and another as child of hostb... > > > > > > And that's similar to Rui Paulo's suggestion a while ago: > > > > > >> You'll probably need to create a fake ACPI child driver to access it. > > >> > > >> Create your identify routine with something like: > > >> > > >> static void mydriver_identify(driver_t *driver, device_t parent) > > >> { > > >> if (device_find_child(parent, "mydriver", -1) == NULL && > > >> mydriver_match(parent)) > > >> device_add_child(parent, "mydriver", -1); > > >> } > > >> > > >> mydriver_match() should check if you were given the acpi0 device. > > > > > > But in order to attach to acpi0, I need to say > > > > > > DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, > > > NULL ); > > > > > > instead of > > > > > > DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, > > > NULL ); > > > > > > This way I could attach to acpi but not to hostb anymore.... > > > > > > I have searched the net for solutions, I have read newbus-draft.txt > > > and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all > > > of these my driver is working on other mainboards where it doesn't > > > have to access foreign memory) but didn't find anything. > > > > I'm out of ideas. > > John, do you know if this is a newbus limitation or if it can be > > worked around ? > > I assume it is possible somehow, I am just too stupid (it is the first > driver I wrote). John, for easy reference, here is my initial message: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html > > Please remember all, that I need the access to the acpi0 memory location > only for a few reads during probing/attaching, not later. > > I have also read somewhere that, when resources are allocated, the > system "walks up" the device tree until it finds the resource. Since > my driver is below hostb0 and hostb0 is below acpi0 I thought it > should work but it doesn't.. I think you want to probably patch hostb0 to let bus_set_resource() work and then use that. You could also just explicitly by-pass hostb0 and allocate a resource from its parent as a quick hack. The PCI bus should pass the requst up to acpi0. That is, do: BUS_ALLOC_RESOURCE(device_get_parent(device_get_parent(dev)), dev, ...); instead of bus_alloc_resource(dev, ...); -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 21 02:33:22 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 853E3106566B; Tue, 21 Jul 2009 02:33:22 +0000 (UTC) (envelope-from prvs=1453d97ea3=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 62EA18FC1C; Tue, 21 Jul 2009 02:33:21 +0000 (UTC) (envelope-from prvs=1453d97ea3=killing@multiplay.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1248142973; x=1248747773; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type; bh=akTX10UOSEfiont9elTbEmzCE5OPBquAAJVyjRlMXx8=; b=bLsewBlZo4+avz/XilJtwDqZ9ZvLTXB4pMjmbkvtOrfgTSKZ2lQSSJSj8MeXDe uUp8VWQWojQrmilorLKWkcF9KNr+VzJi43GXzegjSB6faxFv+qifmo7FefC2cdhl ALKtKuRFNB9Llc4ewaVbVFb6A0ICwmeEjpdyatKENsHv8= X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 21 Jul 2009 03:22:53 +0100 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50007899215.msg; Tue, 21 Jul 2009 03:22:52 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 21 Jul 2009 03:22:52 +0100 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.96 X-Return-Path: prvs=1453d97ea3=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <415DF72E19E24DBEA840BAB408A3442E@multiplay.co.uk> From: "Steven Hartland" To: "Adam Jacob Muller" , "Karl Fischer" References: <39DC135F7F0571489196E0B6F5D58B4A03B460D0@MWBEXCH.mweb.com> Date: Tue, 21 Jul 2009 03:22:47 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0307_01CA09B2.850F46C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Rudi Kramer - MWEB , freebsd-amd64@freebsd.org Subject: Re: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 02:33:23 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0307_01CA09B2.850F46C0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Did anyone ever get anywhere with this, just retried with 8.0-BETA2 and still the same hangs as depicted in the attached screen shots. Sorry got no serial console :( Would like to get this working if possible so anything I can try to gain some more info on this issue? Regards Steve ----- Original Message ----- From: "Adam Jacob Muller" > > Anyone ever get this to work? Perhaps this was fixed in a newer > FreeBSD? Have some M600 that i'd like to get FreeBSD running on :) > > hint.apic.0.disabled seemed to change things a bit, it would reach ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. ------=_NextPart_000_0307_01CA09B2.850F46C0-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 21 05:02:33 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 228EF106564A for ; Tue, 21 Jul 2009 05:02:33 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id D25008FC1C for ; Tue, 21 Jul 2009 05:02:32 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: by yxe11 with SMTP id 11so4525853yxe.3 for ; Mon, 20 Jul 2009 22:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Eg4o7MNyVWCcqqDLFVrtJ8ClEaZqI58B2grH//0OgN0=; b=WQIefRuagFBVly/UP9hSLC9AH13cEuTVDMjPktj2lQYiif0AUb0qPZejRwVTH/y917 q1egFUkghwKa7VNaQfNoFSRZgUZqTv/7bAho1wYqWS53sByQ1Pnn0A0NfApQ8fMf45aD LSzOnbiF8Goyqxb3d0yHlNSH6wyVAyAQLF49U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MLZH2U+//7btRJXAR6z5fmcukwG03QJQLA7mWAGqeso/MoWsOsk/JMVM3Ryk8pVC58 l1nxihVM93gFpP10rbFUWTDqacK/8WDSZyotr9jW1ayCkH99BiioHP/TLQblw49VIDn1 BFfMH1sZIecf2JKOmwADMYS1erOeg1tR0h0xU= MIME-Version: 1.0 Received: by 10.100.141.15 with SMTP id o15mr7351076and.20.1248150870725; Mon, 20 Jul 2009 21:34:30 -0700 (PDT) Date: Tue, 21 Jul 2009 12:34:29 +0800 Message-ID: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> From: "Shaowei Wang (wsw)" To: hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: llvm/clang a tool chain or just a compiler for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 05:02:33 -0000 Hi, hackers! Recently I am playing the clangbsd i386 branch and it works. I've noticed that clang using gcc to linking object code or even doing assembling. clang from FreeBSD perspective will be a whole compiler tool chain or just another C/C++ compiler (may using system's [GNU]as and [GNU]ld) ? Thanks -wsw From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 21 13:36:49 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7982B106564A for ; Tue, 21 Jul 2009 13:36:49 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 3378B8FC15 for ; Tue, 21 Jul 2009 13:36:49 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id CF4ED9CB067; Tue, 21 Jul 2009 15:17:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sQyTrxj3OEQ; Tue, 21 Jul 2009 15:17:36 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 121159CB13C; Tue, 21 Jul 2009 15:17:36 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n6LDHZB6019133; Tue, 21 Jul 2009 15:17:35 +0200 (CEST) (envelope-from rdivacky) Date: Tue, 21 Jul 2009 15:17:35 +0200 From: Roman Divacky To: "Shaowei Wang (wsw)" Message-ID: <20090721131735.GA18929@freebsd.org> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: hackers@freebsd.org Subject: Re: llvm/clang a tool chain or just a compiler for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 13:36:49 -0000 On Tue, Jul 21, 2009 at 12:34:29PM +0800, Shaowei Wang (wsw) wrote: > Hi, hackers! > > Recently I am playing the clangbsd i386 branch and it works. I've noticed > that clang using gcc to linking object code or even doing assembling. > > clang from FreeBSD perspective will be a whole compiler tool chain or just > another C/C++ compiler (may using system's [GNU]as and [GNU]ld) ? llvm people are working on "mc" which is a native assembler/dissasembler. so the only part of the toolchain missing will be linker... now we need as/ld (and gnu driver that knows how to talk to them) roman From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 21 19:20:45 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D75B106566C for ; Tue, 21 Jul 2009 19:20:45 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id A2C538FC13 for ; Tue, 21 Jul 2009 19:20:44 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id B5C861CFA5; Tue, 21 Jul 2009 21:20:43 +0200 (CEST) Date: Tue, 21 Jul 2009 21:20:43 +0200 From: Ed Schouten To: "Shaowei Wang (wsw)" Message-ID: <20090721192043.GK68469@hoeg.nl> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jIYo0VRlfdMI9fLa" Content-Disposition: inline In-Reply-To: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Hackers Subject: Re: llvm/clang a tool chain or just a compiler for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 19:20:45 -0000 --jIYo0VRlfdMI9fLa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, * Shaowei Wang (wsw) wrote: > Recently I am playing the clangbsd i386 branch and it works. I've noticed > that clang using gcc to linking object code or even doing assembling. No, this is not true. It calls ld and as to do the linking/assembling. Some stuff in the clangbsd branch still gets built with GCC, because of regressions/missing features of Clang. Yours, --=20 Ed Schouten WWW: http://80386.nl/ --jIYo0VRlfdMI9fLa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpmFQsACgkQ52SDGA2eCwUA4gCfQzJ/6u48YS2KdWFjBZotZgfK A6oAn2j0oaPpzlVB40npEJ+NQjxCRERA =pken -----END PGP SIGNATURE----- --jIYo0VRlfdMI9fLa-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 21 22:43:23 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4420B106564A for ; Tue, 21 Jul 2009 22:43:23 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out3.uni-muenster.de (ZIVM-OUT3.UNI-MUENSTER.DE [128.176.192.18]) by mx1.freebsd.org (Postfix) with ESMTP id CDE228FC25 for ; Tue, 21 Jul 2009 22:43:22 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.43,242,1246831200"; d="scan'208";a="9041894" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay3.uni-muenster.de with ESMTP; 22 Jul 2009 00:43:21 +0200 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 2A6171B07E1; Wed, 22 Jul 2009 00:43:21 +0200 (CEST) Date: Wed, 22 Jul 2009 00:43:20 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: checking number of parallel ports installed and their port adresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 22:43:23 -0000 hi there, i've written an app in c (and a bit of asm) which needs to do raw parallel port io using the i386 opcodes in/out. to get the number of available parallel ports installed and their addresses i open and mmap /dev/mem and read the address-values from the BIOS area @ 0x408. is there a better way to find out the number of parallel ports installed and their addresses? cheers. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 01:18:47 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF75C1065670 for ; Wed, 22 Jul 2009 01:18:47 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 777FC8FC0C for ; Wed, 22 Jul 2009 01:18:47 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so1620509and.13 for ; Tue, 21 Jul 2009 18:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MzcA1sMpwDgCoExawXH9wHQ/XdVhPpBytKxLAE6oAMg=; b=uJJ/FT11UgW/LjgEfwoflNKWo0enfggWgZnbmW/j4svesK6TwXrBmaMrmHKUidxI9d msL/cvpoVyAP2sNbQ3y71Vy3VRC8HRGK7+fS+Ct2tDFjTeZNJdBFYnAjaqQLnX3OocaL SvWLvfycgnmXvSmWLORD/Kpp1bXdjPcaxddnQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FhXdbCYBz4y7+t7i/688pEG8YryBgZ+GXznEaDF/m080db4U/xASe9t+xYiL2BGNsR qO3nNyJylI+gdfYUHyXuzGQMRws+sPUOt08azQqjuQBzf0+9dN/cSOEkgAdLilt7nut9 e8+Cl/Uj8vT8X7i69xoqQeYPbsH3Gpj9BY6Ig= MIME-Version: 1.0 Received: by 10.100.201.7 with SMTP id y7mr455159anf.121.1248225526496; Tue, 21 Jul 2009 18:18:46 -0700 (PDT) In-Reply-To: <20090721131735.GA18929@freebsd.org> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> Date: Wed, 22 Jul 2009 09:18:46 +0800 Message-ID: <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> From: "Shaowei Wang (wsw)" To: Roman Divacky Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: hackers@freebsd.org Subject: Re: llvm/clang a tool chain or just a compiler for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 01:18:48 -0000 On Tue, Jul 21, 2009 at 9:17 PM, Roman Divacky wrote: > On Tue, Jul 21, 2009 at 12:34:29PM +0800, Shaowei Wang (wsw) wrote: > > Hi, hackers! > > > > Recently I am playing the clangbsd i386 branch and it works. I've noticed > > that clang using gcc to linking object code or even doing assembling. > > > > clang from FreeBSD perspective will be a whole compiler tool chain or > just > > another C/C++ compiler (may using system's [GNU]as and [GNU]ld) ? > > llvm people are working on "mc" which is a native assembler/dissasembler. > so the only part of the toolchain missing will be linker... now we > need as/ld (and gnu driver that knows how to talk to them) So what's the direction? Are we going to cut off all the GNU compiler tool chains and use the llvm/clang when it's mature. > > > roman > From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 01:38:46 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 260C61065670 for ; Wed, 22 Jul 2009 01:38:46 +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 D7D0E8FC13 for ; Wed, 22 Jul 2009 01:38:45 +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 1C5FE6D418; Wed, 22 Jul 2009 03:38:45 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id E4F36844B5; Wed, 22 Jul 2009 03:38:44 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Shaowei Wang \(wsw\)" References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> Date: Wed, 22 Jul 2009 03:38:44 +0200 In-Reply-To: <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> (Shaowei Wang's message of "Wed, 22 Jul 2009 09:18:46 +0800") Message-ID: <864ot5jy3f.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Roman Divacky , hackers@freebsd.org Subject: Re: llvm/clang a tool chain or just a compiler for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 01:38:46 -0000 "Shaowei Wang (wsw)" writes: > So what's the direction? Are we going to cut off all the GNU compiler > tool chains and use the llvm/clang when it's mature. Who's "we"? Anyway, LLVM *isn't* mature, and it probably won't be for years, if ever, so there's no point in asking. If it ever reaches a point where it covers our needs, and it's still under an acceptable license, and somebody sits down and does the work and assumes the responsibility, and portsmgr@ doesn't have a conniption because it breaks half the ports tree, and core@ approves, and a majority of developers approve, including those who think we should run with pcc instead but can't be arsed to do the work, then maybe. At this point, speculating about it is just a waste of time and electrons. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 01:59:34 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84519106566B; Wed, 22 Jul 2009 01:59:34 +0000 (UTC) (envelope-from kitchetech@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 299CC8FC0A; Wed, 22 Jul 2009 01:59:34 +0000 (UTC) (envelope-from kitchetech@gmail.com) Received: by yxe11 with SMTP id 11so5634728yxe.3 for ; Tue, 21 Jul 2009 18:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=IGoltMo3XNebMwvvZjfEPUolPOedVcp2ukqo7dV8ufI=; b=cuyALlJ0NVIZLqMsy7oov1bEwbNwt37AMk/NZv7nqRURquTtmTXXRByXPByThIR6ax Qyos5BxKTr686Sv6+QBB9T61wFhza5UnHHpAWxpvf6LSLWM36+FhUbZfhtEQWDgQIe+Q 13saDdTXE/1uc6ejxpatgEk5FRF9H8la3kz9w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=IGbyzJR3TxjaG4KWy9ZbRDc6OhW1I7JGFIdRRk12wTC3+HoKNVjdkcGL2t5pmSlE/1 jL3zuGYKlM7LZNZ5Yorlu48uRQJyr1dMUFBAyv7Nke+X5K0bUmXe/QrE1LvkfPrt/jcf EG8oS9kCgCZldVKSOgbsaJci6DQnLKVXeJStE= MIME-Version: 1.0 Received: by 10.100.172.16 with SMTP id u16mr488731ane.85.1248226055063; Tue, 21 Jul 2009 18:27:35 -0700 (PDT) In-Reply-To: <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> From: matt donovan Date: Tue, 21 Jul 2009 21:27:15 -0400 Message-ID: <28283d910907211827o3189760y6531f9cebb081adf@mail.gmail.com> To: "Shaowei Wang (wsw)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Roman Divacky , hackers@freebsd.org Subject: Re: llvm/clang a tool chain or just a compiler for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 01:59:34 -0000 On Tue, Jul 21, 2009 at 9:18 PM, Shaowei Wang (wsw) wrote: > On Tue, Jul 21, 2009 at 9:17 PM, Roman Divacky > wrote: > > > On Tue, Jul 21, 2009 at 12:34:29PM +0800, Shaowei Wang (wsw) wrote: > > > Hi, hackers! > > > > > > Recently I am playing the clangbsd i386 branch and it works. I've > noticed > > > that clang using gcc to linking object code or even doing assembling. > > > > > > clang from FreeBSD perspective will be a whole compiler tool chain or > > just > > > another C/C++ compiler (may using system's [GNU]as and [GNU]ld) ? > > > > llvm people are working on "mc" which is a native assembler/dissasembler. > > so the only part of the toolchain missing will be linker... now we > > need as/ld (and gnu driver that knows how to talk to them) > > > So what's the direction? Are we going to cut off all the GNU compiler tool > chains and use the llvm/clang when it's mature. > > > > > > > > > roman > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > Well I did build 8.0-Beta2 with clang the latest svn though seems to have broke the usb compile for me. Most likely due to a commit that was done but clang is pretty mature to compile most things but for now I just have CC=/usr/bin/gcc in my make.conf to build ports From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 07:21:58 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C35FD106564A for ; Wed, 22 Jul 2009 07:21:58 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 7C9478FC17 for ; Wed, 22 Jul 2009 07:21:57 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 87CFE9CB1EF; Wed, 22 Jul 2009 09:20:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzZDd8ch9d8C; Wed, 22 Jul 2009 09:19:56 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 3A9F19CB408; Wed, 22 Jul 2009 09:19:56 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n6M7JuoS090655; Wed, 22 Jul 2009 09:19:56 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 22 Jul 2009 09:19:56 +0200 From: Roman Divacky To: "Shaowei Wang (wsw)" Message-ID: <20090722071956.GA89631@freebsd.org> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: hackers@freebsd.org Subject: Re: llvm/clang a tool chain or just a compiler for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 07:21:59 -0000 On Wed, Jul 22, 2009 at 09:18:46AM +0800, Shaowei Wang (wsw) wrote: > On Tue, Jul 21, 2009 at 9:17 PM, Roman Divacky wrote: > > > On Tue, Jul 21, 2009 at 12:34:29PM +0800, Shaowei Wang (wsw) wrote: > > > Hi, hackers! > > > > > > Recently I am playing the clangbsd i386 branch and it works. I've noticed > > > that clang using gcc to linking object code or even doing assembling. > > > > > > clang from FreeBSD perspective will be a whole compiler tool chain or > > just > > > another C/C++ compiler (may using system's [GNU]as and [GNU]ld) ? > > > > llvm people are working on "mc" which is a native assembler/dissasembler. > > so the only part of the toolchain missing will be linker... now we > > need as/ld (and gnu driver that knows how to talk to them) > > > So what's the direction? Are we going to cut off all the GNU compiler tool > chains and use the llvm/clang when it's mature. there is no official stand on this but I guess the framework to enable optional usage of clang as "cc" instead of gcc might be committed "soon"... but that does not switch anything. there's quite a lot of work still to do (on both fbsd and clang/llvm side). things have stalled a little recently - it's summer, people got distracted, code freeze etc. but at least I am going to push some more work on this after the freeze/summer... this is my personal view not representing anything official in FreeBSD roman From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 07:30:45 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BD23106564A; Wed, 22 Jul 2009 07:30:45 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id CCA018FC15; Wed, 22 Jul 2009 07:30:44 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: by yxe11 with SMTP id 11so8109yxe.3 for ; Wed, 22 Jul 2009 00:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=80xDA8VTRo4Kbh7rhXf+3UwNymd3dwzm0KP7i9bMYjE=; b=oud2wErtWFsjieM+BanS4w666jboUCJk563aJzX0FpjSODToxMlatzgcyeqZNCxP7x rB/VvlwJBtAckiBqWSVNeyN2ULbTypZUV0sZyoaG1ETjm9319gOtCp9asDUGa/Ipuk4W K2PT8JKCW3QiN12DJMhBVpk+h8rNqICXWKw2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WZ0Xw3nbAiMRcvGGApq5GZlwdSDhYFBiqQ98XiTidz1CKCEmSwPeDNug9vFMo5KLHd kZVM1d4SBExrueXBw4WFnytAYKE5VxA9uCdudXosrq4cedskHXbvKeJRLfQ5SzkHJek5 pYhWw0GDQfEyMrdnpb+D8575xdP8I1CtZLpjk= MIME-Version: 1.0 Received: by 10.100.110.9 with SMTP id i9mr752027anc.130.1248247844112; Wed, 22 Jul 2009 00:30:44 -0700 (PDT) In-Reply-To: <20090722071956.GA89631@freebsd.org> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <20090722071956.GA89631@freebsd.org> Date: Wed, 22 Jul 2009 15:30:44 +0800 Message-ID: <2e566b9e0907220030p6e5f0233qcc527acdd5c55dfc@mail.gmail.com> From: "Shaowei Wang (wsw)" To: Roman Divacky Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: hackers@freebsd.org Subject: Re: llvm/clang a tool chain or just a compiler for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 07:30:45 -0000 On Wed, Jul 22, 2009 at 3:19 PM, Roman Divacky wrote: > On Wed, Jul 22, 2009 at 09:18:46AM +0800, Shaowei Wang (wsw) wrote: > > On Tue, Jul 21, 2009 at 9:17 PM, Roman Divacky > wrote: > > > > > On Tue, Jul 21, 2009 at 12:34:29PM +0800, Shaowei Wang (wsw) wrote: > > > > Hi, hackers! > > > > > > > > Recently I am playing the clangbsd i386 branch and it works. I've > noticed > > > > that clang using gcc to linking object code or even doing assembling. > > > > > > > > clang from FreeBSD perspective will be a whole compiler tool chain or > > > just > > > > another C/C++ compiler (may using system's [GNU]as and [GNU]ld) ? > > > > > > llvm people are working on "mc" which is a native > assembler/dissasembler. > > > so the only part of the toolchain missing will be linker... now we > > > need as/ld (and gnu driver that knows how to talk to them) > > > > > > So what's the direction? Are we going to cut off all the GNU compiler > tool > > chains and use the llvm/clang when it's mature. > > there is no official stand on this but I guess the framework to enable > optional > usage of clang as "cc" instead of gcc might be committed "soon"... This sounds great. > > but that does not switch anything. there's quite a lot of work still to do > (on both fbsd and clang/llvm side). things have stalled a little recently > - it's summer, people got distracted, code freeze etc. but at least I am > going > to push some more work on this after the freeze/summer... > Yeah, I know. still a lot of work... > > this is my personal view not representing anything official in FreeBSD > > roman > From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 14:18:03 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F10A5106564A for ; Wed, 22 Jul 2009 14:18:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 496A48FC0C for ; Wed, 22 Jul 2009 14:18:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 n6MEHuS3004246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 17:17:56 +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.3/8.14.3) with ESMTP id n6MEHush081467; Wed, 22 Jul 2009 17:17:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n6MEHuqG081466; Wed, 22 Jul 2009 17:17:56 +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: Wed, 22 Jul 2009 17:17:56 +0300 From: Kostik Belousov To: Dag-Erling Sm??rgrav Message-ID: <20090722141756.GQ55190@deviant.kiev.zoral.com.ua> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <864ot5jy3f.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KVppSDP0TWLrbE6f" Content-Disposition: inline In-Reply-To: <864ot5jy3f.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at 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 Cc: Roman Divacky , hackers@freebsd.org, "Shaowei Wang \(wsw\)" Subject: Re: llvm/clang a tool chain or just a compiler for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 14:18:04 -0000 --KVppSDP0TWLrbE6f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 22, 2009 at 03:38:44AM +0200, Dag-Erling Sm??rgrav wrote: > "Shaowei Wang (wsw)" writes: > > So what's the direction? Are we going to cut off all the GNU compiler > > tool chains and use the llvm/clang when it's mature. >=20 > Who's "we"? >=20 > Anyway, LLVM *isn't* mature, and it probably won't be for years, if > ever, so there's no point in asking. If it ever reaches a point where > it covers our needs, and it's still under an acceptable license, and > somebody sits down and does the work and assumes the responsibility, and > portsmgr@ doesn't have a conniption because it breaks half the ports > tree, and core@ approves, and a majority of developers approve, > including those who think we should run with pcc instead but can't be > arsed to do the work, then maybe. At this point, speculating about it > is just a waste of time and electrons. I believe that the nearest action that is quite reasonable and profitable by its own merit is divorcing base compiler and compiler used to build ports. Even if this means that we would "only" have different versions of gcc. --KVppSDP0TWLrbE6f Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpnH5MACgkQC3+MBN1Mb4iYeACgpAG0oEquVhg02QooKh+u6j/T 0SwAnR8TnKiMBcragEL9oT+PA27JoGzn =3Vfy -----END PGP SIGNATURE----- --KVppSDP0TWLrbE6f-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 15:49:12 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC08C106564A; Wed, 22 Jul 2009 15:49:12 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 326E38FC0C; Wed, 22 Jul 2009 15:49:11 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: by bwz19 with SMTP id 19so264617bwz.43 for ; Wed, 22 Jul 2009 08:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=a4pdNT9MSTYlnMnUq8UXAz5ojNB7CWxyqSOK6GvgW7o=; b=V+raXF1+QZNTafmari1tH/cIvdszPlsDHZ8xI06yUgfZJKj6tf/l2mmh74NplaNTvH 5QhRnByp8bwEqMpshhNfWpVJR+WxCwRmDqLuJhpnTOTD7aXek9l1B4Ecit19JuG7a3/f If1eu06mr7outqIa/wm5v7BdQZlGSiqFi/Lek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IeWCdTOsU3jvdxbYkP64DOMLY44/Wm0Mj43dL665H+5kiTpKr2DQQcstYdzea3tpXe 5p3Tvrcw3fblb8KIG9mJPwzkMabbPMAes9/H2VfI/yX0lLpUXyNkzxomLiJ7FefXZNxd StmSg/6zYd2wyj59qKb+V/up3PVQvX0YURBQE= MIME-Version: 1.0 Received: by 10.204.78.142 with SMTP id l14mr999910bkk.33.1248276197429; Wed, 22 Jul 2009 08:23:17 -0700 (PDT) In-Reply-To: <20090722141756.GQ55190@deviant.kiev.zoral.com.ua> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <864ot5jy3f.fsf@ds4.des.no> <20090722141756.GQ55190@deviant.kiev.zoral.com.ua> Date: Wed, 22 Jul 2009 19:23:17 +0400 Message-ID: <3cb459ed0907220823q2376f545x44c0972a989a4b72@mail.gmail.com> From: Alexander Churanov To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Dag-Erling Sm??rgrav , Roman Divacky , hackers@freebsd.org, "Shaowei Wang \(wsw\)" Subject: Re: llvm/clang a tool chain or just a compiler for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 15:49:13 -0000 2009/7/22 Kostik Belousov : > I believe that the nearest action that is quite reasonable and > profitable by its own merit is divorcing base compiler and compiler used > to build ports. Even if this means that we would "only" have different > versions of gcc. > I know some ports using "USE_GCC" knob of /usr/ports/Mk/bsd.gcc.mk . Is this the same as you suggest? Alexander Churanov From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 16:05:57 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 028D8106564A; Wed, 22 Jul 2009 16:05:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4E8528FC1F; Wed, 22 Jul 2009 16:05:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 n6MG5lCN011265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 19:05:47 +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.3/8.14.3) with ESMTP id n6MG5leR083845; Wed, 22 Jul 2009 19:05:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n6MG5liv083844; Wed, 22 Jul 2009 19:05:47 +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: Wed, 22 Jul 2009 19:05:47 +0300 From: Kostik Belousov To: Alexander Churanov Message-ID: <20090722160547.GU55190@deviant.kiev.zoral.com.ua> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <864ot5jy3f.fsf@ds4.des.no> <20090722141756.GQ55190@deviant.kiev.zoral.com.ua> <3cb459ed0907220823q2376f545x44c0972a989a4b72@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+Zdg+YhINNrRV9Ds" Content-Disposition: inline In-Reply-To: <3cb459ed0907220823q2376f545x44c0972a989a4b72@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at 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 Cc: Dag-Erling Sm??rgrav , Roman Divacky , hackers@freebsd.org, "Shaowei Wang \(wsw\)" Subject: Re: llvm/clang a tool chain or just a compiler for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 16:05:57 -0000 --+Zdg+YhINNrRV9Ds Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 22, 2009 at 07:23:17PM +0400, Alexander Churanov wrote: > 2009/7/22 Kostik Belousov : > > I believe that the nearest action that is quite reasonable and > > profitable by its own merit is divorcing base compiler and compiler used > > to build ports. Even if this means that we would "only" have different > > versions of gcc. > > >=20 > I know some ports using "USE_GCC" knob of /usr/ports/Mk/bsd.gcc.mk . > Is this the same as you suggest? No. And this was actually not my idea. The proposal is to have portmgr-selected and approved version of gcc, installed from port and used to build ports. The base (g)cc is used only to build base. Such divorce seems to be beneficial both to base compiler, and for ports. --+Zdg+YhINNrRV9Ds Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpnONoACgkQC3+MBN1Mb4iWogCeK/wrVE248aYpNklUpFLMsX6F jQ4An3skcIt3a66e8/p/ZHRLKff5yPpS =es35 -----END PGP SIGNATURE----- --+Zdg+YhINNrRV9Ds-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 16:17:08 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E76371065674 for ; Wed, 22 Jul 2009 16:17:08 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 6996F8FC13 for ; Wed, 22 Jul 2009 16:17:08 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by bwz19 with SMTP id 19so282165bwz.43 for ; Wed, 22 Jul 2009 09:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=5Nfx9gABPZC7o96B89KD21tThZaE0BFLJQhQCbKNs2w=; b=Jm5BtIEI1IqY4tvDMCk3xJsaVZTO+nPaS4n5iyQdmtHSeevgYpo0lQ4HLblIxNN2lR yIizK4tohss4ilKBpakrS2Viv/dSEOJFqI5jQrQYIvgqJZYfWbkI1hnzWdtQsOamyfA4 c+NOKtdA33GDbejny230y/2U54zq6ootnsQQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=qWJGa68Q1vNBK6iUGhKQwn1cFGsC94nQs5dmpIDpLAtQ2FVLkFmQp3LqMJacUfU35z /qzkAUmJGOoX0Mss4PvoPp9nzWrREVVVoJWwMNNyDG3oDvNwZtKvQBoXt+l1jnQGQPsy B6o7Gw0qmMG+EOzEEAx+OXnImc0X1lj4Drijo= MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.204.116.15 with SMTP id k15mr988644bkq.111.1248277998451; Wed, 22 Jul 2009 08:53:18 -0700 (PDT) In-Reply-To: <20090722141756.GQ55190@deviant.kiev.zoral.com.ua> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <864ot5jy3f.fsf@ds4.des.no> <20090722141756.GQ55190@deviant.kiev.zoral.com.ua> From: Igor Mozolevsky Date: Wed, 22 Jul 2009 16:52:58 +0100 X-Google-Sender-Auth: fb96929bf9398be8 Message-ID: To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: llvm/clang a tool chain or just a compiler for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 16:17:09 -0000 2009/7/22 Kostik Belousov : > I believe that the nearest action that is quite reasonable and > profitable by its own merit is divorcing base compiler and compiler used > to build ports. Even if this means that we would "only" have different > versions of gcc. On a similar note, has anyone one tried clang + yasm? Cheers, -- Igor From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 16:20:38 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ED50106566B; Wed, 22 Jul 2009 16:20:38 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id C06718FC18; Wed, 22 Jul 2009 16:20:37 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id A0F7D1CF8E; Wed, 22 Jul 2009 18:20:36 +0200 (CEST) Date: Wed, 22 Jul 2009 18:20:36 +0200 From: Ed Schouten To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20090722162036.GO68469@hoeg.nl> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <864ot5jy3f.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OQhbRXNHSL5w/5po" Content-Disposition: inline In-Reply-To: <864ot5jy3f.fsf@ds4.des.no> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Roman Divacky , FreeBSD Hackers , "Shaowei Wang \(wsw\)" Subject: Re: llvm/clang a tool chain or just a compiler for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 16:20:38 -0000 --OQhbRXNHSL5w/5po Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Dag-Erling Sm=F8rgrav wrote: > "Shaowei Wang (wsw)" writes: > > So what's the direction? Are we going to cut off all the GNU compiler > > tool chains and use the llvm/clang when it's mature. >=20 > Who's "we"? >=20 > Anyway, LLVM *isn't* mature, and it probably won't be for years, if > ever, so there's no point in asking. Even though "if ever" sounds a little bit pessimistic, I agree. Unfortunately I'm busy working on other things the last couple of weeks/months, but the biggest problem with LLVM/Clang right now is that the latest release on the website is practically useless to us. I've been tracking SVN, but each time I decide to upgrade sources, I get yet another regression, which means I have to file bug reports. I think I already filed 50-60 bug reports. For some reason there has been a lot of talking, but no hacking. It takes a lot of work to maintain ClangBSD, at least more than I'm willing to spend on it right now. --=20 Ed Schouten WWW: http://80386.nl/ --OQhbRXNHSL5w/5po Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpnPFQACgkQ52SDGA2eCwW57gCZAcpB/H+0bKEvySrCXqbtIhLx eBcAnjMxALtcqHeXbpLV+zJwHJ6enOkP =VybC -----END PGP SIGNATURE----- --OQhbRXNHSL5w/5po-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 16:29:26 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 931DE106566C for ; Wed, 22 Jul 2009 16:29:26 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1CE9F8FC13 for ; Wed, 22 Jul 2009 16:29:26 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id CF86E19927D; Wed, 22 Jul 2009 18:29:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id C097F199256; Wed, 22 Jul 2009 18:29:21 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id AB6B8199250; Wed, 22 Jul 2009 18:29:21 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2FP1HF244) with ESMTP id 2009072218292019-110895 ; Wed, 22 Jul 2009 18:29:20 +0200 Received: by wep4035 (sSMTP sendmail emulation); Wed, 22 Jul 2009 18:29:20 +0200 Date: Wed, 22 Jul 2009 18:29:20 +0200 From: Alexey Shuvaev To: Alexander Best Message-ID: <20090722162920.GA57243@wep4035.physik.uni-wuerzburg.de> Mail-Followup-To: Alexander Best , freebsd-hackers@FreeBSD.org References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: Universitaet Wuerzburg X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 07/22/2009 06:29:20 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 07/22/2009 06:29:20 PM, Serialize complete at 07/22/2009 06:29:20 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: freebsd-hackers@FreeBSD.org Subject: Re: checking number of parallel ports installed and their port adresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 16:29:26 -0000 On Wed, Jul 22, 2009 at 12:43:20AM +0200, Alexander Best wrote: > hi there, > > i've written an app in c (and a bit of asm) which needs to do raw parallel > port io using the i386 opcodes in/out. to get the number of available parallel > ports installed and their addresses i open and mmap /dev/mem and read the > address-values from the BIOS area @ 0x408. is there a better way to find out > the number of parallel ports installed and their addresses? > Why not to use /dev/ppi interface? man 4 ppi It is in GENERIC kernel. You don't need assembler then. You can look at your dmesg to count all ppc parallel ports: [snip] ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 [snip] Alexey. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 19:31:57 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 311331065677 for ; Wed, 22 Jul 2009 19:31:57 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id B7F688FC1B for ; Wed, 22 Jul 2009 19:31:56 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.43,248,1246831200"; d="scan'208";a="219401339" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay2.uni-muenster.de with ESMTP; 22 Jul 2009 21:31:55 +0200 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 231641B0751; Wed, 22 Jul 2009 21:31:55 +0200 (CEST) Date: Wed, 22 Jul 2009 21:31:54 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Alexey Shuvaev Message-ID: In-Reply-To: <20090722162920.GA57243@wep4035.physik.uni-wuerzburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: checking number of parallel ports installed and their port adresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 19:31:59 -0000 the ppi manual states that using ioctl with /dev/ppi is extremely slow. i need the parallel port to be really fast. i need to communicate with a device that uses asynchronous transfer at a rate of ~ 2 mhz. so i need the full ISA bus speed to be able to push/pull data to/from the parallel port without any delays. timing is really critical. if there's a lot of work to do for the scheduler and the io calls get queued too long the transfer will fail. plus i want the app to be linux compatible and i don't think ppi exists on linux. actually i meant: how can i check the available parallel ports from within my app? is there a syscall i can use or something like that? cheers. alex Alexey Shuvaev schrieb am 2009-07-22: > On Wed, Jul 22, 2009 at 12:43:20AM +0200, Alexander Best wrote: > > hi there, > > i've written an app in c (and a bit of asm) which needs to do raw > > parallel > > port io using the i386 opcodes in/out. to get the number of > > available parallel > > ports installed and their addresses i open and mmap /dev/mem and > > read the > > address-values from the BIOS area @ 0x408. is there a better way to > > find out > > the number of parallel ports installed and their addresses? > Why not to use /dev/ppi interface? > man 4 ppi > It is in GENERIC kernel. > You don't need assembler then. > You can look at your dmesg to count all ppc parallel ports: > [snip] > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on > acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > ppc0: [ITHREAD] > ppbus0: on ppc0 > plip0: on ppbus0 > plip0: [ITHREAD] > lpt0: on ppbus0 > lpt0: [ITHREAD] > lpt0: Interrupt-driven port > ppi0: on ppbus0 > [snip] > Alexey. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 20:24:37 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B047D106566C for ; Wed, 22 Jul 2009 20:24:37 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 66B498FC17 for ; Wed, 22 Jul 2009 20:24:37 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id CC0539CB0D9; Wed, 22 Jul 2009 22:22:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPb6LVuKoNLC; Wed, 22 Jul 2009 22:22:36 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 075BA9CB103; Wed, 22 Jul 2009 22:22:36 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n6MKMZUI028479; Wed, 22 Jul 2009 22:22:35 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 22 Jul 2009 22:22:35 +0200 From: Roman Divacky To: Igor Mozolevsky Message-ID: <20090722202235.GA28313@freebsd.org> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <864ot5jy3f.fsf@ds4.des.no> <20090722141756.GQ55190@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Kostik Belousov , hackers@freebsd.org Subject: Re: llvm/clang a tool chain or just a compiler for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 20:24:37 -0000 On Wed, Jul 22, 2009 at 04:52:58PM +0100, Igor Mozolevsky wrote: > 2009/7/22 Kostik Belousov : > > > I believe that the nearest action that is quite reasonable and > > profitable by its own merit is divorcing base compiler and compiler used > > to build ports. Even if this means that we would "only" have different > > versions of gcc. > > > On a similar note, has anyone one tried clang + yasm? I did.. it does not work.... and there is no future in this. clang/llvm is getting native elf writer/assembler really soon From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 20:26:35 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1A331065676 for ; Wed, 22 Jul 2009 20:26:35 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 692178FC29 for ; Wed, 22 Jul 2009 20:26:35 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id E99599CB0D9; Wed, 22 Jul 2009 22:24:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6tcByqhIDRj; Wed, 22 Jul 2009 22:24:34 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 115579CB13C; Wed, 22 Jul 2009 22:24:34 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n6MKOXVH028762; Wed, 22 Jul 2009 22:24:33 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 22 Jul 2009 22:24:33 +0200 From: Roman Divacky To: Ed Schouten Message-ID: <20090722202433.GA28586@freebsd.org> References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <864ot5jy3f.fsf@ds4.des.no> <20090722162036.GO68469@hoeg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090722162036.GO68469@hoeg.nl> User-Agent: Mutt/1.4.2.3i Cc: Dag-Erling Sm?rgrav , FreeBSD Hackers , "Shaowei Wang \(wsw\)" Subject: Re: llvm/clang a tool chain or just a compiler for FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 20:26:36 -0000 On Wed, Jul 22, 2009 at 06:20:36PM +0200, Ed Schouten wrote: > * Dag-Erling Sm?rgrav wrote: > > "Shaowei Wang (wsw)" writes: > > > So what's the direction? Are we going to cut off all the GNU compiler > > > tool chains and use the llvm/clang when it's mature. > > > > Who's "we"? > > > > Anyway, LLVM *isn't* mature, and it probably won't be for years, if > > ever, so there's no point in asking. > > Even though "if ever" sounds a little bit pessimistic, I agree. > > Unfortunately I'm busy working on other things the last couple of > weeks/months, but the biggest problem with LLVM/Clang right now is that > the latest release on the website is practically useless to us. I've > been tracking SVN, but each time I decide to upgrade sources, I get yet > another regression, which means I have to file bug reports. I think I > already filed 50-60 bug reports. > > For some reason there has been a lot of talking, but no hacking. It > takes a lot of work to maintain ClangBSD, at least more than I'm willing > to spend on it right now. I know you disagree with me but from my pov clangbsd is mostly finished. the integration is "just fine". what we need to do now is to get clang/llvm and freebsd sources into shapes so there are no problems compiling freebsd with clang. most of the problems is with clang but there are things to improve in freebsd too. I am working (and others as well) on both. roman From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 22:05:15 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE95F106564A for ; Wed, 22 Jul 2009 22:05:15 +0000 (UTC) (envelope-from ap00@mail.ru) Received: from mx45.mail.ru (mx44.mail.ru [94.100.176.58]) by mx1.freebsd.org (Postfix) with ESMTP id 2AAFA8FC19 for ; Wed, 22 Jul 2009 22:05:14 +0000 (UTC) (envelope-from ap00@mail.ru) Received: from mx33.mail.ru (mx33.mail.ru [94.100.176.47]) by mx45.mail.ru (mPOP.Fallback_MX) with ESMTP id D36B41D249E for ; Wed, 22 Jul 2009 21:40:13 +0400 (MSD) Received: from [91.190.115.253] (port=17274 helo=pstation) by mx33.mail.ru with asmtp id 1MTfnY-000IqQ-00 for freebsd-hackers@FreeBSD.org; Wed, 22 Jul 2009 21:40:12 +0400 Date: Wed, 22 Jul 2009 21:42:21 +0400 From: Anthony Pankov X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) Message-ID: <19939654343.20090722214221@mail.ru> To: freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: Subject: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anthony Pankov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:05:16 -0000 SGID/SUID bits don't work with shell scripts, do they? And no mention in chmod(1,2) manual. -- Best regards, Anthony mailto:ap00@mail.ru From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 23:02:02 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E968106566C for ; Wed, 22 Jul 2009 23:02:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 56FDB8FC1D for ; Wed, 22 Jul 2009 23:02:02 +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 320ABC03DF; Wed, 22 Jul 2009 16:02:02 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 5165F2D6006; Wed, 22 Jul 2009 16:02:01 -0700 (PDT) Message-ID: <4A679A6B.70905@elischer.org> Date: Wed, 22 Jul 2009 16:02:03 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Anthony Pankov References: <19939654343.20090722214221@mail.ru> In-Reply-To: <19939654343.20090722214221@mail.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 23:02:02 -0000 Anthony Pankov wrote: > SGID/SUID bits don't work with shell scripts, do they? No google SUID script security > > And no mention in chmod(1,2) manual. > > > From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 22 23:02:05 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BEA0106566B for ; Wed, 22 Jul 2009 23:02:05 +0000 (UTC) (envelope-from darksoul@darkbsd.org) Received: from shinigami.darkbsd.org (shinigami.darkbsd.org [82.227.96.182]) by mx1.freebsd.org (Postfix) with ESMTP id D3B168FC0A for ; Wed, 22 Jul 2009 23:02:04 +0000 (UTC) (envelope-from darksoul@darkbsd.org) Received: from localhost (localhost [127.0.0.1]) by shinigami.darkbsd.org (Postfix) with ESMTP id 77F485C4A for ; Thu, 23 Jul 2009 00:42:12 +0200 (CEST) Received: from shinigami.darkbsd.org ([127.0.0.1]) by localhost (quasar.darkbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sm-ARtAp+tNq for ; Thu, 23 Jul 2009 00:42:04 +0200 (CEST) Received: from [192.168.0.84] (ilyasviel.darkbsd.org [192.168.0.84]) (Authenticated sender: darksoul) by shinigami.darkbsd.org (Postfix) with ESMTPSA id 9535E5C44 for ; Thu, 23 Jul 2009 00:42:04 +0200 (CEST) Message-ID: <4A6795E7.7020700@darkbsd.org> Date: Thu, 23 Jul 2009 00:42:47 +0200 From: DarkSoul User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org References: <19939654343.20090722214221@mail.ru> In-Reply-To: <19939654343.20090722214221@mail.ru> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD4A4E0D5EA05166AC3E85EFF" X-Mailman-Approved-At: Wed, 22 Jul 2009 23:05:21 +0000 Cc: Subject: Re: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 23:02:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD4A4E0D5EA05166AC3E85EFF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anthony Pankov wrote: > SGID/SUID bits don't work with shell scripts, do they? >=20 > And no mention in chmod(1,2) manual. They don't. One reason for this, is that if they were applied, the following would occur : - execve() syscall reads your script's shebang line, and the script interpreter is executed, receiving the specified arguments along with the script name. - The interpreter then open()s the script file to read it, and run the co= de. The problem you then are faced with, is that you have a time frame defined by the moment between the aforementioned execve() and open(), during which it could be possible to unlink/move/whatever the shell script the interpreter is going to open. You guess where this is going, you have no absolute way of guaranteeing you are executing the file you initially planned on opening because execution/opening/reading is not, and can't be done atomically for shell scripts. Cheers, --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enigD4A4E0D5EA05166AC3E85EFF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpnleoACgkQ24Ql8u6TF2O1tgCfdle8/7o/bupd3ZUOJQ1s+G5l exAAmQHna0uKG23cndYoA8pWfICLDgRa =wxNm -----END PGP SIGNATURE----- --------------enigD4A4E0D5EA05166AC3E85EFF-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 05:44:39 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF574106564A for ; Thu, 23 Jul 2009 05:44:39 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id B819D8FC16 for ; Thu, 23 Jul 2009 05:44:39 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id n6N5D49a070717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jul 2009 22:13:04 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id n6N5D49n070716; Wed, 22 Jul 2009 22:13:04 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA00869; Wed, 22 Jul 09 22:03:47 PDT Date: Wed, 22 Jul 2009 22:00:58 -0700 From: perryh@pluto.rain.com To: freebsd-hackers@freebsd.org Message-Id: <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> In-Reply-To: <4A6795E7.7020700@darkbsd.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: darksoul@darkbsd.org Subject: Re: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 05:44:40 -0000 DarkSoul wrote: > Anthony Pankov wrote: > > SGID/SUID bits don't work with shell scripts, do they? > > They don't. > > ... if they were applied, the following would occur : > - execve() syscall reads your script's shebang line, and > the script interpreter is executed, receiving the specified > arguments along with the script name. > - The interpreter then open()s the script file to read it, > and run the code. > > The problem you then are faced with, is that you have a time > frame defined by the moment between the aforementioned execve() > and open(), during which it could be possible to unlink/move/ > whatever the shell script the interpreter is going to open. > > You guess where this is going, you have no absolute way of > guaranteeing you are executing the file you initially planned > on opening because execution/opening/reading is not, and can't > be done atomically for shell scripts. In principle, it should be possible to fix this exposure by improving the interface between execve() and the interpreter: The execve() syscall already has the script file open to read the shebang line. Leave it open, and ensure that the interpreter receives the open descriptor as fd#3 just as 0, 1, and 2 are already used for stdin, stdout, and stderr. An interpreter supporting this approach would check whether stdscr (fd#3) is already open, and if so read from it instead of open()ing the script file. This should ensure that the script which gets executed is the same inode on which execve() saw the SGID/SUID bits set, even if the filesystem has been changed by the time the interpreter has gotten started. It would be the responsibility of whomever decided to set the SGID/SUID bits on a particular script to ensure that the interpreter involved supports the mechanism. I vaguely recall having seen a similar (or even identical) approach suggested some years ago. It may even have been implemented in some variant of Un*x. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 06:08:40 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1381C106564A for ; Thu, 23 Jul 2009 06:08:40 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mx1.freebsd.org (Postfix) with ESMTP id 87F4F8FC08 for ; Thu, 23 Jul 2009 06:08:39 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n6N68Z5i013781; Thu, 23 Jul 2009 08:08:35 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n6N68Zo6010100; Thu, 23 Jul 2009 08:08:35 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.3/8.14.3) id n6N68ZLj010124; Date: Thu, 23 Jul 2009 08:08:35 +0200 From: Andre Albsmeier To: Doug Ambrisko Message-ID: <20090723060835.GB62628@curry.mchp.siemens.de> References: <20090718133938.GA7802@curry.mchp.siemens.de> <200907221648.n6MGmu58035040@ambrisko.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907221648.n6MGmu58035040@ambrisko.com> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-hackers@freebsd.org, Andre Albsmeier Subject: Re: Reading acpi memory from a driver attached to hostb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 06:08:40 -0000 On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote: > Andre Albsmeier writes: > | On Sat, 18-Jul-2009 at 10:25:06 +0100, Rui Paulo wrote: > | > On 18 Jul 2009, at 09:10, Andre Albsmeier wrote: > | > > | > > On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote: > | > >> Andre Albsmeier wrote: > | > >>> [CC'ing this to Rui Paulo since he tried to help me a while ago] > | > >>> > | > >>> Since my driver is a child of hostb0, I have no idea of how to > | > >>> access > | > >>> acpi0's memory area. Here is a devinfo -r to make things clear: > | > >>> > | > >> ... > | > >>> > | > >>> Earlier, I was given the hint to attach as a child of acpi (see the > | > >>> old mail attached below) but in this case I didn't have access to > | > >>> the > | > >>> hostb registers which I need as well. > | > >>> > | > >>> The only thing I see is: Attach two drivers -- one as child of acpi > | > >>> and another as child of hostb and let them communicate somehow (no > | > >>> idea how to do this). > | > >>> > | > >>> I have also done crazy things like searching for acpi0 and trying > | > >>> to bus_alloc_resource() the memory I am interested in but this also > | > >>> failed. > | > >>> > | > >>> Or is it possible to free(!) somehow the address space from acpi0 > | > >>> and pass it to hostb0 so I can bus_alloc_resource() it? > | > >>> > | > >> > | > >> You can probably make two drivers in one which cooperate to > | > >> allow access to both sets of resources. > | > > > | > > Hmm, that's what I meant by: Attach two drivers -- one as child of > | > > acpi > | > > and another as child of hostb... > | > > > | > > And that's similar to Rui Paulo's suggestion a while ago: > | > > > | > >> You'll probably need to create a fake ACPI child driver to access it. > | > >> > | > >> Create your identify routine with something like: > | > >> > | > >> static void mydriver_identify(driver_t *driver, device_t parent) > | > >> { > | > >> if (device_find_child(parent, "mydriver", -1) == NULL && > | > >> mydriver_match(parent)) > | > >> device_add_child(parent, "mydriver", -1); > | > >> } > | > >> > | > >> mydriver_match() should check if you were given the acpi0 device. > | > > > | > > But in order to attach to acpi0, I need to say > | > > > | > > DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, > | > > NULL ); > | > > > | > > instead of > | > > > | > > DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, > | > > NULL ); > | > > > | > > This way I could attach to acpi but not to hostb anymore.... > | > > > | > > I have searched the net for solutions, I have read newbus-draft.txt > | > > and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all > | > > of these my driver is working on other mainboards where it doesn't > | > > have to access foreign memory) but didn't find anything. > | > > | > I'm out of ideas. > | > John, do you know if this is a newbus limitation or if it can be > | > worked around ? > | > | I assume it is possible somehow, I am just too stupid (it is the first > | driver I wrote). John, for easy reference, here is my initial message: > | > | http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html > | > | Please remember all, that I need the access to the acpi0 memory location > | only for a few reads during probing/attaching, not later. > | > | I have also read somewhere that, when resources are allocated, the > | system "walks up" the device tree until it finds the resource. Since > | my driver is below hostb0 and hostb0 is below acpi0 I thought it > | should work but it doesn't.. > > FWIW, you might look at ipmi(4) especially in some early states since > it can probe and attach in many ways (isa, acpi, pci etc.) and had to > figure out the best way to attach. Also it had various front ends. > If I recall correctly, I did a find for a driver (ie. acpi) then > select the first instance. Once you get that handle then you can > request device resources from it, get the info you need then release > that stuff. However, you won't get the module auto-loading part > that you would get if you created a module that depended on both. > That might get you enough of a hint. Also there are some generic > stuff to read various memory bits like SMBIOS areas etc. This is > used in ipmi(4) as well since the attachment can be defined in SMBIOS. > If you have a specific question, about why the driver did something > I should recall that. The ipmi(4) driver is in fairly clean. There > is some improvements I still need to do on probe/attachment that > causes a bogus ipmi1 at times. Thanks a lot for this interesting information. I see, things are more complicated than I thought. There is no easy way having a quick glance at "foreign" memory during probing. Now I have to figure out how to get the order of probing/attaching done. One thing I could do is: 1. attach mydriver_ACPI to acpi0 2. probe mydriver under hostb0, check if we need access to sysresources from acpi0 (depends on the chipset found). If no, goto 5. 3. ask mydriver_ACPI about stuff I want to know (HOW?) 4. tell mydriver to detach from acpi0 (HOW?) 5. attach mydriver to hostb0 and do my work What I would like more is something like: 1. probe mydriver under hostb0, check if we need access to sysresources from acpi0 (depends on the chipset found). If no, goto 3. 2. ask mydriver_ACPI to attach to acpi0, give me the info I want, detach mydriver_ACPI (HOW?) 3. attach mydriver to hostb0 and do my work Thanks, -Andre From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 07:41:03 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BA7A106564A for ; Thu, 23 Jul 2009 07:41:03 +0000 (UTC) (envelope-from ap00@mail.ru) Received: from mx74.mail.ru (mx74.mail.ru [94.100.176.89]) by mx1.freebsd.org (Postfix) with ESMTP id ECE148FC1A for ; Thu, 23 Jul 2009 07:41:02 +0000 (UTC) (envelope-from ap00@mail.ru) Received: from [91.190.115.253] (port=18539 helo=pstation) by mx74.mail.ru with asmtp id 1MTsvE-0001WA-00 for freebsd-hackers@FreeBSD.org; Thu, 23 Jul 2009 11:41:00 +0400 Date: Thu, 23 Jul 2009 11:43:10 +0400 From: Anthony Pankov X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) Message-ID: <10490103187.20090723114310@mail.ru> To: freebsd-hackers@FreeBSD.org In-Reply-To: <4A679A6B.70905@elischer.org> References: <19939654343.20090722214221@mail.ru> <4A679A6B.70905@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: Subject: Re: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anthony Pankov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 07:41:03 -0000 Thursday, July 23, 2009, 3:02:03 AM, Julian Elischer wrote: JE> google SUID script security Preface: There is a file: rwxr-sr-x some:powerg dothething Run it: ./dothething Make shure that process egid isn't powerg. Resume: I'm too dumb to ask google "SUID script security" with this preface. As a result: May be somebody will correct chmod manual page, my poor english have endowed me with inablity to do this. >> >> And no mention in chmod(1,2) manual. >> >> >> -- Best regards, Anthony mailto:ap00@mail.ru From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 08:18:04 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4412106566B for ; Thu, 23 Jul 2009 08:18:04 +0000 (UTC) (envelope-from j.mckeown@ru.ac.za) Received: from a.mail.ru.ac.za (a.mail.ru.ac.za [IPv6:2001:4200:1010::25:1]) by mx1.freebsd.org (Postfix) with ESMTP id F12728FC17 for ; Thu, 23 Jul 2009 08:18:03 +0000 (UTC) (envelope-from j.mckeown@ru.ac.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ru-msa; d=ru.ac.za; h=Received:From:Organization:To:Subject:Date:User-Agent:References:In-Reply-To:X-Face:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id:X-Virus-Scanned:X-Authenticated-User; b=EQPnfh1q4FfWmeTz2/FiFs0SxyC9ZqRyS+1La3DVa25lclaGjkIDjBeenBQ/ymNFFiV/+uvNAd7dvWD2LDmM4BUYOFq7P6ClbShsSiSDJyYSpOHSNJ2qYz2SNElTVx2X; Received: from vorkosigan.ru.ac.za ([2001:4200:1010:1058:219:d1ff:fe9f:a932]:61551) by a.mail.ru.ac.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTtV4-000OZr-8Q for freebsd-hackers@freebsd.org; Thu, 23 Jul 2009 10:18:02 +0200 From: Jonathan McKeown Organization: Rhodes University To: freebsd-hackers@freebsd.org Date: Thu, 23 Jul 2009 10:18:01 +0200 User-Agent: KMail/1.9.10 References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> In-Reply-To: <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> X-Face: $@VrUx^RHy/}yu]jKf/<4T%/d|F+$j-Ol2"2J$q+%OK1]&/G_S9(=?utf-8?q?HkaQ*=60!=3FYOK=3FY!=27M=60C=0A=09aP=5C9nVPF8Q=7DCilHH8l=3B=7E!4?= =?utf-8?q?2HK6=273lg4J=7Daz?=@1Dqqh:J]M^"YPn*2IWrZON$1+G?oX3@ =?utf-8?q?k=230=0A=0954XDRg=3DYn=5FF-etwot4U=24b?=dTS{i X-Virus-Scanned: a.mail.ru.ac.za (2001:4200:1010::25:1) X-Authenticated-User: s0900137 from vorkosigan.ru.ac.za (2001:4200:1010:1058:219:d1ff:fe9f:a932) using auth_plaintext Subject: Re: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 08:18:05 -0000 On Thursday 23 July 2009 07:00:58 perryh@pluto.rain.com wrote: > DarkSoul wrote: > > Anthony Pankov wrote: > > > SGID/SUID bits don't work with shell scripts, do they? > > > > They don't. [snip description of race condition] > In principle, it should be possible to fix this exposure by > improving the interface between execve() and the interpreter: > > The execve() syscall already has the script file open to read the > shebang line. Leave it open, and ensure that the interpreter > receives the open descriptor as fd#3 just as 0, 1, and 2 are already > used for stdin, stdout, and stderr. An interpreter supporting this > approach would check whether stdscr (fd#3) is already open, and if > so read from it instead of open()ing the script file. This should > ensure that the script which gets executed is the same inode on > which execve() saw the SGID/SUID bits set, even if the filesystem > has been changed by the time the interpreter has gotten started. > It would be the responsibility of whomever decided to set the > SGID/SUID bits on a particular script to ensure that the interpreter > involved supports the mechanism. > > I vaguely recall having seen a similar (or even identical) approach > suggested some years ago. It may even have been implemented in some > variant of Un*x. It's mentioned in the perlsec page of perl's documentation (installed as a manpage on FreeBSD), under Security Bugs, which describes the race condition, and the same fix (keeping the script open and passing /dev/fd/3 rather than closing it and passing the filename). It goes on to say: > Most modern releases of SysVr4 and BSD 4.4 use this approach to avoid the > kernel race condition. Although it would appear not to apply to FreeBSD. Jonathan From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 12:45:29 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5947106564A for ; Thu, 23 Jul 2009 12:45:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 766608FC1E for ; Thu, 23 Jul 2009 12:45:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3147C46B49; Thu, 23 Jul 2009 08:45:29 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 2A64A8A0A2; Thu, 23 Jul 2009 08:45:28 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 23 Jul 2009 08:33:42 -0400 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907230833.43021.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 23 Jul 2009 08:45:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alexey Shuvaev , Alexander Best Subject: Re: checking number of parallel ports installed and their port adresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 12:45:30 -0000 On Wednesday 22 July 2009 3:31:54 pm Alexander Best wrote: > the ppi manual states that using ioctl with /dev/ppi is extremely slow. i need > the parallel port to be really fast. i need to communicate with a device that > uses asynchronous transfer at a rate of ~ 2 mhz. so i need the full ISA bus > speed to be able to push/pull data to/from the parallel port without any > delays. timing is really critical. if there's a lot of work to do for the > scheduler and the io calls get queued too long the transfer will fail. The overhead of ppi is probably in the noise on a modern CPU. I think you should be fine with just using ppi(4). > actually i meant: how can i check the available parallel ports from within my > app? is there a syscall i can use or something like that? You can look for ppcX devices perhaps. The easiest way might be to enable ppi and look for /dev/ppiX devices in /dev. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 12:45:30 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA3481065670 for ; Thu, 23 Jul 2009 12:45:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8DEB68FC19 for ; Thu, 23 Jul 2009 12:45:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 425FD46B4C; Thu, 23 Jul 2009 08:45:30 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 814708A0A3; Thu, 23 Jul 2009 08:45:29 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 23 Jul 2009 08:35:50 -0400 User-Agent: KMail/1.9.7 References: <20090718133938.GA7802@curry.mchp.siemens.de> <200907221648.n6MGmu58035040@ambrisko.com> <20090723060835.GB62628@curry.mchp.siemens.de> In-Reply-To: <20090723060835.GB62628@curry.mchp.siemens.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907230835.50814.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 23 Jul 2009 08:45:29 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Andre Albsmeier Subject: Re: Reading acpi memory from a driver attached to hostb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 12:45:31 -0000 On Thursday 23 July 2009 2:08:35 am Andre Albsmeier wrote: > On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote: > > Andre Albsmeier writes: > > | On Sat, 18-Jul-2009 at 10:25:06 +0100, Rui Paulo wrote: > > | > On 18 Jul 2009, at 09:10, Andre Albsmeier wrote: > > | > > > | > > On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote: > > | > >> Andre Albsmeier wrote: > > | > >>> [CC'ing this to Rui Paulo since he tried to help me a while ago] > > | > >>> > > | > >>> Since my driver is a child of hostb0, I have no idea of how to > > | > >>> access > > | > >>> acpi0's memory area. Here is a devinfo -r to make things clear: > > | > >>> > > | > >> ... > > | > >>> > > | > >>> Earlier, I was given the hint to attach as a child of acpi (see the > > | > >>> old mail attached below) but in this case I didn't have access to > > | > >>> the > > | > >>> hostb registers which I need as well. > > | > >>> > > | > >>> The only thing I see is: Attach two drivers -- one as child of acpi > > | > >>> and another as child of hostb and let them communicate somehow (no > > | > >>> idea how to do this). > > | > >>> > > | > >>> I have also done crazy things like searching for acpi0 and trying > > | > >>> to bus_alloc_resource() the memory I am interested in but this also > > | > >>> failed. > > | > >>> > > | > >>> Or is it possible to free(!) somehow the address space from acpi0 > > | > >>> and pass it to hostb0 so I can bus_alloc_resource() it? > > | > >>> > > | > >> > > | > >> You can probably make two drivers in one which cooperate to > > | > >> allow access to both sets of resources. > > | > > > > | > > Hmm, that's what I meant by: Attach two drivers -- one as child of > > | > > acpi > > | > > and another as child of hostb... > > | > > > > | > > And that's similar to Rui Paulo's suggestion a while ago: > > | > > > > | > >> You'll probably need to create a fake ACPI child driver to access it. > > | > >> > > | > >> Create your identify routine with something like: > > | > >> > > | > >> static void mydriver_identify(driver_t *driver, device_t parent) > > | > >> { > > | > >> if (device_find_child(parent, "mydriver", -1) == NULL && > > | > >> mydriver_match(parent)) > > | > >> device_add_child(parent, "mydriver", -1); > > | > >> } > > | > >> > > | > >> mydriver_match() should check if you were given the acpi0 device. > > | > > > > | > > But in order to attach to acpi0, I need to say > > | > > > > | > > DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, > > | > > NULL ); > > | > > > > | > > instead of > > | > > > > | > > DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, > > | > > NULL ); > > | > > > > | > > This way I could attach to acpi but not to hostb anymore.... > > | > > > > | > > I have searched the net for solutions, I have read newbus-draft.txt > > | > > and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all > > | > > of these my driver is working on other mainboards where it doesn't > > | > > have to access foreign memory) but didn't find anything. > > | > > > | > I'm out of ideas. > > | > John, do you know if this is a newbus limitation or if it can be > > | > worked around ? > > | > > | I assume it is possible somehow, I am just too stupid (it is the first > > | driver I wrote). John, for easy reference, here is my initial message: > > | > > | http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html > > | > > | Please remember all, that I need the access to the acpi0 memory location > > | only for a few reads during probing/attaching, not later. > > | > > | I have also read somewhere that, when resources are allocated, the > > | system "walks up" the device tree until it finds the resource. Since > > | my driver is below hostb0 and hostb0 is below acpi0 I thought it > > | should work but it doesn't.. > > > > FWIW, you might look at ipmi(4) especially in some early states since > > it can probe and attach in many ways (isa, acpi, pci etc.) and had to > > figure out the best way to attach. Also it had various front ends. > > If I recall correctly, I did a find for a driver (ie. acpi) then > > select the first instance. Once you get that handle then you can > > request device resources from it, get the info you need then release > > that stuff. However, you won't get the module auto-loading part > > that you would get if you created a module that depended on both. > > That might get you enough of a hint. Also there are some generic > > stuff to read various memory bits like SMBIOS areas etc. This is > > used in ipmi(4) as well since the attachment can be defined in SMBIOS. > > If you have a specific question, about why the driver did something > > I should recall that. The ipmi(4) driver is in fairly clean. There > > is some improvements I still need to do on probe/attachment that > > causes a bogus ipmi1 at times. > > Thanks a lot for this interesting information. I see, things are more > complicated than I thought. There is no easy way having a quick glance > at "foreign" memory during probing. Now I have to figure out how to get > the order of probing/attaching done. One thing I could do is: > > 1. attach mydriver_ACPI to acpi0 > > 2. probe mydriver under hostb0, check if we need access to > sysresources from acpi0 (depends on the chipset found). > If no, goto 5. > > 3. ask mydriver_ACPI about stuff I want to know (HOW?) > > 4. tell mydriver to detach from acpi0 (HOW?) > > 5. attach mydriver to hostb0 and do my work > > What I would like more is something like: > > 1. probe mydriver under hostb0, check if we need access to > sysresources from acpi0 (depends on the chipset found). > If no, goto 3. > > 2. ask mydriver_ACPI to attach to acpi0, give me the info > I want, detach mydriver_ACPI (HOW?) > > 3. attach mydriver to hostb0 and do my work Did you try doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in your driver that is a child of hostb0? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 16:16:16 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0284B106564A for ; Thu, 23 Jul 2009 16:16:16 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id B2F9F8FC26 for ; Thu, 23 Jul 2009 16:16:15 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MU0xi-0008U3-AL for freebsd-hackers@freebsd.org; Thu, 23 Jul 2009 16:16:06 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Jul 2009 16:16:06 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Jul 2009 16:16:06 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Thu, 23 Jul 2009 18:15:57 +0200 Lines: 33 Message-ID: References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090615) In-Reply-To: <4A6795E7.7020700@darkbsd.org> Sender: news Subject: Re: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 16:16:16 -0000 DarkSoul wrote: > Anthony Pankov wrote: >> SGID/SUID bits don't work with shell scripts, do they? >> >> And no mention in chmod(1,2) manual. > > They don't. > > One reason for this, is that if they were applied, the following would > occur : > - execve() syscall reads your script's shebang line, and the script > interpreter is executed, receiving the specified arguments along with > the script name. > - The interpreter then open()s the script file to read it, and run the code. > > The problem you then are faced with, is that you have a time frame > defined by the moment between the aforementioned execve() and open(), > during which it could be possible to unlink/move/whatever the shell > script the interpreter is going to open. > > You guess where this is going, you have no absolute way of guaranteeing > you are executing the file you initially planned on opening because > execution/opening/reading is not, and can't be done atomically for shell > scripts. Hmm... Presumingly, the biggest concern is with scripts owned by root. Who can unlink, move or change the script? The owner and his group can change it; the directory owner can unlink it. It looks like the targetted problem is if a root creates a script in a user-owned directory and then makes it suid. It looks more like a PEBKAC then a system problem - is it really so serious there is no sysctl to disable the check? From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 16:19:54 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50CE71065675; Thu, 23 Jul 2009 16:19:54 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id E82168FC2D; Thu, 23 Jul 2009 16:19:53 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 23 Jul 2009 07:26:56 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.3/8.14.1) with ESMTP id n6NEPgZu026493; Thu, 23 Jul 2009 07:25:42 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.3/8.14.3/Submit) id n6NEPeRH026492; Thu, 23 Jul 2009 07:25:40 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200907231425.n6NEPeRH026492@ambrisko.com> In-Reply-To: <200907230835.50814.jhb@freebsd.org> To: John Baldwin Date: Thu, 23 Jul 2009 07:25:40 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-hackers@freebsd.org, Andre Albsmeier Subject: Re: Reading acpi memory from a driver attached to hostb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 16:19:54 -0000 John Baldwin writes: | On Thursday 23 July 2009 2:08:35 am Andre Albsmeier wrote: | > On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote: | > > Andre Albsmeier writes: | > > | On Sat, 18-Jul-2009 at 10:25:06 +0100, Rui Paulo wrote: | > > | > On 18 Jul 2009, at 09:10, Andre Albsmeier wrote: | > > | > | > > | > > On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote: | > > | > >> Andre Albsmeier wrote: | > > | > >>> [CC'ing this to Rui Paulo since he tried to help me a while ago] | > > | > >>> | > > | > >>> Since my driver is a child of hostb0, I have no idea of how to | > > | > >>> access | > > | > >>> acpi0's memory area. Here is a devinfo -r to make things clear: | > > | > >>> | > > | > >> ... | > > | > >>> | > > | > >>> Earlier, I was given the hint to attach as a child of acpi (see | the | > > | > >>> old mail attached below) but in this case I didn't have access to | > > | > >>> the | > > | > >>> hostb registers which I need as well. | > > | > >>> | > > | > >>> The only thing I see is: Attach two drivers -- one as child of | acpi | > > | > >>> and another as child of hostb and let them communicate somehow (no | > > | > >>> idea how to do this). | > > | > >>> | > > | > >>> I have also done crazy things like searching for acpi0 and trying | > > | > >>> to bus_alloc_resource() the memory I am interested in but this | also | > > | > >>> failed. | > > | > >>> | > > | > >>> Or is it possible to free(!) somehow the address space from acpi0 | > > | > >>> and pass it to hostb0 so I can bus_alloc_resource() it? | > > | > >>> | > > | > >> | > > | > >> You can probably make two drivers in one which cooperate to | > > | > >> allow access to both sets of resources. | > > | > > | > > | > > Hmm, that's what I meant by: Attach two drivers -- one as child of | > > | > > acpi | > > | > > and another as child of hostb... | > > | > > | > > | > > And that's similar to Rui Paulo's suggestion a while ago: | > > | > > | > > | > >> You'll probably need to create a fake ACPI child driver to access | it. | > > | > >> | > > | > >> Create your identify routine with something like: | > > | > >> | > > | > >> static void mydriver_identify(driver_t *driver, device_t parent) | > > | > >> { | > > | > >> if (device_find_child(parent, "mydriver", -1) == NULL && | > > | > >> mydriver_match(parent)) | > > | > >> device_add_child(parent, "mydriver", -1); | > > | > >> } | > > | > >> | > > | > >> mydriver_match() should check if you were given the acpi0 device. | > > | > > | > > | > > But in order to attach to acpi0, I need to say | > > | > > | > > | > > DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, | > > | > > NULL ); | > > | > > | > > | > > instead of | > > | > > | > > | > > DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, | > > | > > NULL ); | > > | > > | > > | > > This way I could attach to acpi but not to hostb anymore.... | > > | > > | > > | > > I have searched the net for solutions, I have read newbus-draft.txt | > > | > > and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all | > > | > > of these my driver is working on other mainboards where it doesn't | > > | > > have to access foreign memory) but didn't find anything. | > > | > | > > | > I'm out of ideas. | > > | > John, do you know if this is a newbus limitation or if it can be | > > | > worked around ? | > > | | > > | I assume it is possible somehow, I am just too stupid (it is the first | > > | driver I wrote). John, for easy reference, here is my initial message: | > > | | > > | http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html | > > | | > > | Please remember all, that I need the access to the acpi0 memory location | > > | only for a few reads during probing/attaching, not later. | > > | | > > | I have also read somewhere that, when resources are allocated, the | > > | system "walks up" the device tree until it finds the resource. Since | > > | my driver is below hostb0 and hostb0 is below acpi0 I thought it | > > | should work but it doesn't.. | > > | > > FWIW, you might look at ipmi(4) especially in some early states since | > > it can probe and attach in many ways (isa, acpi, pci etc.) and had to | > > figure out the best way to attach. Also it had various front ends. | > > If I recall correctly, I did a find for a driver (ie. acpi) then | > > select the first instance. Once you get that handle then you can | > > request device resources from it, get the info you need then release | > > that stuff. However, you won't get the module auto-loading part | > > that you would get if you created a module that depended on both. | > > That might get you enough of a hint. Also there are some generic | > > stuff to read various memory bits like SMBIOS areas etc. This is | > > used in ipmi(4) as well since the attachment can be defined in SMBIOS. | > > If you have a specific question, about why the driver did something | > > I should recall that. The ipmi(4) driver is in fairly clean. There | > > is some improvements I still need to do on probe/attachment that | > > causes a bogus ipmi1 at times. | > | > Thanks a lot for this interesting information. I see, things are more | > complicated than I thought. There is no easy way having a quick glance | > at "foreign" memory during probing. Now I have to figure out how to get | > the order of probing/attaching done. One thing I could do is: | > | > 1. attach mydriver_ACPI to acpi0 | > | > 2. probe mydriver under hostb0, check if we need access to | > sysresources from acpi0 (depends on the chipset found). | > If no, goto 5. | > | > 3. ask mydriver_ACPI about stuff I want to know (HOW?) | > | > 4. tell mydriver to detach from acpi0 (HOW?) | > | > 5. attach mydriver to hostb0 and do my work | > | > What I would like more is something like: | > | > 1. probe mydriver under hostb0, check if we need access to | > sysresources from acpi0 (depends on the chipset found). | > If no, goto 3. | > | > 2. ask mydriver_ACPI to attach to acpi0, give me the info | > I want, detach mydriver_ACPI (HOW?) | > | > 3. attach mydriver to hostb0 and do my work | | Did you try | doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in your | driver that is a child of hostb0? That should basically work since almost everything is a child of acpi. However, the depth could change so running through the device_get_parent and then checking the name might be good. BTW, there is an example in sys/compat/linsysfs/linsysfs.c in which I run the entire bus tree via linsysfs_run_bus which is recursive and started from linsysfs_init. As John and I say, you don't need to "attach" to acpi just allocate what you need, access it, then release it. If you need to hold on it then it becomes more involved. Since you never attach then you don't need to dettach just release the resources you grabbed ( ie. bus_release_resource what you bus_alloc_resource). Doug A. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 17:49:27 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBBCE106567A; Thu, 23 Jul 2009 17:49:27 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id B52B88FC1B; Thu, 23 Jul 2009 17:49:27 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id n6NHnRGp071367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2009 10:49:27 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id n6NHnRBs071366; Thu, 23 Jul 2009 10:49:27 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA02891; Thu, 23 Jul 09 10:41:43 PDT Date: Thu, 23 Jul 2009 10:38:51 -0700 From: perryh@pluto.rain.com To: ivoras@freebsd.org Message-Id: <4a68a02b.qjV+UOvOtUWLEPN1%perryh@pluto.rain.com> References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 17:49:28 -0000 Ivan Voras wrote: > Presumingly, the biggest concern is with scripts owned by root. > Who can unlink, move or change the script? The owner and his > group can change it; the directory owner can unlink it ... Anyone can make a link to such a script in, say, /tmp and then mess with the link :( From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 17:52:28 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20247106566B for ; Thu, 23 Jul 2009 17:52:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BF8C68FC14 for ; Thu, 23 Jul 2009 17:52:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 75DF546B86; Thu, 23 Jul 2009 13:52:27 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id AF6398A0A1; Thu, 23 Jul 2009 13:52:26 -0400 (EDT) From: John Baldwin To: Doug Ambrisko Date: Thu, 23 Jul 2009 13:46:41 -0400 User-Agent: KMail/1.9.7 References: <200907231425.n6NEPeRH026492@ambrisko.com> In-Reply-To: <200907231425.n6NEPeRH026492@ambrisko.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907231346.42168.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 23 Jul 2009 13:52:26 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, Andre Albsmeier Subject: Re: Reading acpi memory from a driver attached to hostb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 17:52:28 -0000 On Thursday 23 July 2009 10:25:40 am Doug Ambrisko wrote: > John Baldwin writes: > | On Thursday 23 July 2009 2:08:35 am Andre Albsmeier wrote: > | > On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote: > | > > Andre Albsmeier writes: > | > > | On Sat, 18-Jul-2009 at 10:25:06 +0100, Rui Paulo wrote: > | > > | > On 18 Jul 2009, at 09:10, Andre Albsmeier wrote: > | > > | > > | > > | > > On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote: > | > > | > >> Andre Albsmeier wrote: > | > > | > >>> [CC'ing this to Rui Paulo since he tried to help me a while ago] > | > > | > >>> > | > > | > >>> Since my driver is a child of hostb0, I have no idea of how to > | > > | > >>> access > | > > | > >>> acpi0's memory area. Here is a devinfo -r to make things clear: > | > > | > >>> > | > > | > >> ... > | > > | > >>> > | > > | > >>> Earlier, I was given the hint to attach as a child of acpi (see > | the > | > > | > >>> old mail attached below) but in this case I didn't have access to > | > > | > >>> the > | > > | > >>> hostb registers which I need as well. > | > > | > >>> > | > > | > >>> The only thing I see is: Attach two drivers -- one as child of > | acpi > | > > | > >>> and another as child of hostb and let them communicate somehow (no > | > > | > >>> idea how to do this). > | > > | > >>> > | > > | > >>> I have also done crazy things like searching for acpi0 and trying > | > > | > >>> to bus_alloc_resource() the memory I am interested in but this > | also > | > > | > >>> failed. > | > > | > >>> > | > > | > >>> Or is it possible to free(!) somehow the address space from acpi0 > | > > | > >>> and pass it to hostb0 so I can bus_alloc_resource() it? > | > > | > >>> > | > > | > >> > | > > | > >> You can probably make two drivers in one which cooperate to > | > > | > >> allow access to both sets of resources. > | > > | > > > | > > | > > Hmm, that's what I meant by: Attach two drivers -- one as child of > | > > | > > acpi > | > > | > > and another as child of hostb... > | > > | > > > | > > | > > And that's similar to Rui Paulo's suggestion a while ago: > | > > | > > > | > > | > >> You'll probably need to create a fake ACPI child driver to access > | it. > | > > | > >> > | > > | > >> Create your identify routine with something like: > | > > | > >> > | > > | > >> static void mydriver_identify(driver_t *driver, device_t parent) > | > > | > >> { > | > > | > >> if (device_find_child(parent, "mydriver", -1) == NULL && > | > > | > >> mydriver_match(parent)) > | > > | > >> device_add_child(parent, "mydriver", -1); > | > > | > >> } > | > > | > >> > | > > | > >> mydriver_match() should check if you were given the acpi0 device. > | > > | > > > | > > | > > But in order to attach to acpi0, I need to say > | > > | > > > | > > | > > DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, > | > > | > > NULL ); > | > > | > > > | > > | > > instead of > | > > | > > > | > > | > > DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, > | > > | > > NULL ); > | > > | > > > | > > | > > This way I could attach to acpi but not to hostb anymore.... > | > > | > > > | > > | > > I have searched the net for solutions, I have read newbus-draft.txt > | > > | > > and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all > | > > | > > of these my driver is working on other mainboards where it doesn't > | > > | > > have to access foreign memory) but didn't find anything. > | > > | > > | > > | > I'm out of ideas. > | > > | > John, do you know if this is a newbus limitation or if it can be > | > > | > worked around ? > | > > | > | > > | I assume it is possible somehow, I am just too stupid (it is the first > | > > | driver I wrote). John, for easy reference, here is my initial message: > | > > | > | > > | http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html > | > > | > | > > | Please remember all, that I need the access to the acpi0 memory location > | > > | only for a few reads during probing/attaching, not later. > | > > | > | > > | I have also read somewhere that, when resources are allocated, the > | > > | system "walks up" the device tree until it finds the resource. Since > | > > | my driver is below hostb0 and hostb0 is below acpi0 I thought it > | > > | should work but it doesn't.. > | > > > | > > FWIW, you might look at ipmi(4) especially in some early states since > | > > it can probe and attach in many ways (isa, acpi, pci etc.) and had to > | > > figure out the best way to attach. Also it had various front ends. > | > > If I recall correctly, I did a find for a driver (ie. acpi) then > | > > select the first instance. Once you get that handle then you can > | > > request device resources from it, get the info you need then release > | > > that stuff. However, you won't get the module auto-loading part > | > > that you would get if you created a module that depended on both. > | > > That might get you enough of a hint. Also there are some generic > | > > stuff to read various memory bits like SMBIOS areas etc. This is > | > > used in ipmi(4) as well since the attachment can be defined in SMBIOS. > | > > If you have a specific question, about why the driver did something > | > > I should recall that. The ipmi(4) driver is in fairly clean. There > | > > is some improvements I still need to do on probe/attachment that > | > > causes a bogus ipmi1 at times. > | > > | > Thanks a lot for this interesting information. I see, things are more > | > complicated than I thought. There is no easy way having a quick glance > | > at "foreign" memory during probing. Now I have to figure out how to get > | > the order of probing/attaching done. One thing I could do is: > | > > | > 1. attach mydriver_ACPI to acpi0 > | > > | > 2. probe mydriver under hostb0, check if we need access to > | > sysresources from acpi0 (depends on the chipset found). > | > If no, goto 5. > | > > | > 3. ask mydriver_ACPI about stuff I want to know (HOW?) > | > > | > 4. tell mydriver to detach from acpi0 (HOW?) > | > > | > 5. attach mydriver to hostb0 and do my work > | > > | > What I would like more is something like: > | > > | > 1. probe mydriver under hostb0, check if we need access to > | > sysresources from acpi0 (depends on the chipset found). > | > If no, goto 3. > | > > | > 2. ask mydriver_ACPI to attach to acpi0, give me the info > | > I want, detach mydriver_ACPI (HOW?) > | > > | > 3. attach mydriver to hostb0 and do my work > | > | Did you try > | doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in your > | driver that is a child of hostb0? > > That should basically work since almost everything is a child of acpi. > However, the depth could change so running through the device_get_parent > and then checking the name might be good. In this case hostbX's grandparent is always pciX (usually pci0) and the PCI bus driver just passes through requests that come from grandchildren w/o trying to match the rid to a BAR. > As John and I say, you don't need to "attach" to acpi just allocate > what you need, access it, then release it. If you need to hold on > it then it becomes more involved. Since you never attach then you > don't need to dettach just release the resources you grabbed ( > ie. bus_release_resource what you bus_alloc_resource). This is true. However, to attach to acpi you generally need some device_t device to attach to. You could create a fictitious device via an identify routine, but I think that would be a far bigger hack than just doing the device_get_parent() bit in your hostbX driver's probe routine. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 17:53:56 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61103106564A; Thu, 23 Jul 2009 17:53:56 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mx1.freebsd.org (Postfix) with ESMTP id CF9708FC27; Thu, 23 Jul 2009 17:53:55 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n6NHrqWH016673; Thu, 23 Jul 2009 19:53:52 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n6NHrqVJ009145; Thu, 23 Jul 2009 19:53:52 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.3/8.14.3) id n6NHrqcP013142; Date: Thu, 23 Jul 2009 19:53:51 +0200 From: Andre Albsmeier To: Doug Ambrisko Message-ID: <20090723175351.GA70584@curry.mchp.siemens.de> References: <200907230835.50814.jhb@freebsd.org> <200907231425.n6NEPeRH026492@ambrisko.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <200907231425.n6NEPeRH026492@ambrisko.com> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.19 (2009-01-05) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Andre Albsmeier Subject: Re: Reading acpi memory from a driver attached to hostb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 17:53:56 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline John, apparently you sent me an email (thanks a lot) which I never received (we have to blame our company's spam filters which I do not control). I'll comment on it here in my reply to Doug... On Thu, 23-Jul-2009 at 07:25:40 -0700, Doug Ambrisko wrote: > John Baldwin writes: > | On Thursday 23 July 2009 2:08:35 am Andre Albsmeier wrote: > | > On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote: > | > > Andre Albsmeier writes: > | > > | > stripping some elder stuff > | > > | > | > > | I assume it is possible somehow, I am just too stupid (it is the first > | > > | driver I wrote). John, for easy reference, here is my initial message: > | > > | > | > > | http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html > | > > | > | > > | Please remember all, that I need the access to the acpi0 memory location > | > > | only for a few reads during probing/attaching, not later. > | > > | > | > > | I have also read somewhere that, when resources are allocated, the > | > > | system "walks up" the device tree until it finds the resource. Since > | > > | my driver is below hostb0 and hostb0 is below acpi0 I thought it > | > > | should work but it doesn't.. > | > > > | > > FWIW, you might look at ipmi(4) especially in some early states since > | > > it can probe and attach in many ways (isa, acpi, pci etc.) and had to > | > > figure out the best way to attach. Also it had various front ends. > | > > If I recall correctly, I did a find for a driver (ie. acpi) then > | > > select the first instance. Once you get that handle then you can > | > > request device resources from it, get the info you need then release > | > > that stuff. However, you won't get the module auto-loading part > | > > that you would get if you created a module that depended on both. > | > > That might get you enough of a hint. Also there are some generic > | > > stuff to read various memory bits like SMBIOS areas etc. This is > | > > used in ipmi(4) as well since the attachment can be defined in SMBIOS. > | > > If you have a specific question, about why the driver did something > | > > I should recall that. The ipmi(4) driver is in fairly clean. There > | > > is some improvements I still need to do on probe/attachment that > | > > causes a bogus ipmi1 at times. > | > > | > Thanks a lot for this interesting information. I see, things are more > | > complicated than I thought. There is no easy way having a quick glance > | > at "foreign" memory during probing. Now I have to figure out how to get > | > the order of probing/attaching done. One thing I could do is: > | > > | > 1. attach mydriver_ACPI to acpi0 > | > > | > 2. probe mydriver under hostb0, check if we need access to > | > sysresources from acpi0 (depends on the chipset found). > | > If no, goto 5. > | > > | > 3. ask mydriver_ACPI about stuff I want to know (HOW?) > | > > | > 4. tell mydriver to detach from acpi0 (HOW?) > | > > | > 5. attach mydriver to hostb0 and do my work > | > > | > What I would like more is something like: > | > > | > 1. probe mydriver under hostb0, check if we need access to > | > sysresources from acpi0 (depends on the chipset found). > | > If no, goto 3. > | > > | > 2. ask mydriver_ACPI to attach to acpi0, give me the info > | > I want, detach mydriver_ACPI (HOW?) > | > > | > 3. attach mydriver to hostb0 and do my work > | > | Did you try > | doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in your > | driver that is a child of hostb0? I tried this, well, something similar: I had to do 4 times device_get_parent() to end up at acpi0: mydriver -> hostb0 -> pci0 -> pcib0 -> acpi0 > > That should basically work since almost everything is a child of acpi. Thats what I hoped indeed. It would be a lot simpler than working with two drivers which have to communicate with each other. > However, the depth could change so running through the device_get_parent > and then checking the name might be good. I thought the same so I decided to lookup the acpi devclass and then acpi0 from there. To be sure, I compared the resulting pointers of acpi0 with the one found after the four device_get_parent(). They were the same. > > BTW, there is an example in sys/compat/linsysfs/linsysfs.c > in which I run the entire bus tree via linsysfs_run_bus which is > recursive and started from linsysfs_init. > > As John and I say, you don't need to "attach" to acpi just allocate > what you need, access it, then release it. If you need to hold on > it then it becomes more involved. Since you never attach then you > don't need to dettach just release the resources you grabbed ( > ie. bus_release_resource what you bus_alloc_resource). Well, then I still must be doing something wrong. I have attached my driver skeleton which does the following: 1. device_identify() which does a device_add_child() if needed 2. device_probe() which just tries to bus_alloc_resource() a SYS_RES_MEMORY resource from acpi0. If it works (which never does :-(), call bus_release_resource(). device_probe() always returns ENXIO so the whole driver never attaches. Especially in device_probe() I do: 1. Search for acpi0. 2. List the resources of acpi0. I compared the list to my "devinfo -r" output and they are the same. 3. Take the first SYS_RES_MEMORY resource from the list in 2. and try to bus_alloc_resource() it. This never succeds. Maybe you find the bug in there, I run out of ideas. It's not much of code, most of it are device_printfs for debugging... I have also attached the Makefile in case someone wants to kldload it on his machine. I would be very interested if it worked there. Thanks to you and John, of course. -Andre --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=Makefile KMOD = eccmon SRCS = eccmon.c device_if.h bus_if.h pci_if.h NO_MAN = 1 CFLAGS+=-DDEVEL .include --k+w/mQv8wyuph6w0-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 18:40:58 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C618A10656CB for ; Thu, 23 Jul 2009 18:40:58 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f220.google.com (mail-ew0-f220.google.com [209.85.219.220]) by mx1.freebsd.org (Postfix) with ESMTP id 4DB768FC0A for ; Thu, 23 Jul 2009 18:40:57 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by ewy20 with SMTP id 20so274173ewy.43 for ; Thu, 23 Jul 2009 11:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=+hyFI4sJaXXhJrMPuVFer7KgvLq5Nvvuaw/Yf8/UzyM=; b=t7cBbH6YUKSse7QLDngb+LjqhQyfF26yV2YBZfwG4q79t0pzOQ5h6XqHRxKCM/f2KH cMk2KgRc4J8QM4VTPxiz6wzoihlghq0mbNT6VUfikSBBferWnGHaFQMjrNe9psvli3l/ JPooBQy9j5O51swmC0/+KETj341eojUVOCvDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=nmKVa4JjoAeWT37kyc7LvHTTr/VnEtBHqA1BW33gO4RdMCZYbuY33rd5iWq/DUdbpK W466uTNlTX+1pH+0hGw2jL55gE9ECHYoDypNDEn/B+U2KVhqZQZSJvYIv6P5gsLUaSoT WPWrN6OjVzI7DShezW8Xw7OXMg9Kk+bG7Cr58= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.210.10.11 with SMTP id 11mr8457529ebj.5.1248372713191; Thu, 23 Jul 2009 11:11:53 -0700 (PDT) In-Reply-To: <4a68a02b.qjV+UOvOtUWLEPN1%perryh@pluto.rain.com> References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> <4a68a02b.qjV+UOvOtUWLEPN1%perryh@pluto.rain.com> From: Ivan Voras Date: Thu, 23 Jul 2009 20:11:33 +0200 X-Google-Sender-Auth: de4f649ce9cbb01b Message-ID: <9bbcef730907231111s2ef20e76s5a19a6270b3b5f03@mail.gmail.com> To: perryh@pluto.rain.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 18:40:59 -0000 2009/7/23 : > Ivan Voras wrote: >> Presumingly, the biggest concern is with scripts owned by root. >> Who can unlink, move or change the script? The owner and his >> group can change it; the directory owner can unlink it ... > > Anyone can make a link to such a script in, say, /tmp and then > mess with the link :( You mean setuid a soft link? That's allowed? -- f+rEnSIBITAhITAhLR1nM9F4cIs5KJrhbcsVtUIt7K1MhWJy1A== From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 18:55:35 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 647E6106564A for ; Thu, 23 Jul 2009 18:55:35 +0000 (UTC) (envelope-from lgusenet@be-well.ilk.org) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6658FC2A for ; Thu, 23 Jul 2009 18:55:35 +0000 (UTC) (envelope-from lgusenet@be-well.ilk.org) Received: (qmail 30537 invoked from network); 23 Jul 2009 18:28:53 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 23 Jul 2009 18:28:53 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 9AB1150822; Thu, 23 Jul 2009 14:28:52 -0400 (EDT) To: freebsd-hackers@freebsd.org References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> From: Lowell Gilbert Date: Thu, 23 Jul 2009 14:28:52 -0400 In-Reply-To: <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> (perryh@pluto.rain.com's message of "Wed\, 22 Jul 2009 22\:00\:58 -0700") Message-ID: <44my6v8d97.fsf@be-well.ilk.org> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 23 Jul 2009 19:00:49 +0000 Subject: Re: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 18:55:35 -0000 perryh@pluto.rain.com writes: > DarkSoul wrote: >> Anthony Pankov wrote: >> > SGID/SUID bits don't work with shell scripts, do they? >> >> They don't. >> >> ... if they were applied, the following would occur : >> - execve() syscall reads your script's shebang line, and >> the script interpreter is executed, receiving the specified >> arguments along with the script name. >> - The interpreter then open()s the script file to read it, >> and run the code. >> >> The problem you then are faced with, is that you have a time >> frame defined by the moment between the aforementioned execve() >> and open(), during which it could be possible to unlink/move/ >> whatever the shell script the interpreter is going to open. >> >> You guess where this is going, you have no absolute way of >> guaranteeing you are executing the file you initially planned >> on opening because execution/opening/reading is not, and can't >> be done atomically for shell scripts. > > In principle, it should be possible to fix this exposure by > improving the interface between execve() and the interpreter: > > The execve() syscall already has the script file open to read the > shebang line. Leave it open, and ensure that the interpreter > receives the open descriptor as fd#3 just as 0, 1, and 2 are already > used for stdin, stdout, and stderr. An interpreter supporting this > approach would check whether stdscr (fd#3) is already open, and if > so read from it instead of open()ing the script file. This should > ensure that the script which gets executed is the same inode on > which execve() saw the SGID/SUID bits set, even if the filesystem > has been changed by the time the interpreter has gotten started. > It would be the responsibility of whomever decided to set the > SGID/SUID bits on a particular script to ensure that the interpreter > involved supports the mechanism. > > I vaguely recall having seen a similar (or even identical) approach > suggested some years ago. It may even have been implemented in some > variant of Un*x. That's clever, but how would it work in practice, while common shells and scripting languages may not implement their side of it? From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 20:06:12 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FD891065670 for ; Thu, 23 Jul 2009 20:06:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 78FB98FC1F for ; Thu, 23 Jul 2009 20:06:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by cyrus.watson.org (Postfix) with ESMTPSA id 299D346B58; Thu, 23 Jul 2009 16:06:12 -0400 (EDT) From: John Baldwin To: Andre Albsmeier Date: Thu, 23 Jul 2009 16:06:11 -0400 User-Agent: KMail/1.9.7 References: <200907230835.50814.jhb@freebsd.org> <200907231425.n6NEPeRH026492@ambrisko.com> <20090723175351.GA70584@curry.mchp.siemens.de> In-Reply-To: <20090723175351.GA70584@curry.mchp.siemens.de> MIME-Version: 1.0 Content-Disposition: inline X-Length: 2632 X-UID: 20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907231606.11904.jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Reading acpi memory from a driver attached to hostb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 20:06:12 -0000 On Thursday 23 July 2009 1:53:51 pm Andre Albsmeier wrote: > John, apparently you sent me an email (thanks a lot) which I never > received (we have to blame our company's spam filters which I do > not control). I'll comment on it here in my reply to Doug... Yes, I saw the bounces. Hopefully you see the list version of this. > > | Did you try > > | doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in your > > | driver that is a child of hostb0? > > I tried this, well, something similar: I had to do 4 times > device_get_parent() to end up at acpi0: > > mydriver -> hostb0 -> pci0 -> pcib0 -> acpi0 You don't actually need to do that. pci0 will pass the request up to acpi0 eventually. You just need to ask pci0 to allocate it for you and it will see you are not a direct child and take the 'passthrough' case here: struct resource * pci_alloc_resource(device_t dev, device_t child, int type, int *rid, u_long start, u_long end, u_long count, u_int flags) { ... if (device_get_parent(child) != dev) return (BUS_ALLOC_RESOURCE(device_get_parent(dev), child, type, rid, start, end, count, flags)); ... } Rather than trying to allocate the whole chunk of the ACPI resource, I would just do a specific allocation like so: rid = 0; res = BUS_ALLOC_RESOURCE(device_get_parent(device_get_parent(dev)), dev, SYS_RES_MEMORY, &rid, , , , RF_ACTIVE); -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 23:12:06 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D91C11065670 for ; Thu, 23 Jul 2009 23:12:06 +0000 (UTC) (envelope-from stephane.lapie@darkbsd.org) Received: from shinigami.darkbsd.org (shinigami.darkbsd.org [82.227.96.182]) by mx1.freebsd.org (Postfix) with ESMTP id 899088FC15 for ; Thu, 23 Jul 2009 23:12:06 +0000 (UTC) (envelope-from stephane.lapie@darkbsd.org) Received: from localhost (localhost [127.0.0.1]) by shinigami.darkbsd.org (Postfix) with ESMTP id 577D45C4C for ; Fri, 24 Jul 2009 00:54:34 +0200 (CEST) Received: from shinigami.darkbsd.org ([127.0.0.1]) by localhost (quasar.darkbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2vZtJLh0lxl for ; Fri, 24 Jul 2009 00:54:26 +0200 (CEST) Received: from [192.168.0.84] (ilyasviel.darkbsd.org [192.168.0.84]) (Authenticated sender: darksoul) by shinigami.darkbsd.org (Postfix) with ESMTPSA id 792E65C4A for ; Fri, 24 Jul 2009 00:54:26 +0200 (CEST) Message-ID: <4A68EA4A.8070102@darkbsd.org> Date: Fri, 24 Jul 2009 00:55:06 +0200 From: Stephane LAPIE User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> <4a68a02b.qjV+UOvOtUWLEPN1%perryh@pluto.rain.com> <9bbcef730907231111s2ef20e76s5a19a6270b3b5f03@mail.gmail.com> In-Reply-To: <9bbcef730907231111s2ef20e76s5a19a6270b3b5f03@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCBD1A03B46BFF61D318C250C" Subject: Re: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 23:12:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCBD1A03B46BFF61D318C250C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ivan Voras wrote: > 2009/7/23 : >> Ivan Voras wrote: >>> Presumingly, the biggest concern is with scripts owned by root. >>> Who can unlink, move or change the script? The owner and his >>> group can change it; the directory owner can unlink it ... >> Anyone can make a link to such a script in, say, /tmp and then >> mess with the link :( Either way, allowing SUID on scripts without proper guarantees you actually run what you WANT to run, would mean that you can basically execute "whatever code you are able to slip in there" using someone else's credentials, even if not root. You could be able to modify scripts belonging to your own group, while not being able to execute them with the owner user. The point is : "ID/credential usurpation", even if not actual meaningful (on a system-level) "privilege escalation" per se can be a grave problem enough, especially in corporate environments. Therefore any implementation allowing for this behavior should not be accepted, imho. --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enigCBD1A03B46BFF61D318C250C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpo6k0ACgkQ24Ql8u6TF2MnHQCfbA+GL9N7+FWib+oaqgEd6FYh Sv4AoNTx5bNR3SA8FmvrKpg3gzwWq8yw =FPXs -----END PGP SIGNATURE----- --------------enigCBD1A03B46BFF61D318C250C-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 07:02:12 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F52A106566C for ; Fri, 24 Jul 2009 07:02:12 +0000 (UTC) (envelope-from j.mckeown@ru.ac.za) Received: from a.mail.ru.ac.za (a.mail.ru.ac.za [IPv6:2001:4200:1010::25:1]) by mx1.freebsd.org (Postfix) with ESMTP id 16FF58FC23 for ; Fri, 24 Jul 2009 07:02:11 +0000 (UTC) (envelope-from j.mckeown@ru.ac.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ru-msa; d=ru.ac.za; h=Received:From:Organization:To:Subject:Date:User-Agent:References:In-Reply-To:X-Face:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id:X-Virus-Scanned:X-Authenticated-User; b=Re+O4uIB5KEP+KS2bZ8e9wSNhLrk3CQegBCc5gIxrp836c41lGRYI33dyIYqhNMMEAoSTAeH5JOJ2a6q8zd88AvYdh4r1W/+7l/I5jj04gpRU1fWR+AnaBySR1G1DPQz; Received: from vorkosigan.ru.ac.za ([2001:4200:1010:1058:219:d1ff:fe9f:a932]:60274) by a.mail.ru.ac.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MUEnB-000Dlu-PR for freebsd-hackers@freebsd.org; Fri, 24 Jul 2009 09:02:09 +0200 From: Jonathan McKeown Organization: Rhodes University To: freebsd-hackers@freebsd.org Date: Fri, 24 Jul 2009 09:02:09 +0200 User-Agent: KMail/1.9.10 References: <19939654343.20090722214221@mail.ru> <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> <44my6v8d97.fsf@be-well.ilk.org> In-Reply-To: <44my6v8d97.fsf@be-well.ilk.org> X-Face: $@VrUx^RHy/}yu]jKf/<4T%/d|F+$j-Ol2"2J$q+%OK1]&/G_S9(=?utf-8?q?HkaQ*=60!=3FYOK=3FY!=27M=60C=0A=09aP=5C9nVPF8Q=7DCilHH8l=3B=7E!4?= =?utf-8?q?2HK6=273lg4J=7Daz?=@1Dqqh:J]M^"YPn*2IWrZON$1+G?oX3@ =?utf-8?q?k=230=0A=0954XDRg=3DYn=5FF-etwot4U=24b?=dTS{i X-Virus-Scanned: a.mail.ru.ac.za (2001:4200:1010::25:1) X-Authenticated-User: s0900137 from vorkosigan.ru.ac.za (2001:4200:1010:1058:219:d1ff:fe9f:a932) using auth_plaintext Subject: Re: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 07:02:12 -0000 On Thursday 23 July 2009 20:28:52 Lowell Gilbert wrote: > perryh@pluto.rain.com writes: [snip description of shell opening a script, finding a #! line and passing a file descriptor for the opened script to the intended interpreter in /dev/fd/, to avoid a race condition where the shell opens the script, reads the #! line, closes it and hands off the filename to the intended interpreter to reopen what may now be a different file] > > I vaguely recall having seen a similar (or even identical) approach > > suggested some years ago. It may even have been implemented in some > > variant of Un*x. > > That's clever, but how would it work in practice, while common shells > and scripting languages may not implement their side of it? http://www.in-ulm.de/~mascheck/various/shebang/ claims that it's been implemented, in exactly the way described, in Solaris, OpenBSD and NetBSD (albeit as a kernel compile-time option in the latter two). (It's apparently also in IRIX and UnixWare). Given OpenBSD's admirable paranoia about security (hey, I'm a sysadmin: I never ask myself if I'm being paranoid, but if I'm being paranoid enough!) I'd have thought they would have explored the implications fully. Certainly other stuff knows about it. As I said yesterday, Perl describes the problem in its perlsec manpage/perldoc. The perl interpreter even has a build-time option, SETUID_SCRIPTS_ARE_SECURE_NOW - and the correct setting is supposedly detected as part of configure. There may well be some problems to overcome, but this doesn't appear to be unexplored territory. Jonathan From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 07:41:48 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30924106566C; Fri, 24 Jul 2009 07:41:48 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id E37A18FC2C; Fri, 24 Jul 2009 07:41:47 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id n6O7flKQ073129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Jul 2009 00:41:47 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id n6O7flsQ073128; Fri, 24 Jul 2009 00:41:47 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA04818; Fri, 24 Jul 09 00:30:11 PDT Date: Fri, 24 Jul 2009 00:27:19 -0700 From: perryh@pluto.rain.com To: ivoras@freebsd.org Message-Id: <4a696257.YpRb/zYqgBw8bwVp%perryh@pluto.rain.com> References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> <4a68a02b.qjV+UOvOtUWLEPN1%perryh@pluto.rain.com> <9bbcef730907231111s2ef20e76s5a19a6270b3b5f03@mail.gmail.com> In-Reply-To: <9bbcef730907231111s2ef20e76s5a19a6270b3b5f03@mail.gmail.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 07:41:48 -0000 Ivan Voras wrote: > 2009/7/23 : > > Ivan Voras wrote: > >> Presumingly, the biggest concern is with scripts owned by root. > >> Who can unlink, move or change the script? The owner and his > >> group can change it; the directory owner can unlink it ... > > > > Anyone can make a link to such a script in, say, /tmp and then > > mess with the link :( > > You mean setuid a soft link? That's allowed? One can certainly make a symlink that points to a setuid file. The permissions of the symlink itself don't matter. IIRC the original demonstration that this exposure was real and not just theoretical involved making -- and subsequently messing with -- a hard link in /tmp to a setuid script in /bin, /tmp and /bin both being on the root FS. (This was before machines commonly had enough RAM for tmpfs to be practical, and may have been before symlinks even existed.) Granted a case can be made for making /tmp a separate FS in any event, but of course it would have worked just as well to make a link in /usr/tmp to a setuid script in /usr/bin, etc. The only way to avoid the exposure would have been to ensure that no possible attacker would have write permission to any directory on the same FS as a setuid script to which the attacker had execute permission -- not the easiest thing to keep track of on an ongoing basis. With the existence of symlinks I suspect even that would no longer help. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 07:54:29 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E953F106567C for ; Fri, 24 Jul 2009 07:54:29 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtpfb1-g21.free.fr (smtpfb1-g21.free.fr [212.27.42.9]) by mx1.freebsd.org (Postfix) with ESMTP id 55C918FC08 for ; Fri, 24 Jul 2009 07:54:27 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by smtpfb1-g21.free.fr (Postfix) with ESMTP id 0FB452CFA3 for ; Fri, 24 Jul 2009 09:35:38 +0200 (CEST) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 5234494012C; Fri, 24 Jul 2009 09:35:30 +0200 (CEST) Received: from endor.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g21.free.fr (Postfix) with ESMTP id 66CCF940134; Fri, 24 Jul 2009 09:35:28 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 329BF33E61; Fri, 24 Jul 2009 07:34:52 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 10FA3A14E1; Fri, 24 Jul 2009 07:34:52 +0000 (UTC) Date: Fri, 24 Jul 2009 09:34:51 +0200 From: Jeremie Le Hen To: Ed Schouten Message-ID: <20090724073451.GH54986@felucia.tataz.chchile.org> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090509121313.GA58540@hoeg.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Hackers , vasanth raonaik , Lars Engels , jt@0xabadba.be Subject: Re: concurrent sysctl implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 07:54:30 -0000 Hi Ed, Sorry for the late reply. On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > We probably could. I think I discussed this with Robert Watson some time > ago and we could use things like ELF hints. But still, that doesn't > prevent us from reaching this limitation later on. Can you elaborate a little? Are you talking about elf-hints.h? I don't see where we can get randomness from it. Thanks. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 08:19:12 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B263106564A for ; Fri, 24 Jul 2009 08:19:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id D4C438FC15 for ; Fri, 24 Jul 2009 08:19:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 n6O8Ig47065732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jul 2009 11:18:42 +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.3/8.14.3) with ESMTP id n6O8IgVk020578; Fri, 24 Jul 2009 11:18:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n6O8IgAK020577; Fri, 24 Jul 2009 11:18:42 +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: Fri, 24 Jul 2009 11:18:42 +0300 From: Kostik Belousov To: Jeremie Le Hen Message-ID: <20090724081842.GF55190@deviant.kiev.zoral.com.ua> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w9DVQEct5+xA9E/w" Content-Disposition: inline In-Reply-To: <20090724073451.GH54986@felucia.tataz.chchile.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at 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 Cc: Ed Schouten , jt@0xabadba.be, Lars Engels , vasanth raonaik , FreeBSD Hackers Subject: Re: concurrent sysctl implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 08:19:12 -0000 --w9DVQEct5+xA9E/w Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > Hi Ed, >=20 > Sorry for the late reply. >=20 > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > We probably could. I think I discussed this with Robert Watson some time > > ago and we could use things like ELF hints. But still, that doesn't > > prevent us from reaching this limitation later on. >=20 > Can you elaborate a little? Are you talking about elf-hints.h? > I don't see where we can get randomness from it. The thing is called ELF auxillary information vector. It is used to supply some useful information for interpreter from the kernel, see include/machine/elf.h for AT_* entries. --w9DVQEct5+xA9E/w Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEUEARECAAYFAkppbmEACgkQC3+MBN1Mb4jk0wCYvJcXXUb35PBqNOrvR4pECOyc +ACeKpm8zdNQIeFL43vgu5uCVwxavE4= =wvc1 -----END PGP SIGNATURE----- --w9DVQEct5+xA9E/w-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 10:42:38 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36AA51065673; Fri, 24 Jul 2009 10:42:38 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out3.uni-muenster.de (ZIVM-OUT3.UNI-MUENSTER.DE [128.176.192.18]) by mx1.freebsd.org (Postfix) with ESMTP id 92FFC8FC19; Fri, 24 Jul 2009 10:42:37 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.43,262,1246831200"; d="scan'208";a="9278652" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay3.uni-muenster.de with ESMTP; 24 Jul 2009 12:42:34 +0200 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 8EDCF1B0765; Fri, 24 Jul 2009 12:42:34 +0200 (CEST) Date: Fri, 24 Jul 2009 12:42:34 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: John Baldwin , Message-ID: In-Reply-To: <200907230833.43021.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Alexey Shuvaev Subject: Re: checking number of parallel ports installed and their port adresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 10:42:38 -0000 thanks for the hint. if spent a bit of time and turned the in/out opcodes to ppi ioctls. actually i was very surprised about the results since you said the overhead wouldn't be that big. uploading a 256 kbyte file i got the following results: using ppi: 17.120 seconds using in/out opcodes: 8.001 seconds so i think i'll rather stick to my old inline assembly code even if it can't be considered nice programming style, but the ppi overhead isn't something i can cope with in my app. cheers. alex John Baldwin schrieb am 2009-07-23: > On Wednesday 22 July 2009 3:31:54 pm Alexander Best wrote: > > the ppi manual states that using ioctl with /dev/ppi is extremely > > slow. i need > > the parallel port to be really fast. i need to communicate with a > > device that > > uses asynchronous transfer at a rate of ~ 2 mhz. so i need the full > > ISA bus > > speed to be able to push/pull data to/from the parallel port > > without any > > delays. timing is really critical. if there's a lot of work to do > > for the > > scheduler and the io calls get queued too long the transfer will > > fail. > The overhead of ppi is probably in the noise on a modern CPU. I > think you > should be fine with just using ppi(4). > > actually i meant: how can i check the available parallel ports from > > within my > > app? is there a syscall i can use or something like that? > You can look for ppcX devices perhaps. The easiest way might be to > enable > ppi and look for /dev/ppiX devices in /dev. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 11:54:50 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 968BF106566C for ; Fri, 24 Jul 2009 11:54:50 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id 0730C8FC15 for ; Fri, 24 Jul 2009 11:54:48 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 7E1799400F9; Fri, 24 Jul 2009 13:54:42 +0200 (CEST) Received: from endor.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g21.free.fr (Postfix) with ESMTP id 956B4940154; Fri, 24 Jul 2009 13:54:40 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 5B9A033E61; Fri, 24 Jul 2009 11:54:04 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 47906A14E1; Fri, 24 Jul 2009 11:54:04 +0000 (UTC) Date: Fri, 24 Jul 2009 13:54:04 +0200 From: Jeremie Le Hen To: Kostik Belousov Message-ID: <20090724115404.GI54986@felucia.tataz.chchile.org> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090724081842.GF55190@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Ed Schouten , Jeremie Le Hen , FreeBSD Hackers Subject: Re: concurrent sysctl implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 11:54:50 -0000 On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > Hi Ed, > > > > Sorry for the late reply. > > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > We probably could. I think I discussed this with Robert Watson some time > > > ago and we could use things like ELF hints. But still, that doesn't > > > prevent us from reaching this limitation later on. > > > > Can you elaborate a little? Are you talking about elf-hints.h? > > I don't see where we can get randomness from it. > > The thing is called ELF auxillary information vector. It is used to > supply some useful information for interpreter from the kernel, > see include/machine/elf.h for AT_* entries. Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, generated at link time, that will be used to fill the canary at exec(2) time? Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 11:56:49 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAB5C1065679 for ; Fri, 24 Jul 2009 11:56:49 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF028FC2B for ; Fri, 24 Jul 2009 11:56:49 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 09D8E1CEDD; Fri, 24 Jul 2009 13:56:49 +0200 (CEST) Date: Fri, 24 Jul 2009 13:56:49 +0200 From: Ed Schouten To: Jeremie Le Hen Message-ID: <20090724115649.GV68469@hoeg.nl> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mjrw6G9AoRBv8oQK" Content-Disposition: inline In-Reply-To: <20090724115404.GI54986@felucia.tataz.chchile.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , FreeBSD Hackers Subject: Re: concurrent sysctl implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 11:56:50 -0000 --mjrw6G9AoRBv8oQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Jeremie Le Hen wrote: > On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > > Hi Ed, > > >=20 > > > Sorry for the late reply. > > >=20 > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > > We probably could. I think I discussed this with Robert Watson some= time > > > > ago and we could use things like ELF hints. But still, that doesn't > > > > prevent us from reaching this limitation later on. > > >=20 > > > Can you elaborate a little? Are you talking about elf-hints.h? > > > I don't see where we can get randomness from it. > >=20 > > The thing is called ELF auxillary information vector. It is used to > > supply some useful information for interpreter from the kernel, > > see include/machine/elf.h for AT_* entries. >=20 > Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, > generated at link time, that will be used to fill the canary at exec(2) > time? Very short answer: yes! --=20 Ed Schouten WWW: http://80386.nl/ --mjrw6G9AoRBv8oQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkppoYAACgkQ52SDGA2eCwUlPgCeNqfd4voKNAzZinFJr/RimYM9 RaQAniUhizfxuQIcFg+w5MwPiWRqGhFF =564e -----END PGP SIGNATURE----- --mjrw6G9AoRBv8oQK-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 11:58:52 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87989106566B for ; Fri, 24 Jul 2009 11:58:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id CAED08FC14 for ; Fri, 24 Jul 2009 11:58:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 n6OBwUfp079434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jul 2009 14:58:30 +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.3/8.14.3) with ESMTP id n6OBwUEG039657; Fri, 24 Jul 2009 14:58:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n6OBwUHM039636; Fri, 24 Jul 2009 14:58:30 +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: Fri, 24 Jul 2009 14:58:30 +0300 From: Kostik Belousov To: Jeremie Le Hen Message-ID: <20090724115830.GG55190@deviant.kiev.zoral.com.ua> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="30ciY2VPQam4VdV2" Content-Disposition: inline In-Reply-To: <20090724115404.GI54986@felucia.tataz.chchile.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at 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 Cc: Ed Schouten , FreeBSD Hackers Subject: Re: concurrent sysctl implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 11:58:53 -0000 --30ciY2VPQam4VdV2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 24, 2009 at 01:54:04PM +0200, Jeremie Le Hen wrote: > On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > > Hi Ed, > > >=20 > > > Sorry for the late reply. > > >=20 > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > > We probably could. I think I discussed this with Robert Watson some= time > > > > ago and we could use things like ELF hints. But still, that doesn't > > > > prevent us from reaching this limitation later on. > > >=20 > > > Can you elaborate a little? Are you talking about elf-hints.h? > > > I don't see where we can get randomness from it. > >=20 > > The thing is called ELF auxillary information vector. It is used to > > supply some useful information for interpreter from the kernel, > > see include/machine/elf.h for AT_* entries. >=20 > Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, > generated at link time, that will be used to fill the canary at exec(2) > time? The aux entries are not hints, and they are put on the new image stack when execve() activates the image. Aux entries has nothing to do with static link time, they are supplied to the dynamic linker (ELF interpreter). --30ciY2VPQam4VdV2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkppoeUACgkQC3+MBN1Mb4hsygCeMNL7SXmv25mmZdbu/8cgND1O BOgAn1sXD1u8n5ZRXtNkDV0sfgF/LEYx =zGSc -----END PGP SIGNATURE----- --30ciY2VPQam4VdV2-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 13:10:14 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 698F6106566B for ; Fri, 24 Jul 2009 13:10:14 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id EADBC8FC1E for ; Fri, 24 Jul 2009 13:10:12 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 99FF794013F; Fri, 24 Jul 2009 15:10:07 +0200 (CEST) Received: from endor.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g21.free.fr (Postfix) with ESMTP id B89AC9400ED; Fri, 24 Jul 2009 15:10:04 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 8A62433E61; Fri, 24 Jul 2009 13:09:28 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 6E99BA14E1; Fri, 24 Jul 2009 13:09:28 +0000 (UTC) Date: Fri, 24 Jul 2009 15:09:28 +0200 From: Jeremie Le Hen To: Ed Schouten Message-ID: <20090724130928.GJ54986@felucia.tataz.chchile.org> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> <20090724115649.GV68469@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090724115649.GV68469@hoeg.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , FreeBSD Hackers , Jeremie Le Hen Subject: Re: concurrent sysctl implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 13:10:14 -0000 On Fri, Jul 24, 2009 at 01:56:49PM +0200, Ed Schouten wrote: > * Jeremie Le Hen wrote: > > On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > > > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > > > Hi Ed, > > > > > > > > Sorry for the late reply. > > > > > > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > > > We probably could. I think I discussed this with Robert Watson some time > > > > > ago and we could use things like ELF hints. But still, that doesn't > > > > > prevent us from reaching this limitation later on. > > > > > > > > Can you elaborate a little? Are you talking about elf-hints.h? > > > > I don't see where we can get randomness from it. > > > > > > The thing is called ELF auxillary information vector. It is used to > > > supply some useful information for interpreter from the kernel, > > > see include/machine/elf.h for AT_* entries. > > > > Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, > > generated at link time, that will be used to fill the canary at exec(2) > > time? > > Very short answer: yes! Ok thanks. But this would make stack protection useless for local attacks on suid binaries that are world-readable since the attacker could read the ELF aux vector and compute the canary. Upon each invocation, the canary would stay the same which makes the repeat-until-success attack feasible for daemons that are automatically respawned. This saves one syscall per exec(2) but reduce security for the two cases described above. In the performance test I've run with and without -fstack-protector to build world, I saw only around 1 percent penalty. I must admit this was on a UP system which wasn't loaded though. I know that the sysctl system may be redesigned in the future to allow more concurrency. Is it something that could prevent from changing the way the canary is initialized? Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 13:49:54 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D68F106564A for ; Fri, 24 Jul 2009 13:49:54 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id AAAE68FC0A for ; Fri, 24 Jul 2009 13:49:53 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 1F6261CD95; Fri, 24 Jul 2009 15:49:53 +0200 (CEST) Date: Fri, 24 Jul 2009 15:49:53 +0200 From: Ed Schouten To: Jeremie Le Hen Message-ID: <20090724134953.GW68469@hoeg.nl> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> <20090724115649.GV68469@hoeg.nl> <20090724130928.GJ54986@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O3bhLwMadv7h6/J9" Content-Disposition: inline In-Reply-To: <20090724130928.GJ54986@felucia.tataz.chchile.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , FreeBSD Hackers Subject: Re: concurrent sysctl implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 13:49:54 -0000 --O3bhLwMadv7h6/J9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Jeremie Le Hen wrote: > On Fri, Jul 24, 2009 at 01:56:49PM +0200, Ed Schouten wrote: > > * Jeremie Le Hen wrote: > > > On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > > > > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > > > > Hi Ed, > > > > >=20 > > > > > Sorry for the late reply. > > > > >=20 > > > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > > > > We probably could. I think I discussed this with Robert Watson = some time > > > > > > ago and we could use things like ELF hints. But still, that doe= sn't > > > > > > prevent us from reaching this limitation later on. > > > > >=20 > > > > > Can you elaborate a little? Are you talking about elf-hints.h? > > > > > I don't see where we can get randomness from it. > > > >=20 > > > > The thing is called ELF auxillary information vector. It is used to > > > > supply some useful information for interpreter from the kernel, > > > > see include/machine/elf.h for AT_* entries. > > >=20 > > > Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, > > > generated at link time, that will be used to fill the canary at exec(= 2) > > > time? > >=20 > > Very short answer: yes! >=20 > Ok thanks. But this would make stack protection useless for local > attacks on suid binaries that are world-readable since the attacker > could read the ELF aux vector and compute the canary. =20 Wait wait wait. It seems you were only partially right (and Kostik corrected you): We could add AT_RANDOM, but this value will be filled in by the kernel when starting the process. This means the random value is not stored in the binary. --=20 Ed Schouten WWW: http://80386.nl/ --O3bhLwMadv7h6/J9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkppvAEACgkQ52SDGA2eCwWvGACdF86HI6hKK8oo6trEzebCc+GB QiMAniwugjKbhFbrfWd+Ihyb/AzTZO47 =Mb3M -----END PGP SIGNATURE----- --O3bhLwMadv7h6/J9-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 14:51:56 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23A5E1065672 for ; Fri, 24 Jul 2009 14:51:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E775C8FC1D for ; Fri, 24 Jul 2009 14:51:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 89FDA46B85; Fri, 24 Jul 2009 10:51:55 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 9B68E8A0A1; Fri, 24 Jul 2009 10:51:54 -0400 (EDT) From: John Baldwin To: Alexander Best Date: Fri, 24 Jul 2009 07:47:45 -0400 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907240747.45738.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 24 Jul 2009 10:51:54 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alexey Shuvaev , freebsd-hackers@freebsd.org Subject: Re: checking number of parallel ports installed and their port adresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 14:51:56 -0000 On Friday 24 July 2009 6:42:34 am Alexander Best wrote: > thanks for the hint. > > if spent a bit of time and turned the in/out opcodes to ppi ioctls. actually i > was very surprised about the results since you said the overhead wouldn't be > that big. > > uploading a 256 kbyte file i got the following results: > > using ppi: 17.120 seconds > using in/out opcodes: 8.001 seconds > > so i think i'll rather stick to my old inline assembly code even if it can't > be considered nice programming style, but the ppi overhead isn't something i > can cope with in my app. Hmmm, that is a bit much. Though I do suppose you are incurring a user -> kernel -> user transition for each I/O access. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 16:02:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2DED1065675; Fri, 24 Jul 2009 16:02:36 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id 5A6B68FC14; Fri, 24 Jul 2009 16:02:36 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.43,265,1246831200"; d="scan'208";a="278218390" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay1.uni-muenster.de with ESMTP; 24 Jul 2009 18:02:34 +0200 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id ACC691B0765; Fri, 24 Jul 2009 18:02:34 +0200 (CEST) Date: Fri, 24 Jul 2009 18:02:34 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: John Baldwin Message-ID: In-Reply-To: <200907240747.45738.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Alexey Shuvaev , freebsd-hackers@freebsd.org Subject: Re: checking number of parallel ports installed and their port adresses X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 16:02:37 -0000 well i'm performing a large number of port accesses since the data gets transferred bit-by-bit over a single parallel port pin with another pin acting as clock. so transfering 256 kbyte of data means i'm doing >= 256*1024*8*2 ioctls. i guess when transfering data on a nibble, byte, word or dword basis the overhead isn't that dramatic. alex John Baldwin schrieb am 2009-07-24: > On Friday 24 July 2009 6:42:34 am Alexander Best wrote: > > thanks for the hint. > > if spent a bit of time and turned the in/out opcodes to ppi ioctls. > > actually > i > > was very surprised about the results since you said the overhead > > wouldn't be > > that big. > > uploading a 256 kbyte file i got the following results: > > using ppi: 17.120 seconds > > using in/out opcodes: 8.001 seconds > > so i think i'll rather stick to my old inline assembly code even if > > it can't > > be considered nice programming style, but the ppi overhead isn't > > something i > > can cope with in my app. > Hmmm, that is a bit much. Though I do suppose you are incurring a > user -> > kernel -> user transition for each I/O access. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 16:17:46 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93714106566B for ; Fri, 24 Jul 2009 16:17:46 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mx1.freebsd.org (Postfix) with ESMTP id 12EDA8FC0A for ; Fri, 24 Jul 2009 16:17:45 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n6OGHgfa011280; Fri, 24 Jul 2009 18:17:42 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n6OGHgOx002191; Fri, 24 Jul 2009 18:17:42 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.3/8.14.3) id n6OGHgO7018913; Date: Fri, 24 Jul 2009 18:17:42 +0200 From: Andre Albsmeier To: John Baldwin Message-ID: <20090724161742.GA73257@curry.mchp.siemens.de> References: <200907230835.50814.jhb@freebsd.org> <200907231425.n6NEPeRH026492@ambrisko.com> <20090723175351.GA70584@curry.mchp.siemens.de> <200907231606.11904.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907231606.11904.jhb@freebsd.org> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, Andre Albsmeier Subject: Re: Reading acpi memory from a driver attached to hostb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 16:17:46 -0000 On Thu, 23-Jul-2009 at 16:06:11 -0400, John Baldwin wrote: > On Thursday 23 July 2009 1:53:51 pm Andre Albsmeier wrote: > > John, apparently you sent me an email (thanks a lot) which I never > > received (we have to blame our company's spam filters which I do > > not control). I'll comment on it here in my reply to Doug... > > Yes, I saw the bounces. Hopefully you see the list version of this. Yes, I've been lucky this time. > > > > | Did you try > > > | doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in > your > > > | driver that is a child of hostb0? > > > > I tried this, well, something similar: I had to do 4 times > > device_get_parent() to end up at acpi0: > > > > mydriver -> hostb0 -> pci0 -> pcib0 -> acpi0 > > You don't actually need to do that. pci0 will pass the request up to acpi0 That's what I hoped as well. > eventually. You just need to ask pci0 to allocate it for you and it will see > you are not a direct child and take the 'passthrough' case here: > > struct resource * > pci_alloc_resource(device_t dev, device_t child, int type, int *rid, > u_long start, u_long end, u_long count, u_int flags) > { > ... > > if (device_get_parent(child) != dev) > return (BUS_ALLOC_RESOURCE(device_get_parent(dev), child, > type, rid, start, end, count, flags)); > ... > } > > Rather than trying to allocate the whole chunk of the ACPI resource, I would > just do a specific allocation like so: > > rid = 0; > res = BUS_ALLOC_RESOURCE(device_get_parent(device_get_parent(dev)), > dev, SYS_RES_MEMORY, &rid, , end address>, , RF_ACTIVE); OK, I have modified my driver exactly this way, but still no success. It seems my code didn't make it to the list (the attachment was stripped) so I include it inline now. Testing is quite simple, every feedback is welcome: 1. check if "devinfo -r" spits out some free "I/O memory addresses" ranges under acpi0 with at minimum 4 bytes length. 2. select one of them and assign its start address to rstart in eccmon_probe() at the line which reads now u_long rstart = 0xfed14000; (this is the address I use for testing) 3. compile, kldload and dmesg. I always get the message "bus_alloc_resource() returned NULL". Thanks, -Andre -------------------- eccmon.c start ------------------------------------- #include #include #include #include #include #include #include #include #include #include struct eccmon_softc { device_t dev; int res_set; /* flag if bus_set_resource() was used successfully */ struct resource* res; int rid; }; /**********************/ /* eccmon_probe() */ /**********************/ static int eccmon_probe( const device_t const dev ) { u_long rstart = 0xfed14000; int ret; struct resource* res; int rid = 0; device_printf( dev, "probe: started for %x:%x\n", pci_get_vendor( dev ) , pci_get_device( dev ) ); /* * try to bus_alloc_resource the resource and give it back */ if( (res = BUS_ALLOC_RESOURCE( device_get_parent(device_get_parent(dev)), dev, SYS_RES_MEMORY, &rid, rstart, rstart+4, 4, RF_ACTIVE )) == NULL ) { device_printf( dev, "bus_alloc_resource() returned NULL\n" ); return ENXIO; } if( (ret = BUS_RELEASE_RESOURCE( device_get_parent(device_get_parent(dev)), dev, SYS_RES_MEMORY, rid, res )) != 0 ) device_printf( dev, "bus_release_resource() returned %d\n", ret ); return ENXIO; } /***********************/ /* eccmon_attach() */ /***********************/ static int eccmon_attach( const device_t const dev ) { device_printf( dev, "attach: started for %x:%x\n", pci_get_vendor( dev ) , pci_get_device( dev ) ); return ENXIO; } /***********************/ /* eccmon_detach() */ /***********************/ static int eccmon_detach( const device_t const dev ) { device_printf( dev, "detach: started for %x:%x\n", pci_get_vendor( dev ) , pci_get_device( dev ) ); return 0; } /*************************/ /* eccmon_identify() */ /*************************/ static void eccmon_identify( driver_t *driver, device_t p ) { device_printf( p, "identify: start: %x %x\n", pci_get_vendor( p ), pci_get_device( p ) ); device_printf( p, "identify on: %s %d\n", device_get_name( p ), device_get_unit(p) ); if( device_find_child( p, "eccmon", -1 ) == NULL && strcmp( device_get_name( p ), "hostb" ) == 0 && device_get_unit( p ) == 0 ) { device_t child = device_add_child( p, "eccmon", -1 ); device_printf( p, "identify added child: %p\n", child ); } } /***********************/ /* driver(9) stuff */ /***********************/ static device_method_t eccmon_methods[] = { DEVMETHOD( device_identify, eccmon_identify ), DEVMETHOD( device_probe, eccmon_probe ), DEVMETHOD( device_attach, eccmon_attach ), DEVMETHOD( device_detach, eccmon_detach ), { 0, 0 } }; static driver_t eccmon_driver = { "eccmon", eccmon_methods, sizeof( struct eccmon_softc ) }; static devclass_t eccmon_devclass; DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, NULL ); -------------------- eccmon.c end ------------------------------------- -------------------- Makefile start ------------------------------------- KMOD = eccmon SRCS = eccmon.c device_if.h bus_if.h pci_if.h NO_MAN = 1 CFLAGS+=-DDEVEL .include -------------------- Makefile end ------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 15:11:40 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 509C6106566B for ; Fri, 24 Jul 2009 15:11:40 +0000 (UTC) (envelope-from lgusenet@be-well.ilk.org) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by mx1.freebsd.org (Postfix) with ESMTP id 281318FC29 for ; Fri, 24 Jul 2009 15:11:40 +0000 (UTC) (envelope-from lgusenet@be-well.ilk.org) Received: (qmail 1983 invoked from network); 24 Jul 2009 15:11:39 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 24 Jul 2009 15:11:39 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id A395350822; Fri, 24 Jul 2009 11:11:38 -0400 (EDT) To: Jonathan McKeown References: <19939654343.20090722214221@mail.ru> <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> <44my6v8d97.fsf@be-well.ilk.org> <200907240902.09609.j.mckeown@ru.ac.za> From: Lowell Gilbert Date: Fri, 24 Jul 2009 11:11:38 -0400 In-Reply-To: <200907240902.09609.j.mckeown@ru.ac.za> (Jonathan McKeown's message of "Fri\, 24 Jul 2009 09\:02\:09 +0200") Message-ID: <44zlau6rpx.fsf@be-well.ilk.org> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 24 Jul 2009 17:41:39 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 15:11:40 -0000 Jonathan McKeown writes: > On Thursday 23 July 2009 20:28:52 Lowell Gilbert wrote: >> That's clever, but how would it work in practice, while common shells >> and scripting languages may not implement their side of it? > > http://www.in-ulm.de/~mascheck/various/shebang/ claims that it's been > implemented, in exactly the way described, in Solaris, OpenBSD and NetBSD > (albeit as a kernel compile-time option in the latter two). (It's apparently > also in IRIX and UnixWare). > > Given OpenBSD's admirable paranoia about security (hey, I'm a sysadmin: I > never ask myself if I'm being paranoid, but if I'm being paranoid enough!) > I'd have thought they would have explored the implications fully. They don't enable it by default, and they don't seem to recommend it. > Certainly other stuff knows about it. As I said yesterday, Perl describes the > problem in its perlsec manpage/perldoc. The perl interpreter even has a > build-time option, SETUID_SCRIPTS_ARE_SECURE_NOW - and the correct setting is > supposedly detected as part of configure. The problem I'm wondering about is that it doesn't matter what knows about it as long as there's an interpreter that *doesn't*. Anything that opens a script parameter on its own (there are other vulnerable approaches, but one's enough) will be insecure. I may well be missing something, of course. > There may well be some problems to overcome, but this doesn't appear to be > unexplored territory. Not entirely, but there may well be a reason it's never been in common use. - Lowell From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 21:29:41 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57C651065670 for ; Fri, 24 Jul 2009 21:29:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 8243C8FC1A for ; Fri, 24 Jul 2009 21:29:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 n6OLTGvH013024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Jul 2009 00:29:16 +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.3/8.14.3) with ESMTP id n6OLTGKW032998; Sat, 25 Jul 2009 00:29:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n6OLTGbs032997; Sat, 25 Jul 2009 00:29:16 +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, 25 Jul 2009 00:29:16 +0300 From: Kostik Belousov To: Ed Schouten Message-ID: <20090724212916.GQ55190@deviant.kiev.zoral.com.ua> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> <20090724115649.GV68469@hoeg.nl> <20090724130928.GJ54986@felucia.tataz.chchile.org> <20090724134953.GW68469@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nmEd1AIGA/JIgsXT" Content-Disposition: inline In-Reply-To: <20090724134953.GW68469@hoeg.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at 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 Cc: FreeBSD Hackers , Jeremie Le Hen Subject: Re: concurrent sysctl implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 21:29:41 -0000 --nmEd1AIGA/JIgsXT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 24, 2009 at 03:49:53PM +0200, Ed Schouten wrote: > * Jeremie Le Hen wrote: > > On Fri, Jul 24, 2009 at 01:56:49PM +0200, Ed Schouten wrote: > > > * Jeremie Le Hen wrote: > > > > On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > > > > > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > > > > > Hi Ed, > > > > > >=20 > > > > > > Sorry for the late reply. > > > > > >=20 > > > > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > > > > > We probably could. I think I discussed this with Robert Watso= n some time > > > > > > > ago and we could use things like ELF hints. But still, that d= oesn't > > > > > > > prevent us from reaching this limitation later on. > > > > > >=20 > > > > > > Can you elaborate a little? Are you talking about elf-hints.h? > > > > > > I don't see where we can get randomness from it. > > > > >=20 > > > > > The thing is called ELF auxillary information vector. It is used = to > > > > > supply some useful information for interpreter from the kernel, > > > > > see include/machine/elf.h for AT_* entries. > > > >=20 > > > > Ah ok, so the idea is to generate a new hint, for instance AT_RANDO= M, > > > > generated at link time, that will be used to fill the canary at exe= c(2) > > > > time? > > >=20 > > > Very short answer: yes! > >=20 > > Ok thanks. But this would make stack protection useless for local > > attacks on suid binaries that are world-readable since the attacker > > could read the ELF aux vector and compute the canary. =20 >=20 > Wait wait wait. It seems you were only partially right (and Kostik > corrected you): >=20 > We could add AT_RANDOM, but this value will be filled in by the kernel > when starting the process. This means the random value is not stored in > the binary. Below is the prototype that seems to work for me both with patched and old rtld on i386. Patch also contains bits for amd64 that I did not tested yet. All other arches are not buildable for now. Patch completely eliminates sysctl syscalls from the rtld and libc startup. Without the patch, a single run of /bin/ls did 6 sysctls, with the patch, no sysctls is queried at all. diff --git a/lib/libc/gen/__getosreldate.c b/lib/libc/gen/__getosreldate.c index 69aac07..6a4e5ea 100644 --- a/lib/libc/gen/__getosreldate.c +++ b/lib/libc/gen/__getosreldate.c @@ -29,6 +29,8 @@ __FBSDID("$FreeBSD$"); =20 #include #include +#include +#include =20 /* * This is private to libc. It is intended for wrapping syscall stubs in = order @@ -49,7 +51,15 @@ __getosreldate(void) =20 if (osreldate !=3D 0) return (osreldate); -=09 + + if (_rtld_aux_info !=3D NULL) + error =3D _rtld_aux_info(AT_OSRELDATE, &osreldate, + sizeof(osreldate)); + else + error =3D ENOSYS; + if (error =3D=3D 0 && osreldate !=3D 0) + return (osreldate); + oid[0] =3D CTL_KERN; oid[1] =3D KERN_OSRELDATE; osrel =3D 0; diff --git a/lib/libc/gen/getpagesize.c b/lib/libc/gen/getpagesize.c index d796b9d..b8f0ec1 100644 --- a/lib/libc/gen/getpagesize.c +++ b/lib/libc/gen/getpagesize.c @@ -36,6 +36,8 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#include +#include #include =20 /* @@ -52,13 +54,23 @@ getpagesize() int mib[2];=20 static int value; size_t size; + int error; + + if (value !=3D 0) + return (value); + + if (_rtld_aux_info !=3D NULL) + error =3D _rtld_aux_info(AT_PAGESZ, &value, sizeof(value)); + else + error =3D ENOSYS; + if (error =3D=3D 0 && value !=3D 0) + return (value); + + mib[0] =3D CTL_HW; + mib[1] =3D HW_PAGESIZE; + size =3D sizeof value; + if (sysctl(mib, 2, &value, &size, NULL, 0) =3D=3D -1) + return (-1); =20 - if (!value) { - mib[0] =3D CTL_HW; - mib[1] =3D HW_PAGESIZE; - size =3D sizeof value; - if (sysctl(mib, 2, &value, &size, NULL, 0) =3D=3D -1) - return (-1); - } return (value); } diff --git a/lib/libc/stdlib/malloc.c b/lib/libc/stdlib/malloc.c index 270d641..e479abe 100644 --- a/lib/libc/stdlib/malloc.c +++ b/lib/libc/stdlib/malloc.c @@ -179,6 +179,7 @@ __FBSDID("$FreeBSD$"); =20 #include #include +#include #include #include #include @@ -4769,7 +4770,10 @@ malloc_init_hard(void) unsigned i; int linklen; char buf[PATH_MAX + 1]; + int mib[2]; + size_t len; const char *opts; + int error; =20 malloc_mutex_lock(&init_lock); if (malloc_initialized) { @@ -4782,10 +4786,11 @@ malloc_init_hard(void) } =20 /* Get number of CPUs. */ - { - int mib[2]; - size_t len; - + if (_rtld_aux_info !=3D NULL) + error =3D _rtld_aux_info(AT_NCPUS, &ncpus, sizeof(ncpus)); + else + error =3D ENOSYS; + if (error !=3D 0 || ncpus =3D=3D 0) { mib[0] =3D CTL_HW; mib[1] =3D HW_NCPU; len =3D sizeof(ncpus); diff --git a/lib/libc/sys/stack_protector.c b/lib/libc/sys/stack_protector.c index 63beebc..571f63c 100644 --- a/lib/libc/sys/stack_protector.c +++ b/lib/libc/sys/stack_protector.c @@ -34,6 +34,8 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include +#include #include #include #include @@ -54,9 +56,17 @@ __guard_setup(void) { int mib[2]; size_t len; + int error; =20 if (__stack_chk_guard[0] !=3D 0) return; + if (_rtld_aux_info !=3D NULL) + error =3D _rtld_aux_info(AT_CANARY, __stack_chk_guard, + sizeof(__stack_chk_guard)); + else + error =3D ENOSYS; + if (error =3D=3D 0 && __stack_chk_guard[0] !=3D 0) + return; =20 mib[0] =3D CTL_KERN; mib[1] =3D KERN_ARND; diff --git a/libexec/rtld-elf/Symbol.map b/libexec/rtld-elf/Symbol.map index ce1e3e5..f45f955 100644 --- a/libexec/rtld-elf/Symbol.map +++ b/libexec/rtld-elf/Symbol.map @@ -24,4 +24,5 @@ FBSDprivate_1.0 { _rtld_free_tls; _rtld_atfork_pre; _rtld_atfork_post; + _rtld_aux_info; }; diff --git a/libexec/rtld-elf/amd64/reloc.c b/libexec/rtld-elf/amd64/reloc.c index 8a32adf..a510884 100644 --- a/libexec/rtld-elf/amd64/reloc.c +++ b/libexec/rtld-elf/amd64/reloc.c @@ -113,7 +113,7 @@ init_pltgot(Obj_Entry *obj) =20 /* Process the non-PLT relocations. */ int -reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld) +reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld, bool early) { const Elf_Rela *relalim; const Elf_Rela *rela; @@ -125,9 +125,13 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld) * The dynamic loader may be called from a thread, we have * limited amounts of stack available so we cannot use alloca(). */ - cache =3D mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); - if (cache =3D=3D MAP_FAILED) + if (early) cache =3D NULL; + else { + cache =3D mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); + if (cache =3D=3D MAP_FAILED) + cache =3D NULL; + } =20 relalim =3D (const Elf_Rela *) ((caddr_t) obj->rela + obj->relasize); for (rela =3D obj->rela; rela < relalim; rela++) { diff --git a/libexec/rtld-elf/i386/reloc.c b/libexec/rtld-elf/i386/reloc.c index ec83bff..2913d78 100644 --- a/libexec/rtld-elf/i386/reloc.c +++ b/libexec/rtld-elf/i386/reloc.c @@ -114,7 +114,7 @@ init_pltgot(Obj_Entry *obj) =20 /* Process the non-PLT relocations. */ int -reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld) +reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld, bool early) { const Elf_Rel *rellim; const Elf_Rel *rel; @@ -126,9 +126,13 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld) * The dynamic loader may be called from a thread, we have * limited amounts of stack available so we cannot use alloca(). */ - cache =3D mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); - if (cache =3D=3D MAP_FAILED) + if (early) cache =3D NULL; + else { + cache =3D mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); + if (cache =3D=3D MAP_FAILED) + cache =3D NULL; + } =20 rellim =3D (const Elf_Rel *) ((caddr_t) obj->rel + obj->relsize); for (rel =3D obj->rel; rel < rellim; rel++) { diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c index 721fe89..75a1c69 100644 --- a/libexec/rtld-elf/rtld.c +++ b/libexec/rtld-elf/rtld.c @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include @@ -84,6 +85,9 @@ typedef struct Struct_DoneList { */ static const char *basename(const char *); static void die(void) __dead2; +static void digest_dynamic1(Obj_Entry *, int, const Elf_Dyn **, + const Elf_Dyn **); +static void digest_dynamic2(Obj_Entry *, const Elf_Dyn *, const Elf_Dyn *); static void digest_dynamic(Obj_Entry *, int); static Obj_Entry *digest_phdr(const Elf_Phdr *, int, caddr_t, const char *= ); static Obj_Entry *dlcheck(void *); @@ -97,7 +101,7 @@ static char *find_library(const char *, const Obj_Entry = *); static const char *gethints(void); static void init_dag(Obj_Entry *); static void init_dag1(Obj_Entry *, Obj_Entry *, DoneList *); -static void init_rtld(caddr_t); +static void init_rtld(caddr_t, Elf_Auxinfo **); static void initlist_add_neededs(Needed_Entry *, Objlist *); static void initlist_add_objects(Obj_Entry *, Obj_Entry **, Objlist *); static bool is_exported(const Elf_Sym *); @@ -116,7 +120,7 @@ static void objlist_push_head(Objlist *, Obj_Entry *); static void objlist_push_tail(Objlist *, Obj_Entry *); static void objlist_remove(Objlist *, Obj_Entry *); static void *path_enumerate(const char *, path_enum_proc, void *); -static int relocate_objects(Obj_Entry *, bool, Obj_Entry *); +static int relocate_objects(Obj_Entry *, bool, Obj_Entry *, bool early); static int rtld_dirname(const char *, char *); static int rtld_dirname_abs(const char *, char *); static void rtld_exit(void); @@ -188,6 +192,9 @@ extern Elf_Dyn _DYNAMIC; #define RTLD_IS_DYNAMIC() (&_DYNAMIC !=3D NULL) #endif =20 +static int pagesize, osreldate, canary_len, ncpus; +static char *canary; + /* * These are the functions the dynamic linker exports to application * programs. They are the only symbols the dynamic linker is willing @@ -214,6 +221,7 @@ static func_ptr_type exports[] =3D { (func_ptr_type) &dl_iterate_phdr, (func_ptr_type) &_rtld_atfork_pre, (func_ptr_type) &_rtld_atfork_post, + (func_ptr_type) &_rtld_aux_info, NULL }; =20 @@ -350,7 +358,7 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_proc, Obj_Entry= **objp) =20 /* Initialize and relocate ourselves. */ assert(aux_info[AT_BASE] !=3D NULL); - init_rtld((caddr_t) aux_info[AT_BASE]->a_un.a_ptr); + init_rtld((caddr_t) aux_info[AT_BASE]->a_un.a_ptr, aux_info); =20 __progname =3D obj_rtld.path; argv0 =3D argv[0] !=3D NULL ? argv[0] : "(null)"; @@ -519,7 +527,7 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_proc, Obj_Entry= **objp) allocate_initial_tls(obj_list); =20 if (relocate_objects(obj_main, - ld_bind_now !=3D NULL && *ld_bind_now !=3D '\0', &obj_rtld) =3D=3D -1) + ld_bind_now !=3D NULL && *ld_bind_now !=3D '\0', &obj_rtld, false) =3D=3D= -1) die(); =20 dbg("doing copy relocations"); @@ -736,14 +744,16 @@ die(void) * information in its Obj_Entry structure. */ static void -digest_dynamic(Obj_Entry *obj, int early) +digest_dynamic1(Obj_Entry *obj, int early, const Elf_Dyn **dyn_rpath, + const Elf_Dyn **dyn_soname) { const Elf_Dyn *dynp; Needed_Entry **needed_tail =3D &obj->needed; - const Elf_Dyn *dyn_rpath =3D NULL; - const Elf_Dyn *dyn_soname =3D NULL; int plttype =3D DT_REL; =20 + *dyn_rpath =3D NULL; + *dyn_soname =3D NULL; + obj->bind_now =3D false; for (dynp =3D obj->dynamic; dynp->d_tag !=3D DT_NULL; dynp++) { switch (dynp->d_tag) { @@ -867,11 +877,11 @@ digest_dynamic(Obj_Entry *obj, int early) * We have to wait until later to process this, because we * might not have gotten the address of the string table yet. */ - dyn_rpath =3D dynp; + *dyn_rpath =3D dynp; break; =20 case DT_SONAME: - dyn_soname =3D dynp; + *dyn_soname =3D dynp; break; =20 case DT_INIT: @@ -958,6 +968,12 @@ digest_dynamic(Obj_Entry *obj, int early) obj->pltrelasize =3D obj->pltrelsize; obj->pltrelsize =3D 0; } +} + +static void +digest_dynamic2(Obj_Entry *obj, const Elf_Dyn *dyn_rpath, + const Elf_Dyn *dyn_soname) +{ =20 if (obj->z_origin && obj->origin_path =3D=3D NULL) { obj->origin_path =3D xmalloc(PATH_MAX); @@ -975,6 +991,16 @@ digest_dynamic(Obj_Entry *obj, int early) object_add_name(obj, obj->strtab + dyn_soname->d_un.d_val); } =20 +static void +digest_dynamic(Obj_Entry *obj, int early) +{ + const Elf_Dyn *dyn_rpath; + const Elf_Dyn *dyn_soname; + + digest_dynamic1(obj, early, &dyn_rpath, &dyn_soname); + digest_dynamic2(obj, dyn_rpath, dyn_soname); +} + /* * Process a shared object's program header. This is used only for the * main program, when the kernel has already loaded the main program @@ -1301,9 +1327,11 @@ init_dag1(Obj_Entry *root, Obj_Entry *obj, DoneList = *dlp) * this function is to relocate the dynamic linker. */ static void -init_rtld(caddr_t mapbase) +init_rtld(caddr_t mapbase, Elf_Auxinfo **aux_info) { Obj_Entry objtmp; /* Temporary rtld object */ + const Elf_Dyn *dyn_rpath; + const Elf_Dyn *dyn_soname; =20 /* * Conjure up an Obj_Entry structure for the dynamic linker. @@ -1320,27 +1348,38 @@ init_rtld(caddr_t mapbase) #endif if (RTLD_IS_DYNAMIC()) { objtmp.dynamic =3D rtld_dynamic(&objtmp); - digest_dynamic(&objtmp, 1); + digest_dynamic1(&objtmp, 1, &dyn_rpath, &dyn_soname); assert(objtmp.needed =3D=3D NULL); #if !defined(__mips__) /* MIPS and SH{3,5} have a bogus DT_TEXTREL. */ assert(!objtmp.textrel); #endif - /* * Temporarily put the dynamic linker entry into the object list, so * that symbols can be found. */ =20 - relocate_objects(&objtmp, true, &objtmp); + relocate_objects(&objtmp, true, &objtmp, true); } - /* Initialize the object list. */ obj_tail =3D &obj_list; =20 /* Now that non-local variables can be accesses, copy out obj_rtld. */ memcpy(&obj_rtld, &objtmp, sizeof(obj_rtld)); =20 + if (aux_info[AT_PAGESZ] !=3D NULL) + pagesize =3D aux_info[AT_PAGESZ]->a_un.a_val; + if (aux_info[AT_OSRELDATE] !=3D NULL) + osreldate =3D aux_info[AT_OSRELDATE]->a_un.a_val; + if (aux_info[AT_CANARY] !=3D NULL && aux_info[AT_CANARYLEN] !=3D NULL)= { + canary =3D aux_info[AT_CANARY]->a_un.a_ptr; + canary_len =3D aux_info[AT_CANARYLEN]->a_un.a_val; + } + if (aux_info[AT_NCPUS] !=3D NULL) + ncpus =3D aux_info[AT_NCPUS]->a_un.a_val; + + digest_dynamic2(&obj_rtld, dyn_rpath, dyn_soname); + /* Replace the path with a dynamically allocated copy. */ obj_rtld.path =3D xstrdup(PATH_RTLD); =20 @@ -1745,7 +1784,8 @@ objlist_remove(Objlist *list, Obj_Entry *obj) * or -1 on failure. */ static int -relocate_objects(Obj_Entry *first, bool bind_now, Obj_Entry *rtldobj) +relocate_objects(Obj_Entry *first, bool bind_now, Obj_Entry *rtldobj, + bool early) { Obj_Entry *obj; =20 @@ -1770,7 +1810,7 @@ relocate_objects(Obj_Entry *first, bool bind_now, Obj= _Entry *rtldobj) } =20 /* Process the non-PLT relocations. */ - if (reloc_non_plt(obj, rtldobj)) + if (reloc_non_plt(obj, rtldobj, early)) return -1; =20 if (obj->textrel) { /* Re-protected the text segment. */ @@ -2022,7 +2062,8 @@ dlopen(const char *name, int mode) if (result !=3D -1 && ld_tracing) goto trace; if (result =3D=3D -1 || - (relocate_objects(obj, mode =3D=3D RTLD_NOW, &obj_rtld)) =3D=3D -1)= { + (relocate_objects(obj, mode =3D=3D RTLD_NOW, &obj_rtld, false)) + =3D=3D -1) { obj->dl_refcount--; unref_dag(obj); if (obj->refcount =3D=3D 0) @@ -3611,3 +3652,110 @@ fetch_ventry(const Obj_Entry *obj, unsigned long sy= mnum) } return NULL; } + +static int +__getosreldate(void) +{ + static int osreldate; + size_t len; + int oid[2]; + int error, osrel; + + oid[0] =3D CTL_KERN; + oid[1] =3D KERN_OSRELDATE; + osrel =3D 0; + len =3D sizeof(osrel); + error =3D sysctl(oid, 2, &osrel, &len, NULL, 0); + if (error =3D=3D 0 && osrel > 0 && len =3D=3D sizeof(osrel)) + osreldate =3D osrel; + return (osreldate); +} + +static int +__getpagesize(void) +{ + int mib[2]; + static int value; + size_t size; + + mib[0] =3D CTL_HW; + mib[1] =3D HW_PAGESIZE; + size =3D sizeof value; + if (sysctl(mib, 2, &value, &size, NULL, 0) =3D=3D -1) + return (-1); + + return (value); +} + +static int +__getncpus(void) +{ + int mib[2]; + size_t len; + int n; + + mib[0] =3D CTL_HW; + mib[1] =3D HW_NCPU; + len =3D sizeof(ncpus); + if (sysctl(mib, 2, &n, &len, (void *) 0, 0) =3D=3D -1) + n =3D 1; + return (n); +} + +int +_rtld_aux_info(int aux, void *buf, int buflen) +{ + int res; + + switch (aux) { + case AT_CANARY: + if (canary !=3D NULL && canary_len >=3D buflen) { + memcpy(buf, canary, buflen); + memset(canary, 0, canary_len); + canary =3D NULL; + res =3D 0; + } else + res =3D ENOENT; + break; + case AT_PAGESZ: + if (buflen =3D=3D sizeof(int)) { + if (pagesize =3D=3D 0) + pagesize =3D __getpagesize(); + if (pagesize !=3D 0) { + *(int *)buf =3D pagesize; + res =3D 0; + } else + res =3D ENOENT; + } else + res =3D EINVAL; + break; + case AT_OSRELDATE: + if (buflen =3D=3D sizeof(int)) { + if (osreldate =3D=3D 0) + osreldate =3D __getosreldate(); + if (osreldate !=3D 0) { + *(int *)buf =3D osreldate; + res =3D 0; + } else + res =3D ENOENT; + } else + res =3D EINVAL; + break; + case AT_NCPUS: + if (buflen =3D=3D sizeof(int)) { + if (ncpus =3D=3D 0) + ncpus =3D __getncpus(); + if (ncpus !=3D 0) { + *(int *)buf =3D ncpus; + res =3D 0; + } else + res =3D ENOENT; + } else + res =3D EINVAL; + break; + default: + res =3D ENOENT; + break; + } + return (res); +} diff --git a/libexec/rtld-elf/rtld.h b/libexec/rtld-elf/rtld.h index 06086b4..928e3ed 100644 --- a/libexec/rtld-elf/rtld.h +++ b/libexec/rtld-elf/rtld.h @@ -286,7 +286,7 @@ const Ver_Entry *fetch_ventry(const Obj_Entry *obj, uns= igned long); * MD function declarations. */ int do_copy_relocations(Obj_Entry *); -int reloc_non_plt(Obj_Entry *, Obj_Entry *); +int reloc_non_plt(Obj_Entry *, Obj_Entry *, bool); int reloc_plt(Obj_Entry *); int reloc_jmpslots(Obj_Entry *); void allocate_initial_tls(Obj_Entry *); diff --git a/sys/amd64/include/elf.h b/sys/amd64/include/elf.h index e5c95f7..d541b9e 100644 --- a/sys/amd64/include/elf.h +++ b/sys/amd64/include/elf.h @@ -87,8 +87,12 @@ __ElfType(Auxinfo); #define AT_GID 13 /* Real gid. */ #define AT_EGID 14 /* Effective gid. */ #define AT_EXECPATH 15 /* Path to the executable. */ +#define AT_CANARY 16 /* Canary for SSP */ +#define AT_CANARYLEN 17 /* Length of the canary. */ +#define AT_OSRELDATE 18 /* OSRELDATE. */ +#define AT_NCPUS 19 /* Number of CPUs. */ =20 -#define AT_COUNT 16 /* Count of defined aux entry types. */ +#define AT_COUNT 20 /* Count of defined aux entry types. */ =20 /* * Relocation types. diff --git a/sys/compat/ia32/ia32_sysvec.c b/sys/compat/ia32/ia32_sysvec.c index af8168e..acf2c34 100644 --- a/sys/compat/ia32/ia32_sysvec.c +++ b/sys/compat/ia32/ia32_sysvec.c @@ -191,6 +191,7 @@ ia32_copyout_strings(struct image_params *imgp) struct freebsd32_ps_strings *arginfo; size_t execpath_len; int szsigcode; + char canary[sizeof(long) * 8]; =20 /* * Calculate string base and vector table pointers. @@ -203,8 +204,9 @@ ia32_copyout_strings(struct image_params *imgp) arginfo =3D (struct freebsd32_ps_strings *)FREEBSD32_PS_STRINGS; szsigcode =3D *(imgp->proc->p_sysent->sv_szsigcode); destp =3D (caddr_t)arginfo - szsigcode - SPARE_USRSPACE - - roundup(execpath_len, sizeof(char *)) - - roundup((ARG_MAX - imgp->args->stringspace), sizeof(char *)); + roundup(execpath_len, sizeof(char *)) - + roundup(sizeof(canary), sizeof(char *)) - + roundup((ARG_MAX - imgp->args->stringspace), sizeof(char *)); =20 /* * install sigcode @@ -223,6 +225,14 @@ ia32_copyout_strings(struct image_params *imgp) } =20 /* + * Prepare the canary for SSP. + */ + arc4rand(canary, sizeof(canary), 0); + imgp->canary =3D (uintptr_t)arginfo - szsigcode - execpath_len - + sizeof(canary); + copyout(canary, (void *)imgp->canary, sizeof(canary)); + + /* * If we have a valid auxargs ptr, prepare some room * on the stack. */ @@ -239,8 +249,8 @@ ia32_copyout_strings(struct image_params *imgp) * for argument of Runtime loader. */ vectp =3D (u_int32_t *) (destp - (imgp->args->argc + - imgp->args->envc + 2 + imgp->auxarg_size + execpath_len) * - sizeof(u_int32_t)); + imgp->args->envc + 2 + imgp->auxarg_size) + * sizeof(u_int32_t)); } else /* * The '+ 2' is for the null pointers at the end of each of diff --git a/sys/i386/include/elf.h b/sys/i386/include/elf.h index af71ab8..a959e68 100644 --- a/sys/i386/include/elf.h +++ b/sys/i386/include/elf.h @@ -90,8 +90,12 @@ __ElfType(Auxinfo); #define AT_GID 13 /* Real gid. */ #define AT_EGID 14 /* Effective gid. */ #define AT_EXECPATH 15 /* Path to the executable. */ +#define AT_CANARY 16 /* Canary for SSP. */ +#define AT_CANARYLEN 17 /* Length of the canary. */ +#define AT_OSRELDATE 18 /* OSRELDATE. */ +#define AT_NCPUS 19 /* Number of CPUs. */ =20 -#define AT_COUNT 16 /* Count of defined aux entry types. */ +#define AT_COUNT 20 /* Count of defined aux entry types. */ =20 /* * Relocation types. diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index e2c0a12..b2c1d45 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -50,6 +50,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -887,6 +888,12 @@ __elfN(freebsd_fixup)(register_t **stack_base, struct = image_params *imgp) AUXARGS_ENTRY(pos, AT_BASE, args->base); if (imgp->execpathp !=3D 0) AUXARGS_ENTRY(pos, AT_EXECPATH, imgp->execpathp); + AUXARGS_ENTRY(pos, AT_OSRELDATE, imgp->proc->p_osrel); + if (imgp->canary !=3D 0) { + AUXARGS_ENTRY(pos, AT_CANARY, imgp->canary); + AUXARGS_ENTRY(pos, AT_CANARYLEN, imgp->canarylen); + } + AUXARGS_ENTRY(pos, AT_NCPUS, mp_ncpus); AUXARGS_ENTRY(pos, AT_NULL, 0); =20 free(imgp->auxargs, M_TEMP); diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c index 3f36658..6bed93f 100644 --- a/sys/kern/kern_exec.c +++ b/sys/kern/kern_exec.c @@ -380,6 +380,8 @@ do_execve(td, args, mac_p) imgp->args =3D args; imgp->execpath =3D imgp->freepath =3D NULL; imgp->execpathp =3D 0; + imgp->canary =3D 0; + imgp->canarylen =3D 0; =20 #ifdef MAC error =3D mac_execve_enter(imgp, mac_p); @@ -1175,6 +1177,7 @@ exec_copyout_strings(imgp) struct proc *p; size_t execpath_len; int szsigcode; + char canary[sizeof(long) * 8]; =20 /* * Calculate string base and vector table pointers. @@ -1191,6 +1194,7 @@ exec_copyout_strings(imgp) szsigcode =3D *(p->p_sysent->sv_szsigcode); destp =3D (caddr_t)arginfo - szsigcode - SPARE_USRSPACE - roundup(execpath_len, sizeof(char *)) - + roundup(sizeof(canary), sizeof(char *)) - roundup((ARG_MAX - imgp->args->stringspace), sizeof(char *)); =20 /* @@ -1210,6 +1214,15 @@ exec_copyout_strings(imgp) } =20 /* + * Prepare the canary for SSP. + */ + arc4rand(canary, sizeof(canary), 0); + imgp->canary =3D (uintptr_t)arginfo - szsigcode - execpath_len - + sizeof(canary); + copyout(canary, (void *)imgp->canary, sizeof(canary)); + imgp->canarylen =3D sizeof(canary); + + /* * If we have a valid auxargs ptr, prepare some room * on the stack. */ @@ -1226,8 +1239,8 @@ exec_copyout_strings(imgp) * for argument of Runtime loader. */ vectp =3D (char **)(destp - (imgp->args->argc + - imgp->args->envc + 2 + imgp->auxarg_size + execpath_len) * - sizeof(char *)); + imgp->args->envc + 2 + imgp->auxarg_size) + * sizeof(char *)); } else { /* * The '+ 2' is for the null pointers at the end of each of diff --git a/sys/sys/imgact.h b/sys/sys/imgact.h index e6acc00..8acd184 100644 --- a/sys/sys/imgact.h +++ b/sys/sys/imgact.h @@ -69,6 +69,8 @@ struct image_params { char *execpath; unsigned long execpathp; char *freepath; + unsigned long canary; + int canarylen; }; =20 #ifdef _KERNEL diff --git a/sys/sys/link_elf.h b/sys/sys/link_elf.h index 98840a5..30f3d75 100644 --- a/sys/sys/link_elf.h +++ b/sys/sys/link_elf.h @@ -92,6 +92,10 @@ __BEGIN_DECLS =20 typedef int (*__dl_iterate_hdr_callback)(struct dl_phdr_info *, size_t, vo= id *); extern int dl_iterate_phdr(__dl_iterate_hdr_callback, void *); +extern int _rtld_aux_info(int, void *, int); +#ifndef IN_RTLD +#pragma weak _rtld_aux_info +#endif =20 __END_DECLS =20 --nmEd1AIGA/JIgsXT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpqJ6sACgkQC3+MBN1Mb4gcHACeKgssoIm9mDtZJ/1UcKVIeWfr JOYAoJRHu7mGijbYJVLJHFrYlwSXP9NQ =aN41 -----END PGP SIGNATURE----- --nmEd1AIGA/JIgsXT-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 25 01:47:44 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E22E6106566C for ; Sat, 25 Jul 2009 01:47:44 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from mail-fx0-f208.google.com (mail-fx0-f208.google.com [209.85.220.208]) by mx1.freebsd.org (Postfix) with ESMTP id 733188FC14 for ; Sat, 25 Jul 2009 01:47:44 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by fxm4 with SMTP id 4so42011fxm.43 for ; Fri, 24 Jul 2009 18:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pSqGNOzOMWbpbUewIPBA3P/aGKN/O5o00OhRMEOnqxw=; b=wry6RNTgmHURHobLoY/97VdjpLtdU6KwV6pHJJbJlMPub3V+z6yyuXQZke4NEmeuBR bOCX6Ll2V7trOWDnPYn8fAtv0IyohLwc+CuEhpAP9Qf4y4Axd3DV9YTvKQiZOhOvQhZZ 47cMrOCa31p/pNteT/99BEuQwptbca8Dep8aE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hh4jnn+CdhI1qF+hHSzyKMqScNSjnU6FOnCCSAkKuIJH+cR1FIHLS4LEr5PrOEOZzk zQiiW2y7J3vCZIt618epG9tMReS0ptFyaRZRcAufD3fVJRSSj90Xs4XsNAJL0wnqaDJC lt340JttyiLwEBdaEx+j3sTkIMRTE70sEeEz8= MIME-Version: 1.0 Received: by 10.239.175.131 with SMTP id n3mr400557hbf.82.1248486463476; Fri, 24 Jul 2009 18:47:43 -0700 (PDT) In-Reply-To: <19939654343.20090722214221@mail.ru> References: <19939654343.20090722214221@mail.ru> Date: Fri, 24 Jul 2009 22:47:43 -0300 Message-ID: From: "Carlos A. M. dos Santos" To: Anthony Pankov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 01:47:45 -0000 On Wed, Jul 22, 2009 at 2:42 PM, Anthony Pankov wrote: > > SGID/SUID bits don't work with shell scripts, do they? No. A possible workaround is have a SUID/SGID version of you interpreter and use it. Something like # pw groupadd -n sush -g 401 # cp /bin/sh /bin/sush # chown root:sush /bin/sush # chmod 4750 /bin/sush # pw usermod johndoe -G sush Then start your script with "#!/bin/sush" and user johndoe,as well as any member of the "sush" group will be able to it run as root. I think I don't need to warn you that they will be able to run *any* command as root, in fact. For a better approach, consider using sudo, instead (/usr/ports/security/sudo). -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 25 13:01:57 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 429A31065672 for ; Sat, 25 Jul 2009 13:01:57 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout6.freenet.de (mout6.freenet.de [IPv6:2001:748:100:40::2:8]) by mx1.freebsd.org (Postfix) with ESMTP id C9D108FC24 for ; Sat, 25 Jul 2009 13:01:56 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.10] (helo=0.mx.freenet.de) by mout6.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1MUgsu-0008Rz-5V; Sat, 25 Jul 2009 15:01:56 +0200 Received: from tfbf2.t.pppool.de ([89.55.251.242]:58635 helo=ernst.jennejohn.org) by 0.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #93) id 1MUgst-0004K9-T7; Sat, 25 Jul 2009 15:01:56 +0200 Date: Sat, 25 Jul 2009 15:01:54 +0200 From: Gary Jennejohn To: Kostik Belousov Message-ID: <20090725150154.4f36e0ce@ernst.jennejohn.org> In-Reply-To: <20090724212916.GQ55190@deviant.kiev.zoral.com.ua> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> <20090724115649.GV68469@hoeg.nl> <20090724130928.GJ54986@felucia.tataz.chchile.org> <20090724134953.GW68469@hoeg.nl> <20090724212916.GQ55190@deviant.kiev.zoral.com.ua> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: 149285::1248526916-00006070-8CF4038C/0-0/0-0 Cc: FreeBSD Hackers Subject: Re: concurrent sysctl implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 13:01:57 -0000 On Sat, 25 Jul 2009 00:29:16 +0300 Kostik Belousov wrote: > Below is the prototype that seems to work for me both with patched and > old rtld on i386. Patch also contains bits for amd64 that I did not > tested yet. All other arches are not buildable for now. > [patch deleted] I'm currently running the patch under AMD64 and haven't noticed any regressiosn yet. --- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 25 13:32:03 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 337561065672 for ; Sat, 25 Jul 2009 13:32:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 7AC268FC2B for ; Sat, 25 Jul 2009 13:32:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 n6PDVvej070354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Jul 2009 16:31:57 +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.3/8.14.3) with ESMTP id n6PDVvUR055188; Sat, 25 Jul 2009 16:31:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n6PDVvnP055187; Sat, 25 Jul 2009 16:31:57 +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, 25 Jul 2009 16:31:57 +0300 From: Kostik Belousov To: Gary Jennejohn Message-ID: <20090725133157.GT55190@deviant.kiev.zoral.com.ua> References: <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> <20090724115649.GV68469@hoeg.nl> <20090724130928.GJ54986@felucia.tataz.chchile.org> <20090724134953.GW68469@hoeg.nl> <20090724212916.GQ55190@deviant.kiev.zoral.com.ua> <20090725150154.4f36e0ce@ernst.jennejohn.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j48bLZbs/yxfL7tN" Content-Disposition: inline In-Reply-To: <20090725150154.4f36e0ce@ernst.jennejohn.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at 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 Cc: FreeBSD Hackers Subject: Re: concurrent sysctl implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 13:32:03 -0000 --j48bLZbs/yxfL7tN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 25, 2009 at 03:01:54PM +0200, Gary Jennejohn wrote: > On Sat, 25 Jul 2009 00:29:16 +0300 > Kostik Belousov wrote: >=20 > > Below is the prototype that seems to work for me both with patched and > > old rtld on i386. Patch also contains bits for amd64 that I did not > > tested yet. All other arches are not buildable for now. > >=20 > [patch deleted] >=20 > I'm currently running the patch under AMD64 and haven't noticed any > regressiosn yet. Thank you. It is interesting how much sysctls are issued for startup. Easier way to see that is to ktrace /bin/ls and then do kdump | grep SCTL. --j48bLZbs/yxfL7tN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkprCUwACgkQC3+MBN1Mb4g0JACdHYuPLvHxhvfBke5V5Wfa3Ps0 nvcAoIrB76lsJRwjGGr3B0Fmrbgxz0Ts =mJNw -----END PGP SIGNATURE----- --j48bLZbs/yxfL7tN-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 25 13:56:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08463106566B; Sat, 25 Jul 2009 13:56:37 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7C28FC17; Sat, 25 Jul 2009 13:56:36 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n6PDuXRu004403; Sat, 25 Jul 2009 15:56:33 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n6PDuX13031726; Sat, 25 Jul 2009 15:56:33 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.3/8.14.3) id n6PDuXqj022761; Date: Sat, 25 Jul 2009 15:56:32 +0200 From: Andre Albsmeier To: John Baldwin Message-ID: <20090725135632.GA77656@curry.mchp.siemens.de> References: <200907230835.50814.jhb@freebsd.org> <200907231425.n6NEPeRH026492@ambrisko.com> <20090723175351.GA70584@curry.mchp.siemens.de> <200907231606.11904.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907231606.11904.jhb@freebsd.org> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, Andre Albsmeier Subject: SOLVED: Reading acpi memory from a driver attached to hostb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 13:56:37 -0000 On Thu, 23-Jul-2009 at 16:06:11 -0400, John Baldwin wrote: > On Thursday 23 July 2009 1:53:51 pm Andre Albsmeier wrote: > > John, apparently you sent me an email (thanks a lot) which I never > > received (we have to blame our company's spam filters which I do > > not control). I'll comment on it here in my reply to Doug... > > Yes, I saw the bounces. Hopefully you see the list version of this. > > > > | Did you try > > > | doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in > your > > > | driver that is a child of hostb0? > > > > I tried this, well, something similar: I had to do 4 times > > device_get_parent() to end up at acpi0: > > > > mydriver -> hostb0 -> pci0 -> pcib0 -> acpi0 > > You don't actually need to do that. pci0 will pass the request up to acpi0 > eventually. You just need to ask pci0 to allocate it for you and it will see > you are not a direct child and take the 'passthrough' case here: > > struct resource * > pci_alloc_resource(device_t dev, device_t child, int type, int *rid, > u_long start, u_long end, u_long count, u_int flags) > { > ... > > if (device_get_parent(child) != dev) > return (BUS_ALLOC_RESOURCE(device_get_parent(dev), child, > type, rid, start, end, count, flags)); > ... > } > > Rather than trying to allocate the whole chunk of the ACPI resource, I would > just do a specific allocation like so: > > rid = 0; > res = BUS_ALLOC_RESOURCE(device_get_parent(device_get_parent(dev)), > dev, SYS_RES_MEMORY, &rid, , end address>, , RF_ACTIVE); I finally got it working. Many thanks to all, especially to Doug and John. It should have worked all the time with John's code above but due to a stupidity on my part (I specified "end" as "start + count" and not as "start + count - 1") the allocation failed. It was Doug's suggestion to disable resource allocation in acpi.c -- so the memory area was unused and I could allocate it. After entering some debugging code into acpi_resource.c and acpi.c, which do not forgive errors like the above, I found my bug ;-) No I learned a bit about acpi and found curious things like this: When using BUS_ALLOC_RESOURCE( device_get_parent(device_get_parent(dev)), ... it is pci0 appearing in acpi_alloc_resource() to allocate the resource with the parameters I specify (count == 0x4000). When using only BUS_ALLOC_RESOURCE( device_get_parent(dev), ... it is hostb0 appearing in acpi_alloc_resource() but count got changed to 0x80. However start and end remain unchanged and do not match end = start + count - 1 anymore. Thanks again, -Andre