From owner-freebsd-arch Sun Jul 22 1: 2:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (discworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id DAC3037B401 for ; Sun, 22 Jul 2001 01:02:25 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 5770 invoked by uid 1000); 22 Jul 2001 08:06:27 -0000 Date: Sun, 22 Jul 2001 11:06:26 +0300 From: Peter Pentchev To: arch@FreeBSD.org Subject: Re: kern/29131: Current hungs in sysctl -a while booting + patch Message-ID: <20010722110626.A819@ringworld.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org References: <200107220334.f6M3YRe01219@kan.dnsalias.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107220334.f6M3YRe01219@kan.dnsalias.net>; from kabaev@mail.ru on Sat, Jul 21, 2001 at 11:34:27PM -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, Can anyone envision any side effects from committing the patch in this PR? Seems like a trivial fix for a typo to me.. G'luck, Peter -- If I were you, who would be reading this sentence? On Sat, Jul 21, 2001 at 11:34:27PM -0400, Alexander N. Kabaev wrote: > > >Number: 29131 > >Category: kern > >Synopsis: Current hungs in sysctl -a while booting + patch > >Originator: Alexander N. Kabaev > >Release: FreeBSD 5.0-CURRENT i386 > >Organization: > Verizon > >Environment: > System: FreeBSD kan.dnsalias.net 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Sat Jul 21 23:05:49 EDT 2001 root@kan.dnsalias.net:/usr/src/sys/i386/compile/KAN i386 > > >Description: > -CURRENT appears to hung while booting because sysctl -a never > finishes. ^C can be used to interrupt the sysctl execution and > to continue booting. > > It appears, that a sysctl oid_number collision is happening. Namely, > sysctl_register_oid allocates new numbers for OID_AUTO sysctl nodes > starting from the number 100, while at the same time kernel registers > predefined sysctls with ids as high as 255 (see SYSCTL_NODE for > net.inet.raw). If I raise the starting number for dynamic sysctls > to be 255, the problem disappears. > > >How-To-Repeat: > N/A > >Fix: > > Index: kern_sysctl.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/kern_sysctl.c,v > retrieving revision 1.110 > diff -u -u -r1.110 kern_sysctl.c > --- kern_sysctl.c 2001/06/22 19:54:38 1.110 > +++ kern_sysctl.c 2001/07/22 03:04:45 > @@ -113,7 +113,7 @@ > * 100 to leave space for pre-assigned oid numbers. > */ > if (oidp->oid_number == OID_AUTO) { > - static int newoid = 100; > + static int newoid = 0x100; > > oidp->oid_number = newoid++; > if (newoid == 0x7fffffff) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 22 1:43: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id A3F8037B403 for ; Sun, 22 Jul 2001 01:42:59 -0700 (PDT) (envelope-from bright@sneakerz.org) Received: by sneakerz.org (Postfix, from userid 1092) id E91365D01F; Sun, 22 Jul 2001 03:42:33 -0500 (CDT) Date: Sun, 22 Jul 2001 03:42:33 -0500 From: Alfred Perlstein To: Peter Pentchev Cc: arch@FreeBSD.org Subject: Re: kern/29131: Current hungs in sysctl -a while booting + patch Message-ID: <20010722034233.B49508@sneakerz.org> References: <200107220334.f6M3YRe01219@kan.dnsalias.net> <20010722110626.A819@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010722110626.A819@ringworld.oblivion.bg>; from roam@orbitel.bg on Sun, Jul 22, 2001 at 11:06:26AM +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Peter Pentchev [010722 03:02] wrote: > Hi, > > Can anyone envision any side effects from committing the patch > in this PR? Seems like a trivial fix for a typo to me.. Shouldn't "magic" constants be put into the sysctl.h header? > > >Number: 29131 > > >Category: kern > > >Synopsis: Current hungs in sysctl -a while booting + patch > > > > Index: kern_sysctl.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/kern/kern_sysctl.c,v > > retrieving revision 1.110 > > diff -u -u -r1.110 kern_sysctl.c > > --- kern_sysctl.c 2001/06/22 19:54:38 1.110 > > +++ kern_sysctl.c 2001/07/22 03:04:45 > > @@ -113,7 +113,7 @@ > > * 100 to leave space for pre-assigned oid numbers. > > */ > > if (oidp->oid_number == OID_AUTO) { > > - static int newoid = 100; > > + static int newoid = 0x100; > > > > oidp->oid_number = newoid++; > > if (newoid == 0x7fffffff) -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 22 4:59:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 7303037B40B for ; Sun, 22 Jul 2001 04:59:23 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id NAA24983; Sun, 22 Jul 2001 13:59:22 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Subject: moving struct module out of kern_module.c From: Dag-Erling Smorgrav Date: 22 Jul 2001 13:59:21 +0200 Message-ID: Lines: 7 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Currently, struct module is defined in kern_module.c and opaque to the rest of the kernel. I'd like to move the definition out into module.h so linprocfs can access it. Any objections? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 22 5: 1:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 5DC9837B406 for ; Sun, 22 Jul 2001 05:01:11 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id OAA25009; Sun, 22 Jul 2001 14:01:10 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@FreeBSD.ORG Subject: Re: moving struct module out of kern_module.c References: From: Dag-Erling Smorgrav Date: 22 Jul 2001 14:01:09 +0200 In-Reply-To: Message-ID: Lines: 8 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --=-=-= I forgot to attach the patch... DES -- Dag-Erling Smorgrav - des@ofug.org --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=module.diff Index: sys/module.h =================================================================== RCS file: /home/ncvs/src/sys/sys/module.h,v retrieving revision 1.16 diff -u -r1.16 module.h --- sys/module.h 2001/06/19 21:40:14 1.16 +++ sys/module.h 2001/07/22 11:59:55 @@ -46,7 +46,17 @@ MOD_SHUTDOWN } modeventtype_t; -typedef struct module *module_t; +typedef struct module { + TAILQ_ENTRY(module) link; /* chain together all modules */ + TAILQ_ENTRY(module) flink; /* all modules in a file */ + struct linker_file* file; /* file which contains this module */ + int refs; /* reference count */ + int id; /* unique id number */ + char *name; /* module name */ + modeventhand_t handler; /* event handler */ + void *arg; /* argument for handler */ + modspecific_t data; /* module specific data */ +} *module_t; typedef int (*modeventhand_t)(module_t mod, int /*modeventtype_t*/ what, void *arg); Index: kern/kern_module.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_module.c,v retrieving revision 1.26 diff -u -r1.26 kern_module.c --- kern/kern_module.c 2001/02/04 13:12:21 1.26 +++ kern/kern_module.c 2001/07/22 11:59:37 @@ -40,17 +40,6 @@ static MALLOC_DEFINE(M_MODULE, "module", "module data structures"); typedef TAILQ_HEAD(, module) modulelist_t; -struct module { - TAILQ_ENTRY(module) link; /* chain together all modules */ - TAILQ_ENTRY(module) flink; /* all modules in a file */ - struct linker_file* file; /* file which contains this module */ - int refs; /* reference count */ - int id; /* unique id number */ - char *name; /* module name */ - modeventhand_t handler; /* event handler */ - void *arg; /* argument for handler */ - modspecific_t data; /* module specific data */ -}; #define MOD_EVENT(mod, type) (mod)->handler((mod), (type), (mod)->arg) --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 22 5:16:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 7BDE437B401 for ; Sun, 22 Jul 2001 05:16:50 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id OAA25089; Sun, 22 Jul 2001 14:16:49 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@FreeBSD.ORG Subject: Re: moving struct module out of kern_module.c References: From: Dag-Erling Smorgrav Date: 22 Jul 2001 14:16:49 +0200 In-Reply-To: Message-ID: Lines: 12 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --=-=-= Dag-Erling Smorgrav writes: > I forgot to attach the patch... And of course it doesn't build, because the ordering is wrong. I've attached a corrected patch. DES -- Dag-Erling Smorgrav - des@ofug.org --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=module.diff Index: sys/module.h =================================================================== RCS file: /home/ncvs/src/sys/sys/module.h,v retrieving revision 1.16 diff -u -r1.16 module.h --- sys/module.h 2001/06/19 21:40:14 1.16 +++ sys/module.h 2001/07/22 12:14:14 @@ -46,7 +46,7 @@ MOD_SHUTDOWN } modeventtype_t; -typedef struct module *module_t; +typedef struct module *module_t; typedef int (*modeventhand_t)(module_t mod, int /*modeventtype_t*/ what, void *arg); @@ -92,6 +92,18 @@ int md_type; /* type of entry MDT_* */ void *md_data; /* specific data */ const char *md_cval; /* common string label */ +}; + +struct module { + TAILQ_ENTRY(module) link; /* chain together all modules */ + TAILQ_ENTRY(module) flink; /* all modules in a file */ + struct linker_file* file; /* file which contains this module */ + int refs; /* reference count */ + int id; /* unique id number */ + char *name; /* module name */ + modeventhand_t handler; /* event handler */ + void *arg; /* argument for handler */ + modspecific_t data; /* module specific data */ }; #ifdef _KERNEL Index: kern/kern_module.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_module.c,v retrieving revision 1.26 diff -u -r1.26 kern_module.c --- kern/kern_module.c 2001/02/04 13:12:21 1.26 +++ kern/kern_module.c 2001/07/22 11:59:37 @@ -40,17 +40,6 @@ static MALLOC_DEFINE(M_MODULE, "module", "module data structures"); typedef TAILQ_HEAD(, module) modulelist_t; -struct module { - TAILQ_ENTRY(module) link; /* chain together all modules */ - TAILQ_ENTRY(module) flink; /* all modules in a file */ - struct linker_file* file; /* file which contains this module */ - int refs; /* reference count */ - int id; /* unique id number */ - char *name; /* module name */ - modeventhand_t handler; /* event handler */ - void *arg; /* argument for handler */ - modspecific_t data; /* module specific data */ -}; #define MOD_EVENT(mod, type) (mod)->handler((mod), (type), (mod)->arg) --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 22 5:55:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id CEF9D37B403 for ; Sun, 22 Jul 2001 05:55:55 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA03038; Sun, 22 Jul 2001 22:55:49 +1000 Date: Sun, 22 Jul 2001 22:52:38 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: moving struct module out of kern_module.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 22 Jul 2001, Dag-Erling Smorgrav wrote: > Currently, struct module is defined in kern_module.c and opaque to the > rest of the kernel. I'd like to move the definition out into module.h > so linprocfs can access it. Any objections? Yes, It's supposed to be opaque. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 22 12:43: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id AC13E37B405 for ; Sun, 22 Jul 2001 12:43:07 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.247.136.127.Dial1.SanJose1.Level3.net [209.247.136.127]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id MAA28420; Sun, 22 Jul 2001 12:43:03 -0700 (PDT) Message-ID: <3B5B2CED.FB89F773@mindspring.com> Date: Sun, 22 Jul 2001 12:43:41 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Pentchev Cc: arch@FreeBSD.org Subject: Re: kern/29131: Current hungs in sysctl -a while booting + patch References: <200107220334.f6M3YRe01219@kan.dnsalias.net> <20010722110626.A819@ringworld.oblivion.bg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Pentchev wrote: > > Hi, > > Can anyone envision any side effects from committing the patch > in this PR? Seems like a trivial fix for a typo to me.. Side effects... people will start complaining about the next thinbg down the list, once this works? 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 22 13:13:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id 141CB37B403 for ; Sun, 22 Jul 2001 13:13:23 -0700 (PDT) (envelope-from bright@sneakerz.org) Received: by sneakerz.org (Postfix, from userid 1092) id B300E5D01F; Sun, 22 Jul 2001 15:13:22 -0500 (CDT) Date: Sun, 22 Jul 2001 15:13:22 -0500 From: Alfred Perlstein To: Bruce Evans Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: moving struct module out of kern_module.c Message-ID: <20010722151322.F49508@sneakerz.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from bde@zeta.org.au on Sun, Jul 22, 2001 at 10:52:38PM +1000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Bruce Evans [010722 07:56] wrote: > On 22 Jul 2001, Dag-Erling Smorgrav wrote: > > > Currently, struct module is defined in kern_module.c and opaque to the > > rest of the kernel. I'd like to move the definition out into module.h > > so linprocfs can access it. Any objections? > > Yes, It's supposed to be opaque. Agreed, if anything add a functional interface to grab the info and perform the manipulations that you need. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 22 13:18:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 30D2B37B403 for ; Sun, 22 Jul 2001 13:18:25 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f6MKJBI01159; Sun, 22 Jul 2001 13:19:11 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200107222019.f6MKJBI01159@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: moving struct module out of kern_module.c In-reply-to: Your message of "22 Jul 2001 13:59:21 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 22 Jul 2001 13:19:11 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Currently, struct module is defined in kern_module.c and opaque to the > rest of the kernel. I'd like to move the definition out into module.h > so linprocfs can access it. Any objections? Why? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 22 14: 0:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (discworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 5128037B406 for ; Sun, 22 Jul 2001 14:00:21 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 3012 invoked by uid 1000); 22 Jul 2001 20:59:34 -0000 Date: Sun, 22 Jul 2001 23:59:34 +0300 From: Peter Pentchev To: freebsd-gnats-submit@FreeBSD.org Cc: arch@FreeBSD.org Subject: Re: kern/29131: Current hungs in sysctl -a while booting + patch Message-ID: <20010722235934.G882@ringworld.oblivion.bg> Mail-Followup-To: freebsd-gnats-submit@FreeBSD.org, arch@FreeBSD.org References: <200107220334.f6M3YRe01219@kan.dnsalias.net> <20010722110626.A819@ringworld.oblivion.bg> <20010722034233.B49508@sneakerz.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010722034233.B49508@sneakerz.org>; from bright@sneakerz.org on Sun, Jul 22, 2001 at 03:42:33AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jul 22, 2001 at 03:42:33AM -0500, Alfred Perlstein wrote: > * Peter Pentchev [010722 03:02] wrote: > > Hi, > > > > Can anyone envision any side effects from committing the patch > > in this PR? Seems like a trivial fix for a typo to me.. > > Shouldn't "magic" constants be put into the sysctl.h header? Good call! Attached are two patches: one to make sys/kern/kern_sysctl.c a bit more style(9)-compliant (what made me do it was the failed search for /^sysctl_register_oid/ when I saw it referenced), and one to put a magic constant into sysctl.h and make kern_sysctl.c use it and complain (albeit a bit harshly ;) about misbehaving static sysctl's. Comments? G'luck, Peter -- If I were you, who would be reading this sentence? --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kern_sysctl.c-style.patch" Index: src/sys/kern/kern_sysctl.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_sysctl.c,v retrieving revision 1.110 diff -u -r1.110 kern_sysctl.c --- src/sys/kern/kern_sysctl.c 2001/06/22 19:54:38 1.110 +++ src/sys/kern/kern_sysctl.c 2001/07/22 20:38:15 @@ -87,7 +87,8 @@ * Order by number in each list. */ -void sysctl_register_oid(struct sysctl_oid *oidp) +void +sysctl_register_oid(struct sysctl_oid *oidp) { struct sysctl_oid_list *parent = oidp->oid_parent; struct sysctl_oid *p; @@ -135,7 +136,8 @@ SLIST_INSERT_HEAD(parent, oidp, oid_link); } -void sysctl_unregister_oid(struct sysctl_oid *oidp) +void +sysctl_unregister_oid(struct sysctl_oid *oidp) { SLIST_REMOVE(oidp->oid_parent, oidp, sysctl_oid, oid_link); } @@ -371,7 +373,8 @@ */ SET_DECLARE(sysctl_set, struct sysctl_oid); -static void sysctl_register_all(void *arg) +static void +sysctl_register_all(void *arg) { struct sysctl_oid **oidp; @@ -1084,7 +1087,8 @@ * must be in kernel space. */ int -userland_sysctl(struct proc *p, int *name, u_int namelen, void *old, size_t *oldlenp, int inkernel, void *new, size_t newlen, size_t *retval) +userland_sysctl(struct proc *p, int *name, u_int namelen, void *old, + size_t *oldlenp, int inkernel, void *new, size_t newlen, size_t *retval) { int error = 0; struct sysctl_req req, req2; --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sysctl-auto-start.patch" Index: src/sys/kern/kern_sysctl.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_sysctl.c,v retrieving revision 1.110 diff -u -r1.110 kern_sysctl.c --- src/sys/kern/kern_sysctl.c 2001/06/22 19:54:38 1.110 +++ src/sys/kern/kern_sysctl.c 2001/07/22 20:46:50 @@ -113,11 +113,13 @@ * 100 to leave space for pre-assigned oid numbers. */ if (oidp->oid_number == OID_AUTO) { - static int newoid = 100; + static int newoid = CTL_AUTO_START; oidp->oid_number = newoid++; if (newoid == 0x7fffffff) panic("out of oids"); + } else if (oidp->oid_number >= CTL_AUTO_START) { + panic("static sysctl oid too high: %d", oidp->oid_number); } /* Index: src/sys/sys/sysctl.h =================================================================== RCS file: /home/ncvs/src/sys/sys/sysctl.h,v retrieving revision 1.97 diff -u -r1.97 sysctl.h --- src/sys/sys/sysctl.h 2001/06/22 06:35:19 1.97 +++ src/sys/sys/sysctl.h 2001/07/22 20:46:55 @@ -95,6 +95,12 @@ */ #define OID_AUTO (-1) +/* + * The starting number for dynamically-assigned entries. WARNING! + * ALL static sysctl entries should have numbers LESS than this! + */ +#define CTL_AUTO_START 0x100 + #ifdef _KERNEL #define SYSCTL_HANDLER_ARGS struct sysctl_oid *oidp, void *arg1, int arg2, \ struct sysctl_req *req --Nq2Wo0NMKNjxTN9z-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 22 14: 8: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from assaris.sics.se (dhcp114.iss.kth.se [130.237.7.114]) by hub.freebsd.org (Postfix) with ESMTP id 5818D37B405; Sun, 22 Jul 2001 14:07:57 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id XAA30980; Sun, 22 Jul 2001 23:08:13 +0200 (CEST) (envelope-from assar) To: Mike Heffner Cc: obrien@FreeBSD.ORG, arch@FreeBSD.ORG, dan@FreeBSD.ORG Subject: Re: Importing lukemftpd References: From: Assar Westerlund Date: 22 Jul 2001 23:08:13 +0200 In-Reply-To: Mike Heffner's message of "Sun, 22 Jul 2001 00:11:42 -0400 (EDT)" Message-ID: <5lwv50isea.fsf@assaris.sics.se> Lines: 10 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Heffner writes: > Right now I just have two diffs in there, the first is a > 's/GLOB_LIMIT/GLOB_MAXPATH' which prevents it from segfaulting when doing any > globbing I believe the plan is actually to do the rename in glob(3) to be compatible with the other *BSDs. At least nobody objected when I proposed that. /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 22 14:41:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (discworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 931F437B401 for ; Sun, 22 Jul 2001 14:41:20 -0700 (PDT) (envelope-from roam@ringworld.nanolink.com) Received: (qmail 3493 invoked by uid 1000); 22 Jul 2001 21:40:34 -0000 Date: Mon, 23 Jul 2001 00:40:34 +0300 From: Peter Pentchev To: arch@FreeBSD.org Cc: audit@FreeBSD.org Subject: sysctl(8) enhancement: display sysctl MIB's Message-ID: <20010723004034.I882@ringworld.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org, audit@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, During the testing of the kern_sysctl.c patches for PR xxxxx, I came across a feature missing from the sysctl user interface - there was no easy way to obtain a list of sysctl's and their MIB's to see if the PR submitter was actually correct that there were cases when dynamic sysctl's were placed amidst static ones. sysctl(8), the logical place to look for such an interface, turned out to have none. Attached is a patch which adds a new command-line flag, -m, to display MIB's before names. Since the MIB's are of arbitrary length, there is no easy way to line them up, short of buffering the entire sysctl output to determine the maximum size. Since this is only of limited use (debugging new sysctl entries' placement), people who use it could be bothered to use a standalone formatter (Perl and awk come to mind ;) to prettify the output. Comments? Yep, I know that this is only of limited use, but still, it turned out to be useful in at least one case. G'luck, Peter -- I am jealous of the first word in this sentence. Index: src/sbin/sysctl/sysctl.8 =================================================================== RCS file: /home/ncvs/src/sbin/sysctl/sysctl.8,v retrieving revision 1.36 diff -u -r1.36 sysctl.8 --- src/sbin/sysctl/sysctl.8 2001/07/13 09:09:48 1.36 +++ src/sbin/sysctl/sysctl.8 2001/07/22 21:36:26 @@ -40,7 +40,7 @@ .Nd get or set kernel state .Sh SYNOPSIS .Nm -.Op Fl bNnox +.Op Fl bmNnox .Ar name Ns Op = Ns Ar value .Ar ... .Nm @@ -71,6 +71,11 @@ Force the value of the variable(s) to be output in raw, binary format. No names are printed and no terminating newlines are output. This is mostly useful with a single variable. +.It Fl m +Specify that the MIB numerical value should be printed before the name. +This flag only takes effect if +.Fl n +is not specified. .It Fl N Show only variable names, not their values. This is particularly useful with shells that offer programmable Index: src/sbin/sysctl/sysctl.c =================================================================== RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v retrieving revision 1.37 diff -u -r1.37 sysctl.c --- src/sbin/sysctl/sysctl.c 2001/06/18 21:06:24 1.37 +++ src/sbin/sysctl/sysctl.c 2001/07/22 21:36:28 @@ -58,10 +58,11 @@ #include #include -static int aflag, bflag, Nflag, nflag, oflag, xflag; +static int aflag, bflag, mflag, Nflag, nflag, oflag, xflag; static int oidfmt(int *, int, char *, u_int *); static void parse(char *); +static int show_varname(const char *, const int *, int); static int show_var(int *, int); static int sysctl_all (int *oid, int len); static int name2oid(char *, int *); @@ -71,8 +72,8 @@ { (void)fprintf(stderr, "%s\n%s\n", - "usage: sysctl [-bNnox] variable[=value] ...", - " sysctl [-bNnox] -a"); + "usage: sysctl [-bmNnox] variable[=value] ...", + " sysctl [-bmNnox] -a"); exit(1); } @@ -83,7 +84,7 @@ setbuf(stdout,0); setbuf(stderr,0); - while ((ch = getopt(argc, argv, "AabNnowxX")) != -1) { + while ((ch = getopt(argc, argv, "AabmNnowxX")) != -1) { switch (ch) { case 'A': /* compatibility */ @@ -95,6 +96,9 @@ case 'b': bflag = 1; break; + case 'm': + mflag = 1; + break; case 'N': Nflag = 1; break; @@ -369,6 +373,33 @@ } /* + * This formats and outputs the name of one variable. + * If the -m command-line flag was specified, the MIB value + * is also printed out. + * + * Returns zero on success. + * No error conditions yet (XXX: check printf() return value? :) + */ + +static int +show_varname(const char *name, const int *oid, int len) +{ + int i; + + if (nflag) + return (0); + + if (mflag) { + for (i = 0; i < len-1; i++) + printf("%X.", oid[i]); + printf("%X ", oid[i]); + } + + printf("%s: ", name); + return (0); +} + +/* * This formats and outputs the value of one variable * * Returns zero if anything was actually output. @@ -397,7 +428,7 @@ err(1, "sysctl name %d %d %d", i, j, errno); if (Nflag) { - printf("%s", name); + show_varname(name, oid, nlen); return (0); } @@ -430,14 +461,12 @@ p = val; switch (*fmt) { case 'A': - if (!nflag) - printf("%s: ", name); + show_varname(name, oid, nlen); printf("%s", p); return (0); case 'I': - if (!nflag) - printf("%s: ", name); + show_varname(name, oid, nlen); fmt++; val = ""; while (len >= sizeof(int)) { @@ -452,8 +481,7 @@ return (0); case 'L': - if (!nflag) - printf("%s: ", name); + show_varname(name, oid, nlen); fmt++; val = ""; while (len >= sizeof(long)) { @@ -468,8 +496,7 @@ return (0); case 'P': - if (!nflag) - printf("%s: ", name); + show_varname(name, oid, nlen); printf("%p", *(void **)p); return (0); @@ -487,16 +514,14 @@ else func = NULL; if (func) { - if (!nflag) - printf("%s: ", name); + show_varname(name, oid, nlen); return ((*func)(len, p)); } /* FALL THROUGH */ default: if (!oflag && !xflag) return (1); - if (!nflag) - printf("%s: ", name); + show_varname(name, oid, nlen); printf("Format:%s Length:%d Dump:0x", fmt, len); while (len-- && (xflag || p < val + 16)) printf("%02x", *p++); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 22 14:43:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (discworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 5AE5737B407 for ; Sun, 22 Jul 2001 14:43:24 -0700 (PDT) (envelope-from roam@ringworld.nanolink.com) Received: (qmail 3559 invoked by uid 1000); 22 Jul 2001 21:42:38 -0000 Date: Mon, 23 Jul 2001 00:42:38 +0300 From: Peter Pentchev To: arch@FreeBSD.org Cc: audit@FreeBSD.org Subject: Re: sysctl(8) enhancement: display sysctl MIB's Message-ID: <20010723004238.J882@ringworld.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org, audit@FreeBSD.org References: <20010723004034.I882@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010723004034.I882@ringworld.oblivion.bg>; from roam@orbitel.bg on Mon, Jul 23, 2001 at 12:40:34AM +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jul 23, 2001 at 12:40:34AM +0300, Peter Pentchev wrote: > Hi, > > During the testing of the kern_sysctl.c patches for PR xxxxx, Errrr oops. The PR is kern/29131 :) G'luck, Peter -- I had to translate this sentence into English because I could not read the original Sanskrit. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 22 23:31:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.39]) by hub.freebsd.org (Postfix) with SMTP id 29A6137B408 for ; Sun, 22 Jul 2001 23:31:32 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 1857 invoked by uid 1000); 23 Jul 2001 06:30:41 -0000 Date: Mon, 23 Jul 2001 09:30:41 +0300 From: Peter Pentchev To: arch@FreeBSD.org Cc: audit@FreeBSD.org Subject: Re: kern/29131: Current hungs in sysctl -a while booting + patch Message-ID: <20010723093041.A1201@ringworld.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org, audit@FreeBSD.org References: <200107220334.f6M3YRe01219@kan.dnsalias.net> <20010722110626.A819@ringworld.oblivion.bg> <20010722034233.B49508@sneakerz.org> <20010722235934.G882@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010722235934.G882@ringworld.oblivion.bg>; from roam@orbitel.bg on Sun, Jul 22, 2001 at 11:59:34PM +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jul 22, 2001 at 11:59:34PM +0300, Peter Pentchev wrote: > On Sun, Jul 22, 2001 at 03:42:33AM -0500, Alfred Perlstein wrote: > > * Peter Pentchev [010722 03:02] wrote: > > > Hi, > > > > > > Can anyone envision any side effects from committing the patch > > > in this PR? Seems like a trivial fix for a typo to me.. > > > > Shouldn't "magic" constants be put into the sysctl.h header? > > Good call! > > Attached are two patches: one to make sys/kern/kern_sysctl.c a bit > more style(9)-compliant (what made me do it was the failed search > for /^sysctl_register_oid/ when I saw it referenced), and one to put > a magic constant into sysctl.h and make kern_sysctl.c use it and > complain (albeit a bit harshly ;) about misbehaving static sysctl's. Here are the patches again (for -audit review). The second patch was modified after a suggestion from Dima - the comment about OID_AUTO in kern_sysctl.c was improved a bit. G'luck, Peter -- This would easier understand fewer had omitted. --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kern_sysctl.c-style.patch" Index: src/sys/kern/kern_sysctl.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_sysctl.c,v retrieving revision 1.110 diff -u -r1.110 kern_sysctl.c --- src/sys/kern/kern_sysctl.c 2001/06/22 19:54:38 1.110 +++ src/sys/kern/kern_sysctl.c 2001/07/22 20:38:15 @@ -87,7 +87,8 @@ * Order by number in each list. */ -void sysctl_register_oid(struct sysctl_oid *oidp) +void +sysctl_register_oid(struct sysctl_oid *oidp) { struct sysctl_oid_list *parent = oidp->oid_parent; struct sysctl_oid *p; @@ -135,7 +136,8 @@ SLIST_INSERT_HEAD(parent, oidp, oid_link); } -void sysctl_unregister_oid(struct sysctl_oid *oidp) +void +sysctl_unregister_oid(struct sysctl_oid *oidp) { SLIST_REMOVE(oidp->oid_parent, oidp, sysctl_oid, oid_link); } @@ -371,7 +373,8 @@ */ SET_DECLARE(sysctl_set, struct sysctl_oid); -static void sysctl_register_all(void *arg) +static void +sysctl_register_all(void *arg) { struct sysctl_oid **oidp; @@ -1084,7 +1087,8 @@ * must be in kernel space. */ int -userland_sysctl(struct proc *p, int *name, u_int namelen, void *old, size_t *oldlenp, int inkernel, void *new, size_t newlen, size_t *retval) +userland_sysctl(struct proc *p, int *name, u_int namelen, void *old, + size_t *oldlenp, int inkernel, void *new, size_t newlen, size_t *retval) { int error = 0; struct sysctl_req req, req2; --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sysctl-auto-start.patch" Index: src/sys/kern/kern_sysctl.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_sysctl.c,v retrieving revision 1.110 diff -u -r1.110 kern_sysctl.c --- src/sys/kern/kern_sysctl.c 2001/06/22 19:54:38 1.110 +++ src/sys/kern/kern_sysctl.c 2001/07/23 06:26:42 @@ -109,15 +109,19 @@ } /* * If this oid has a number OID_AUTO, give it a number which - * is greater than any current oid. Make sure it is at least - * 100 to leave space for pre-assigned oid numbers. + * is greater than any current oid. + * NOTE: DO NOT change the starting value here, change it in + * , and make sure it is at least 256 to + * accomodate e.g. net.inet.raw as a static sysctl node. */ if (oidp->oid_number == OID_AUTO) { - static int newoid = 100; + static int newoid = CTL_AUTO_START; oidp->oid_number = newoid++; if (newoid == 0x7fffffff) panic("out of oids"); + } else if (oidp->oid_number >= CTL_AUTO_START) { + panic("static sysctl oid too high: %d", oidp->oid_number); } /* Index: src/sys/sys/sysctl.h =================================================================== RCS file: /home/ncvs/src/sys/sys/sysctl.h,v retrieving revision 1.97 diff -u -r1.97 sysctl.h --- src/sys/sys/sysctl.h 2001/06/22 06:35:19 1.97 +++ src/sys/sys/sysctl.h 2001/07/23 06:26:42 @@ -95,6 +95,12 @@ */ #define OID_AUTO (-1) +/* + * The starting number for dynamically-assigned entries. WARNING! + * ALL static sysctl entries should have numbers LESS than this! + */ +#define CTL_AUTO_START 0x100 + #ifdef _KERNEL #define SYSCTL_HANDLER_ARGS struct sysctl_oid *oidp, void *arg1, int arg2, \ struct sysctl_req *req --PEIAKu/WMn1b1Hv9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 23 4: 7:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.39]) by hub.freebsd.org (Postfix) with SMTP id AB01137B405 for ; Mon, 23 Jul 2001 04:07:06 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 52907 invoked by uid 1000); 23 Jul 2001 11:06:20 -0000 Date: Mon, 23 Jul 2001 14:06:20 +0300 From: Peter Pentchev To: arch@FreeBSD.org Cc: audit@FreeBSD.org Subject: Re: sysctl(8) enhancement: display sysctl MIB's Message-ID: <20010723140620.A52175@ringworld.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org, audit@FreeBSD.org References: <20010723004034.I882@ringworld.oblivion.bg> <20010723104201.855893E2F@bazooka.unixfreak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010723104201.855893E2F@bazooka.unixfreak.org>; from dima@unixfreak.org on Mon, Jul 23, 2001 at 03:42:01AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jul 23, 2001 at 03:42:01AM -0700, Dima Dorfman wrote: [snip] > > I don't think checking printf()'s return value does anything other > than add more lines to the program. Most (none?) of the other > programs don't do it. Besides, what can you do when it fails? > Remember, err(3) calls it too... (well, it calls fprintf to write to > stderr, but you get the idea) [snip] > > If you're going to make show_varname() return something to indicate an > error (your code doesn't do that right now, but the return type is > 'int', and the comment says that it might fail in the future), you > should check the return value when you call it. Actually, I think > making the return type 'void' makes more sense: this is a support > routine (as opposed to an interface to something), and if it detects > an error, calling one of the err(3) functions would be cleaner than > doing error checking all over the place. > > > Other than that, I think it's a good idea. OK, a revised patch follows.. G'luck, Peter -- If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. Index: src/sbin/sysctl/sysctl.8 =================================================================== RCS file: /home/ncvs/src/sbin/sysctl/sysctl.8,v retrieving revision 1.36 diff -u -r1.36 sysctl.8 --- src/sbin/sysctl/sysctl.8 2001/07/13 09:09:48 1.36 +++ src/sbin/sysctl/sysctl.8 2001/07/23 11:05:00 @@ -40,7 +40,7 @@ .Nd get or set kernel state .Sh SYNOPSIS .Nm -.Op Fl bNnox +.Op Fl bmNnox .Ar name Ns Op = Ns Ar value .Ar ... .Nm @@ -71,6 +71,11 @@ Force the value of the variable(s) to be output in raw, binary format. No names are printed and no terminating newlines are output. This is mostly useful with a single variable. +.It Fl m +Specify that the MIB numerical value should be printed before the name. +This flag only takes effect if +.Fl n +is not specified. .It Fl N Show only variable names, not their values. This is particularly useful with shells that offer programmable Index: src/sbin/sysctl/sysctl.c =================================================================== RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v retrieving revision 1.37 diff -u -r1.37 sysctl.c --- src/sbin/sysctl/sysctl.c 2001/06/18 21:06:24 1.37 +++ src/sbin/sysctl/sysctl.c 2001/07/23 11:05:00 @@ -58,10 +58,11 @@ #include #include -static int aflag, bflag, Nflag, nflag, oflag, xflag; +static int aflag, bflag, mflag, Nflag, nflag, oflag, xflag; static int oidfmt(int *, int, char *, u_int *); static void parse(char *); +static void show_varname(const char *, const int *, int); static int show_var(int *, int); static int sysctl_all (int *oid, int len); static int name2oid(char *, int *); @@ -71,8 +72,8 @@ { (void)fprintf(stderr, "%s\n%s\n", - "usage: sysctl [-bNnox] variable[=value] ...", - " sysctl [-bNnox] -a"); + "usage: sysctl [-bmNnox] variable[=value] ...", + " sysctl [-bmNnox] -a"); exit(1); } @@ -83,7 +84,7 @@ setbuf(stdout,0); setbuf(stderr,0); - while ((ch = getopt(argc, argv, "AabNnowxX")) != -1) { + while ((ch = getopt(argc, argv, "AabmNnowxX")) != -1) { switch (ch) { case 'A': /* compatibility */ @@ -95,6 +96,9 @@ case 'b': bflag = 1; break; + case 'm': + mflag = 1; + break; case 'N': Nflag = 1; break; @@ -369,6 +373,30 @@ } /* + * This formats and outputs the name of one variable. + * If the -m command-line flag was specified, the MIB value + * is also printed out. + */ + +static void +show_varname(const char *name, const int *oid, int len) +{ + int i; + + if (nflag) + return; + + if (mflag) { + for (i = 0; i < len-1; i++) + printf("%X.", oid[i]); + printf("%X ", oid[i]); + } + + printf("%s: ", name); + return; +} + +/* * This formats and outputs the value of one variable * * Returns zero if anything was actually output. @@ -397,7 +425,7 @@ err(1, "sysctl name %d %d %d", i, j, errno); if (Nflag) { - printf("%s", name); + show_varname(name, oid, nlen); return (0); } @@ -430,14 +458,12 @@ p = val; switch (*fmt) { case 'A': - if (!nflag) - printf("%s: ", name); + show_varname(name, oid, nlen); printf("%s", p); return (0); case 'I': - if (!nflag) - printf("%s: ", name); + show_varname(name, oid, nlen); fmt++; val = ""; while (len >= sizeof(int)) { @@ -452,8 +478,7 @@ return (0); case 'L': - if (!nflag) - printf("%s: ", name); + show_varname(name, oid, nlen); fmt++; val = ""; while (len >= sizeof(long)) { @@ -468,8 +493,7 @@ return (0); case 'P': - if (!nflag) - printf("%s: ", name); + show_varname(name, oid, nlen); printf("%p", *(void **)p); return (0); @@ -487,16 +511,14 @@ else func = NULL; if (func) { - if (!nflag) - printf("%s: ", name); + show_varname(name, oid, nlen); return ((*func)(len, p)); } /* FALL THROUGH */ default: if (!oflag && !xflag) return (1); - if (!nflag) - printf("%s: ", name); + show_varname(name, oid, nlen); printf("Format:%s Length:%d Dump:0x", fmt, len); while (len-- && (xflag || p < val + 16)) printf("%02x", *p++); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 23 15:21:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 9036437B403; Mon, 23 Jul 2001 15:21:29 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f6NMLJF53050; Mon, 23 Jul 2001 16:21:19 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f6NMLIo93090; Mon, 23 Jul 2001 16:21:18 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200107232221.f6NMLIo93090@harmony.village.org> To: Assar Westerlund Subject: Re: Importing lukemftpd Cc: Mike Heffner , obrien@FreeBSD.ORG, arch@FreeBSD.ORG, dan@FreeBSD.ORG In-reply-to: Your message of "22 Jul 2001 23:08:13 +0200." <5lwv50isea.fsf@assaris.sics.se> References: <5lwv50isea.fsf@assaris.sics.se> Date: Mon, 23 Jul 2001 16:21:18 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <5lwv50isea.fsf@assaris.sics.se> Assar Westerlund writes: : Mike Heffner writes: : > Right now I just have two diffs in there, the first is a : > 's/GLOB_LIMIT/GLOB_MAXPATH' which prevents it from segfaulting when doing any : > globbing : : I believe the plan is actually to do the rename in glob(3) to be : compatible with the other *BSDs. At least nobody objected when I : proposed that. Yes. I thought you'd done that already... :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 12:24:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id E7B4137B409; Tue, 24 Jul 2001 12:24:31 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f6OJOSs111282; Tue, 24 Jul 2001 15:24:28 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200107231707.f6NH7wU18016@earth.backplane.com> References: <000f01c11315$094851e0$420d640a@HELL> <200107230354.f6N3stj13517@earth.backplane.com> <200107231538.f6NFcZl81468@khavrinen.lcs.mit.edu> <200107231557.f6NFvQb17025@earth.backplane.com> <200107231649.f6NGnq982448@khavrinen.lcs.mit.edu> <200107231707.f6NH7wU18016@earth.backplane.com> Date: Tue, 24 Jul 2001 15:24:23 -0400 To: Matt Dillon , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Changes to utmp, wtmp & lastlog entries Cc: Garrett Wollman , brian@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a spin-off of the thread in -security about: bin/22595: telnetd tricked into using arbitrary peer ip I figured we might as well bring it up in -arch at this point. The question is what (if any) changes should we make to the way entries are made to utmp, wtmp, and lastlog. If you look at that PR, there are some security implications wrt how those entries are currently handled, and thus it would be a good idea to do something about them. I'm quoting some of the recent background here, but you'd want to check that PR (and all the followup entries to it) for full details: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=22595 At 10:07 AM -0700 7/23/01, Matt Dillon wrote: >Garrett Wollman wrote: >:<:> Garrett Wollman wrote: >:> : SVR4 has an API. This API is standardized as a part of >:> : the Austin Group process. >: >:> Fine.. then if you want to get all the third party program >:> authors to use a magic API, be my guest. >: >: If they run on Solaris -- which most of them do -- then they already >: do. Nice try, Matt, but far off the mark. >: >:-GAWollman > > Really.. Lets see. wu-ftpd... nope. proftpd... nope. Want me > to continue? Still... If there *is* an API which would be common to both Solaris and FreeBSD, then it should be much easier to get third-party program authors to accept changes to use that API. As for the best change to make, let me suggest that we basically follow both Matt's and Garrett's recommendations (which were made in other messages in the thread). Let's increase the size of UT_HOSTSIZE to at least 56, so the field can always hold the complete IP address (even for IPv6) in the field, but let's encourage programs to use whatever the standardized API is to make these entries. There will be a bit of a transition-hit when the size of the field is changed, where anything that usees or sets these records will need to be recompiled. Maybe we should do this change as part of 5.0, and not MFC it. If you read all the entries in the PR, Brian noted that OpenBSD has already changed UT_HOSTSIZE to be 256. I might go for something larger than 56 (such as 64, just to be a computer geek who always picks powers of 2...), but I don't think freebsd needs to go all the way to 256. I don't feel too strongly about the actual solution decided upon, but I did think it was about time to have this topic explicitly mentioned in freebsd-arch, so we can figure out what is best to do and then do whatever that is. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 13: 4:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-169-104-149.dsl.lsan03.pacbell.net [64.169.104.149]) by hub.freebsd.org (Postfix) with ESMTP id 47FF737B407; Tue, 24 Jul 2001 13:04:20 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 4053566E04; Tue, 24 Jul 2001 13:04:19 -0700 (PDT) Date: Tue, 24 Jul 2001 13:04:18 -0700 From: Kris Kennaway To: "David E. O'Brien" Cc: arch@FreeBSD.org Subject: Nuking all malloc wrappers (Re: cvs commit: src/usr.bin/nm nm.c) Message-ID: <20010724130418.A34051@xor.obsecurity.org> References: <200107241408.f6OE83j65583@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107241408.f6OE83j65583@freefall.freebsd.org>; from obrien@FreeBSD.org on Tue, Jul 24, 2001 at 07:08:03AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I don't understand why you're doing this. Increasing code duplication by expanding out a local function seems like a pessimization to me. Many programs wrap functions that malloc, and it's the correct thing to do to increase code readability as well as making it more likely that all instances get checked for the malloc return value. It's a very big step to go from "emalloc() shouldn't exist in libutil" to "no piece of code in FreeBSD should use a private wrapper function around malloc() to simplify the process of checking the return value". Could you please explain your reasoning? Kris On Tue, Jul 24, 2001 at 07:08:03AM -0700, David E. O'Brien wrote: > obrien 2001/07/24 07:08:03 PDT >=20 > Modified files: > usr.bin/nm nm.c=20 > Log: > Expland the emalloc to do the testing at the place of mallocing. > =20 > Revision Changes Path > 1.16 +7 -17 src/usr.bin/nm/nm.c > http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/nm/nm.c.diff?r1=3D1.15= &r2=3D1.16 --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7XdTCWry0BWjoQKURAo3LAJ4/hgWSdSPLG/FJvDWvY+KoANS8bQCgkAG2 GnjFBvQVcKDDJ+emdwgmNdI= =pqFa -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 13:17:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id C3E3437B436; Tue, 24 Jul 2001 13:17:22 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id WAA02163; Tue, 24 Jul 2001 22:17:10 +0200 (CEST) (envelope-from assar) To: Warner Losh Cc: Mike Heffner , obrien@FreeBSD.ORG, arch@FreeBSD.ORG, dan@FreeBSD.ORG Subject: Re: Importing lukemftpd References: <5lwv50isea.fsf@assaris.sics.se> <200107232221.f6NMLIo93090@harmony.village.org> From: Assar Westerlund Date: 24 Jul 2001 22:17:09 +0200 In-Reply-To: Warner Losh's message of "Mon, 23 Jul 2001 16:21:18 -0600" Message-ID: <5lbsmaccai.fsf@assaris.sics.se> Lines: 17 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --=-=-= Warner Losh writes: > : I believe the plan is actually to do the rename in glob(3) to be > : compatible with the other *BSDs. At least nobody objected when I > : proposed that. > > Yes. I thought you'd done that already... :-) Actually not. I wasn't sure how much backwards compatability we wanted, if we want to change RELENG_4 too (which I would prefer). Since we cannot have full backwards compatability, I propose applying this patch, keeping the old flag name for glob but not preserving the return code (since I cannot see any code actually using it). Comments? /assar --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=freebsd-glob.diff Index: include/glob.h =================================================================== RCS file: /home/ncvs/src/include/glob.h,v retrieving revision 1.4 diff -u -w -r1.4 glob.h --- include/glob.h 2001/03/19 19:10:06 1.4 +++ include/glob.h 2001/07/24 20:07:13 @@ -77,11 +77,14 @@ #define GLOB_NOMAGIC 0x0200 /* GLOB_NOCHECK without magic chars (csh). */ #define GLOB_QUOTE 0x0400 /* Quote special chars with \. */ #define GLOB_TILDE 0x0800 /* Expand tilde names from the passwd file. */ -#define GLOB_MAXPATH 0x1000 /* limit number of returned paths */ +#define GLOB_LIMIT 0x1000 /* limit number of returned paths */ +/* backwards compatibility, this is the old name for this option */ +#define GLOB_MAXPATH GLOB_LIMIT + #define GLOB_NOSPACE (-1) /* Malloc call failed. */ #define GLOB_ABEND (-2) /* Unignored error. */ -#define GLOB_LIMIT (-3) /* Path limit was hit. */ +#define GLOB_LIMITHIT (-3) /* Path limit was hit. */ __BEGIN_DECLS int glob __P((const char *, int, int (*)(const char *, int), glob_t *)); Index: lib/libc/gen/glob.3 =================================================================== RCS file: /home/ncvs/src/lib/libc/gen/glob.3,v retrieving revision 1.15 diff -u -w -r1.15 glob.3 --- lib/libc/gen/glob.3 2001/03/19 19:10:06 1.15 +++ lib/libc/gen/glob.3 2001/07/24 20:07:14 @@ -260,13 +260,14 @@ Expand patterns that start with .Ql ~ to user name home directories. -.It Dv GLOB_MAXPATH +.It Dv GLOB_LIMIT Limit the total number of returned pathnames to the value provided in -.Fa gl_matchc . +.Fa gl_matchc +(default ARG_MAX). If .Fn glob would match more pathnames, -.Dv GLOB_LIMIT +.Dv GLOB_LIMITHIT will be returned. .El .Pp @@ -384,9 +385,9 @@ was set or .Fa \*(lp*errfunc\*(rp\*(lp\*(rp returned non-zero. -.It Dv GLOB_LIMIT +.It Dv GLOB_LIMITHIT The flag -.Dv GLOB_MAXPATH +.Dv GLOB_LIMIT was provided, and the specified limit passed to .Fn glob in Index: lib/libc/gen/glob.c =================================================================== RCS file: /home/ncvs/src/lib/libc/gen/glob.c,v retrieving revision 1.17 diff -u -w -r1.17 glob.c --- lib/libc/gen/glob.c 2001/03/28 23:55:51 1.17 +++ lib/libc/gen/glob.c 2001/07/24 20:07:14 @@ -170,9 +170,11 @@ if (!(flags & GLOB_DOOFFS)) pglob->gl_offs = 0; } - if (flags & GLOB_MAXPATH) + if (flags & GLOB_LIMIT) { limit = pglob->gl_matchc; - else + if (limit == 0) + limit = ARG_MAX; + } else limit = 0; pglob->gl_flags = flags & ~GLOB_MAGCHAR; pglob->gl_errfunc = errfunc; @@ -688,7 +690,7 @@ const Char *p; if (*limit && pglob->gl_pathc > *limit) - return (GLOB_LIMIT); + return (GLOB_LIMITHIT); newsize = sizeof(*pathv) * (2 + pglob->gl_pathc + pglob->gl_offs); pathv = pglob->gl_pathv ? Index: libexec/ftpd/ftpd.c =================================================================== RCS file: /home/ncvs/src/libexec/ftpd/ftpd.c,v retrieving revision 1.77 diff -u -w -r1.77 ftpd.c --- libexec/ftpd/ftpd.c 2001/06/13 00:06:42 1.77 +++ libexec/ftpd/ftpd.c 2001/07/24 20:07:17 @@ -2670,7 +2670,7 @@ memset(&gl, 0, sizeof(gl)); gl.gl_matchc = MAXGLOBARGS; - flags |= GLOB_MAXPATH; + flags |= GLOB_LIMIT; freeglob = 1; if (glob(whichf, flags, 0, &gl)) { reply(550, "not found"); Index: libexec/ftpd/popen.c =================================================================== RCS file: /home/ncvs/src/libexec/ftpd/popen.c,v retrieving revision 1.20 diff -u -w -r1.20 popen.c --- libexec/ftpd/popen.c 2001/03/19 19:11:00 1.20 +++ libexec/ftpd/popen.c 2001/07/24 20:07:17 @@ -108,7 +108,7 @@ memset(&gl, 0, sizeof(gl)); gl.gl_matchc = MAXGLOBARGS; - flags |= GLOB_MAXPATH; + flags |= GLOB_LIMIT; if (glob(argv[argc], flags, NULL, &gl)) gargv[gargc++] = strdup(argv[argc]); else --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 15:58:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 6C3E737B409; Tue, 24 Jul 2001 15:58:44 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6OMwfM08170; Tue, 24 Jul 2001 23:58:41 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6OMweg52573; Tue, 24 Jul 2001 23:58:40 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200107242258.f6OMweg52573@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Garance A Drosihn Cc: Matt Dillon , arch@FreeBSD.ORG, Garrett Wollman , brian@FreeBSD.ORG Subject: Re: Changes to utmp, wtmp & lastlog entries In-Reply-To: Message from Garance A Drosihn of "Tue, 24 Jul 2001 15:24:23 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Jul 2001 23:58:40 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > This is a spin-off of the thread in -security about: > bin/22595: telnetd tricked into using arbitrary peer ip [.....] > Still... If there *is* an API which would be common to both Solaris > and FreeBSD, then it should be much easier to get third-party program > authors to accept changes to use that API. > > As for the best change to make, let me suggest that we basically > follow both Matt's and Garrett's recommendations (which were made > in other messages in the thread). [.....] I'm happy to bump UT_HOSTSIZE to 56 and plan to do so in 5 days if that's the concensus (and if nobody has done so already). Garrett, would you mind looking at importing the Austin API for this ? -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 16: 7:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 5E62537B403 for ; Tue, 24 Jul 2001 16:07:14 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f6ON6xi06524; Tue, 24 Jul 2001 19:06:59 -0400 (EDT) (envelope-from wollman) Date: Tue, 24 Jul 2001 19:06:59 -0400 (EDT) From: Garrett Wollman Message-Id: <200107242306.f6ON6xi06524@khavrinen.lcs.mit.edu> To: Brian Somers Cc: arch@FreeBSD.ORG Subject: Re: Changes to utmp, wtmp & lastlog entries In-Reply-To: <200107242258.f6OMweg52573@hak.lan.Awfulhak.org> References: <200107242258.f6OMweg52573@hak.lan.Awfulhak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG < said: > Garrett, would you mind looking at importing the Austin API for this ? There is no ``importing'' to be done. Someone has to actually sit down and write the code. I have absolutely zero cycles free to do this myself, but I'd be happy to provide the relevant information -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 16: 7:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 7BF2F37B434 for ; Tue, 24 Jul 2001 16:07:18 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f6ON7IM48642 for ; Tue, 24 Jul 2001 16:07:18 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 4CBC9380B; Tue, 24 Jul 2001 16:07:18 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: moving struct module out of kern_module.c In-Reply-To: Date: Tue, 24 Jul 2001 16:07:18 -0700 From: Peter Wemm Message-Id: <20010724230718.4CBC9380B@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > Currently, struct module is defined in kern_module.c and opaque to the > rest of the kernel. I'd like to move the definition out into module.h > so linprocfs can access it. Any objections? It is intentionally opaque, just like the device stuff. If there is an interface deficiency then that is what needs addressing, not groping around private infrastructure internals. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 16:18:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 77E6737B405 for ; Tue, 24 Jul 2001 16:18:51 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6ONInM08414; Wed, 25 Jul 2001 00:18:49 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6ONImg53101; Wed, 25 Jul 2001 00:18:48 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200107242318.f6ONImg53101@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Garrett Wollman Cc: Brian Somers , arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Changes to utmp, wtmp & lastlog entries In-Reply-To: Message from Garrett Wollman of "Tue, 24 Jul 2001 19:06:59 EDT." <200107242306.f6ON6xi06524@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Jul 2001 00:18:48 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > < said: > > > Garrett, would you mind looking at importing the Austin API for this ? > > There is no ``importing'' to be done. Someone has to actually sit > down and write the code. I have absolutely zero cycles free to do > this myself, but I'd be happy to provide the relevant information I haven't that much time, but I could take a look at any info you've got :*) > -GAWollman Cheers. -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 16:36:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id AD92737B403; Tue, 24 Jul 2001 16:36:12 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f6ONa9o38143; Tue, 24 Jul 2001 16:36:09 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Jul 2001 16:36:09 -0700 (PDT) From: Matt Dillon Message-Id: <200107242336.f6ONa9o38143@earth.backplane.com> To: Brian Somers Cc: Garance A Drosihn , arch@FreeBSD.ORG, Garrett Wollman , brian@FreeBSD.ORG Subject: Re: Changes to utmp, wtmp & lastlog entries References: <200107242258.f6OMweg52573@hak.lan.Awfulhak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> This is a spin-off of the thread in -security about: :> bin/22595: telnetd tricked into using arbitrary peer ip :[.....] :> Still... If there *is* an API which would be common to both Solaris :> and FreeBSD, then it should be much easier to get third-party program :> authors to accept changes to use that API. :> :> As for the best change to make, let me suggest that we basically :> follow both Matt's and Garrett's recommendations (which were made :> in other messages in the thread). :[.....] : :I'm happy to bump UT_HOSTSIZE to 56 and plan to do so in 5 days if :that's the concensus (and if nobody has done so already). : :Garrett, would you mind looking at importing the Austin API for this ? :-- :Brian : http://www.freebsd-services.com/ : It would be great if you could quarterback this one, Brian, thanks! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 17:58:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from iatl0x01.coxmail.com (iatl0x02.coxmail.com [206.157.225.11]) by hub.freebsd.org (Postfix) with ESMTP id D7FD937B406; Tue, 24 Jul 2001 17:58:06 -0700 (PDT) (envelope-from mheffner@novacoxmail.com) Received: from enterprise.muriel.penguinpowered.com ([209.249.161.66]) by iatl0x01.coxmail.com (InterMail vK.4.03.02.00 201-232-124 license eaa2928f5bcba31507d4d280f1027278) with ESMTP id <20010725005804.IBOD10268.iatl0x01@enterprise.muriel.penguinpowered.com>; Tue, 24 Jul 2001 20:58:04 -0400 Message-ID: X-Mailer: XFMail 1.5.0 on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.5.0.FreeBSD:20010724205538:2583=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <5lbsmaccai.fsf@assaris.sics.se> Date: Tue, 24 Jul 2001 20:55:38 -0400 (EDT) Reply-To: Mike Heffner From: Mike Heffner To: Assar Westerlund Subject: Re: Importing lukemftpd Cc: arch@FreeBSD.ORG, Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.5.0.FreeBSD:20010724205538:2583=_ Content-Type: text/plain; charset=us-ascii [cc's trimmed] On 24-Jul-2001 Assar Westerlund wrote: | Warner Losh writes: |> : I believe the plan is actually to do the rename in glob(3) to be |> : compatible with the other *BSDs. At least nobody objected when I |> : proposed that. |> |> Yes. I thought you'd done that already... :-) | | Actually not. I wasn't sure how much backwards compatability we | wanted, if we want to change RELENG_4 too (which I would prefer). | Since we cannot have full backwards compatability, I propose applying | this patch, keeping the old flag name for glob but not preserving the | return code (since I cannot see any code actually using it). Comments? Why not just do away with the LIMITHIT return code and just use GLOB_NOSPACE like NetBSD and OpenBSD does? Mike -- Mike Heffner Fredericksburg, VA --_=XFMail.1.5.0.FreeBSD:20010724205538:2583=_ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7XhkKFokZQs3sv5kRAlyjAJ44UZ7cxjkV9c0+IYPhAIPs54podACeOZC9 S8eESXJ1B46+2j7i6WLhbCM= =0OZ7 -----END PGP SIGNATURE----- --_=XFMail.1.5.0.FreeBSD:20010724205538:2583=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 18: 7:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from assaris.sics.se (h122n4fls32o892.telia.com [213.64.47.122]) by hub.freebsd.org (Postfix) with ESMTP id CBE0037B403 for ; Tue, 24 Jul 2001 18:07:39 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id DAA26673; Wed, 25 Jul 2001 03:07:28 +0200 (CEST) (envelope-from assar) To: Mike Heffner Cc: arch@FreeBSD.ORG, Warner Losh Subject: Re: Importing lukemftpd References: From: Assar Westerlund Date: 25 Jul 2001 03:07:27 +0200 In-Reply-To: Mike Heffner's message of "Tue, 24 Jul 2001 20:55:38 -0400 (EDT)" Message-ID: <5litghyfxs.fsf@assaris.sics.se> Lines: 13 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Heffner writes: > Why not just do away with the LIMITHIT return code and just use GLOB_NOSPACE > like NetBSD and OpenBSD does? because: 1. It's a different error condition and thus I thought it merited (still having) a different error code. 2. It wasn't as bad for portability. Error codes aren't quite portabel among the *BSDs as it is currently, but perhaps we should work on that. /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 20:43:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from iatl0x01.coxmail.com (iatl0x02.coxmail.com [206.157.225.11]) by hub.freebsd.org (Postfix) with ESMTP id AF37F37B403; Tue, 24 Jul 2001 20:43:25 -0700 (PDT) (envelope-from mheffner@novacoxmail.com) Received: from enterprise.muriel.penguinpowered.com ([209.249.161.66]) by iatl0x01.coxmail.com (InterMail vK.4.03.02.00 201-232-124 license eaa2928f5bcba31507d4d280f1027278) with ESMTP id <20010725034325.GVY18366.iatl0x01@enterprise.muriel.penguinpowered.com>; Tue, 24 Jul 2001 23:43:25 -0400 Message-ID: X-Mailer: XFMail 1.5.0 on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.5.0.FreeBSD:20010724234100:2934=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <5litghyfxs.fsf@assaris.sics.se> Date: Tue, 24 Jul 2001 23:41:00 -0400 (EDT) Reply-To: Mike Heffner From: Mike Heffner To: Assar Westerlund Subject: Making glob(3) portable (was Re: Importing lukemftpd) Cc: Warner Losh , arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.5.0.FreeBSD:20010724234100:2934=_ Content-Type: text/plain; charset=us-ascii On 25-Jul-2001 Assar Westerlund wrote: | Mike Heffner writes: |> Why not just do away with the LIMITHIT return code and just use GLOB_NOSPACE |> like NetBSD and OpenBSD does? | | because: | | 1. It's a different error condition and thus I thought it merited | (still having) a different error code. | 2. It wasn't as bad for portability. Error codes aren't quite In what way is it not as bad? I agree that we don't have all the error values that NetBSD and OpenBSD have, but using a different one for this scenario than what the other *BSDs use is not very portable either. | portabel among the *BSDs as it is currently, but perhaps we should | work on that. IMO, removing GLOB_LIMITHIT, or whatever, and just using GLOB_NOSPACE with errno=0 would be the first step in the direction of portability. | | /assar Mike -- Mike Heffner Fredericksburg, VA --_=XFMail.1.5.0.FreeBSD:20010724234100:2934=_ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7Xj/LFokZQs3sv5kRAuQcAJ9w9KHYuc48aoTPC5sINfmOpZmTlwCfWdbE yWA3lGejy4qcotJ0dZgnkWc= =+D/t -----END PGP SIGNATURE----- --_=XFMail.1.5.0.FreeBSD:20010724234100:2934=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 20:43:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from iatl0x01.coxmail.com (iatl0x02.coxmail.com [206.157.225.11]) by hub.freebsd.org (Postfix) with ESMTP id 3D7FD37B403; Tue, 24 Jul 2001 20:43:55 -0700 (PDT) (envelope-from mheffner@novacoxmail.com) Received: from enterprise.muriel.penguinpowered.com ([209.249.161.66]) by iatl0x01.coxmail.com (InterMail vK.4.03.02.00 201-232-124 license eaa2928f5bcba31507d4d280f1027278) with ESMTP id <20010725034354.GWQ18366.iatl0x01@enterprise.muriel.penguinpowered.com>; Tue, 24 Jul 2001 23:43:54 -0400 Message-ID: X-Mailer: XFMail 1.5.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <5litghyfxs.fsf@assaris.sics.se> Date: Tue, 24 Jul 2001 23:41:29 -0400 (EDT) Reply-To: Mike Heffner From: Mike Heffner To: Assar Westerlund Subject: Re: Importing lukemftpd Cc: Warner Losh , arch@FreeBSD.ORG, Mike Heffner Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 25-Jul-2001 Assar Westerlund wrote: | Mike Heffner writes: |> Why not just do away with the LIMITHIT return code and just use GLOB_NOSPACE |> like NetBSD and OpenBSD does? | | because: | | 1. It's a different error condition and thus I thought it merited | (still having) a different error code. | 2. It wasn't as bad for portability. Error codes aren't quite | portabel among the *BSDs as it is currently, but perhaps we should | work on that. | | /assar Mike -- Mike Heffner Fredericksburg, VA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 20:55:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [206.40.252.115]) by hub.freebsd.org (Postfix) with ESMTP id 0D72337B401 for ; Tue, 24 Jul 2001 20:55:49 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f6P3tDR07945; Tue, 24 Jul 2001 20:55:13 -0700 (PDT) (envelope-from obrien) Date: Tue, 24 Jul 2001 20:55:13 -0700 From: "David O'Brien" To: Mike Silbersack Cc: arch@freebsd.org, Bosko Milekic , Matt Dillon , "David O'Brien" Subject: Re: cvs commit: src/sys/netinet tcp_usrreq.c Message-ID: <20010724205513.H5825@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20010718121851.B26558@dragon.nuxi.com> <20010718214902.H6519-100000@achilles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010718214902.H6519-100000@achilles.silby.com>; from silby@silby.com on Wed, Jul 18, 2001 at 10:04:45PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jul 18, 2001 at 10:04:45PM -0500, Mike Silbersack wrote: > I think you're right in increasing the number of mbufs, but changing the > scaling factor is probably the wrong way to do it; it will cause people > with custom kernels to have many thousands more mbufs than they expect. > > In 4.x, the setting is currently at: > (512 + MAXUSERS * 16) > > current was > (1024 + MAXUSERS * 16) > > before your scaling change (to * 64). > > How about we instead change the constant amount, to perhaps: > (2048 + MAXUSERS * 16) I am open to this change, but would like see others comment also on this proposal. > (I'd like to do the scaling based on RAM size, > but I don't have time at the moment.) Agreed. I started on a set of diffs, but have not had time to finish them and test them. > Note that if we're increasing this, we should probably increase > maxfiles/sockets - that's probably more important now. Any one else with an opinion on this? -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 21:20:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 340CC37B405 for ; Tue, 24 Jul 2001 21:19:59 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 32546 invoked by uid 1000); 25 Jul 2001 04:19:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Jul 2001 04:19:57 -0000 Date: Tue, 24 Jul 2001 23:19:57 -0500 (CDT) From: Mike Silbersack To: , Subject: TCP sequence numbers: RFC1948 patch ready for testing Message-ID: <20010724230813.A31803-200000@achilles.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-155072002-996034797=:31803" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-155072002-996034797=:31803 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello all, the RFC1948-like sequence number generation patch is ready for testing. The patch included will apply cleanly to both a recent -current and a recent -stable. I've spent a good deal of time looking at tcpdump logs, and it looks good to me. Please test and review this if you feel comfortable doing so. If you do not feel comfortable doing so, please simply test it instead. :) When testing, please try both with net.inet.tcp.tcp_seq_genscheme set to 0 and 1. 0 Uses the RFC1948 scheme for generating all ISNs, 1 uses RFC1948 only for outgoing SYN; SYN-ACKs are filled with random values instead. I'd like to leave this selectable, with the default to 1. 1 is slightly faster, while 0 may feel more comfortable to some users. Both schemes should work equally well, so please test both. I've changed the RFC1948 algorithm slightly, by adding a random offset. Please look this over carefully when reviewing. Note that this patch is _functionally_ complete, but does not yet remove cruft from other generation schemes; I will do this in the final version of the patch. Enjoy! Mike "Silby" Silbersack --0-155072002-996034797=:31803 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="rfc1948seq.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20010724231957.R31803@achilles.silby.com> Content-Description: Content-Disposition: attachment; filename="rfc1948seq.patch" ZGlmZiAtdSAtciBuZXRpbmV0Lm9sZC90Y3BfaW5wdXQuYyBuZXRpbmV0L3Rj cF9pbnB1dC5jDQotLS0gbmV0aW5ldC5vbGQvdGNwX2lucHV0LmMJVGh1IEp1 bCAxOSAyMDo0NTowMSAyMDAxDQorKysgbmV0aW5ldC90Y3BfaW5wdXQuYwlG cmkgSnVsIDIwIDIyOjM4OjE4IDIwMDENCkBAIC0xMTM1LDcgKzExMzUsNyBA QA0KIAkJaWYgKGlzcykNCiAJCQl0cC0+aXNzID0gaXNzOw0KIAkJZWxzZSB7 DQotCQkJdHAtPmlzcyA9IHRjcF9uZXdfaXNuKCk7DQorCQkJdHAtPmlzcyA9 IHRjcF9uZXdfaXNuKHRwKTsNCiAgCQl9DQogCQl0cC0+aXJzID0gdGgtPnRo X3NlcTsNCiAJCXRjcF9zZW5kc2VxaW5pdCh0cCk7DQpAQCAtMTY2Nyw3ICsx NjY3LDcgQEANCiAJCQlpZiAodGhmbGFncyAmIFRIX1NZTiAmJg0KIAkJCSAg ICB0cC0+dF9zdGF0ZSA9PSBUQ1BTX1RJTUVfV0FJVCAmJg0KIAkJCSAgICBT RVFfR1QodGgtPnRoX3NlcSwgdHAtPnJjdl9ueHQpKSB7DQotCQkJCWlzcyA9 IHRjcF9uZXdfaXNuKCk7DQorCQkJCWlzcyA9IHRjcF9uZXdfaXNuKHRwKTsN CiAJCQkJdHAgPSB0Y3BfY2xvc2UodHApOw0KIAkJCQlnb3RvIGZpbmRwY2I7 DQogCQkJfQ0KZGlmZiAtdSAtciBuZXRpbmV0Lm9sZC90Y3Bfc3Vici5jIG5l dGluZXQvdGNwX3N1YnIuYw0KLS0tIG5ldGluZXQub2xkL3RjcF9zdWJyLmMJ VGh1IEp1bCAxOSAyMDo0NTowMSAyMDAxDQorKysgbmV0aW5ldC90Y3Bfc3Vi ci5jCU1vbiBKdWwgMjMgMjE6NTk6NTMgMjAwMQ0KQEAgLTk4LDYgKzk4LDcg QEANCiAjZW5kaWYgLypJUFNFQyovDQogDQogI2luY2x1ZGUgPG1hY2hpbmUv aW5fY2tzdW0uaD4NCisjaW5jbHVkZSA8c3lzL21kNS5oPg0KIA0KIGludCAJ dGNwX21zc2RmbHQgPSBUQ1BfTVNTOw0KIFNZU0NUTF9JTlQoX25ldF9pbmV0 X3RjcCwgVENQQ1RMX01TU0RGTFQsIG1zc2RmbHQsIENUTEZMQUdfUlcsIA0K QEAgLTExMTIsMjQgKzExMTMsOTIgQEANCiB9DQogI2VuZGlmIC8qIElORVQ2 ICovDQogDQorLyoNCisgKiBGb2xsb3dpbmcgaXMgd2hlcmUgVENQIGluaXRp YWwgc2VxdWVuY2UgbnVtYmVyIGdlbmVyYXRpb24gb2NjdXJzLg0KKyAqIEZv ciBJU05zIGluIFNZTi1BQ0sgcGFja2V0cywgd2UgdXNlIHRoZSBvdXRwdXQg ZnJvbSBhcmM0cmFuZG9tKCk7DQorICogdGhlcmUgaXMgbm8gbW9udG9uaWNp dHkgcmVxdWlyZW1lbnQgZm9yIElTTnMgaW4gU1lOLUFDSyBwYWNrZXRzLA0K KyAqIGFuZCB0aGV5IHNob3VsZCBiZSBhcyByYW5kb20gYXMgcG9zc2libGUg dG8gYXZvaWQgc3Bvb2ZpbmcgYXR0YWNrcy4NCisgKg0KKyAqIFdoZW4gd2Ug c2VuZCBJU05zIGluIG91dGdvaW5nIFNZTiBwYWNrZXRzLCB3ZSBtdXN0IGVu c3VyZSBtb25vdG9uaWNpdHkNCisgKiBzbyB0aGF0IFRJTUVfV0FJVCByZWN5 Y2xpbmcgd29ya3MgcHJvcGVybHkgb24gdGhlIGhvc3RzIHdlIGFyZQ0KKyAq IGNvbm5lY3RpbmcgdG8uICBUbyBtZWV0IHRoaXMgcmVxdWlyZW1lbnQgd2hp bGUgc3RpbGwgYmVpbmcNCisgKiB1bnByZWRpY3RhYmxlLCB3ZSB1c2UgYSBt b2RpZmllZCB2ZXJzaW9uIG9mIHRoZSBhbGdvcml0aG0gc3BlY2lmaWVkDQor ICogaW4gUkZDIDE5NDguDQorICoNCisgKiBUaGUgYWxnb3JpdGhtIGlzIGFz IGZvbGxvd3M6DQorICogSVNOID0gVGltZSArIGlzbl9vZmZzZXQgKyBtZDUo ZnBvcnQsIGxwb3J0LCBmYWRkciwgbGFkZHIsIHNlY3JldCkNCisgKiANCisg KiBUaW1lIGlzIGJhc2VkIG9mZiB0aGUgc3lzdGVtIHRpbWVyLCBhbmQgaXMg Y29ycmVjdGVkIHNvIHRoYXQgaXQNCisgKiBpbmNyZWFzZXMgYnkgb25lIG1l Z2FieXRlIHBlciBzZWNvbmQuICBUaGlzIGFsbG93cyBmb3IgcHJvcGVyDQor ICogcmVjeWNsaW5nIG9uIGhpZ2ggc3BlZWQgTEFOcyB3aGlsZSBzdGlsbCBs ZWF2aW5nIG92ZXIgYW4gaG91cg0KKyAqIGJlZm9yZSByb2xsb3Zlci4NCisg Kg0KKyAqIGlzbl9vZmZzZXQgaXMgYSByYW5kb20gdmFsdWUgY2hhbmdlZCB3 aGVuZXZlciBzZWNyZXQgaXMgY2hhbmdlZC4NCisgKiBUaGUgcHVycG9zZSBv ZiB0aGlzIHZhbHVlIGlzIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBleGFjdCBv dXRwdXQNCisgKiBvZiB0aGUgaGFzaCBmdW5jdGlvbiBjYW5ub3QgYmUgZGV0 ZXJtaW5lZC4gIElmIHRoaXMgd2FzIG5vdCBwcmVzZW50LA0KKyAqIGl0IHdv dWxkIGJlIGEgc2ltcGxlIG1hdHRlciB0byBzdWJ0cmFjdCB0aW1lIGZyb20g dGhlIElTTiBhbmQNCisgKiBsYXVuY2ggYSBicnV0ZS1mb3JjZSBhdHRhY2sg b24gdGhlIHNlY3JldCBvZiB0aGUgaGFzaC4gIFRoaXMNCisgKiBhdHRhY2sg c2hvdWxkIG5vdyBiZSBtdWNoIHRvdWdoZXIuICAoaXNuX29mZnNldCBpcyBu b3QgcGFydA0KKyAqIG9mIHRoZSBzcGVjIG91dGxpbmVkIGluIFJGQyAxOTQ4 LikNCisgKg0KKyAqIFRoZSBtZDUgaGFzaCBpcyB3aGF0IHNlcGVyYXRlcyB0 aGUgSVNOIHNwYWNlIG9mIGV2ZXJ5IGNvbm5lY3Rpb24uDQorICogQXMgbG9u ZyBhcyB0aGUgc2VjcmV0IHJlbWFpbnMgc2VjcmV0LCBpdCBzaG91bGQgYmUg dmlydHVhbGx5DQorICogaW1wb3NzaWJsZSBmb3IgYW55b25lIHRvIGd1ZXNz IHRoZSBzZXF1ZW5jZSBzcGFjZSBvZiBhbnkgb3RoZXINCisgKiBjb25uZWN0 aW9uLiAgVGhlIHNlY3JldCBpcyBjaGFuZ2VkIGhvdXJseSB0byBlbnN1cmUg dGhhdCANCisgKiBhIGJydXRlIGZvcmNlIGF0dGFjayBvbiB0aGUgc2VjcmV0 IHdpbGwgbm90IGJlIHBvc3NpYmxlIGluDQorICogdGhlIG5lYXIgZnV0dXJl Lg0KKyAqDQorICogRm9yIG1vcmUgaW5mb3JtYXRpb24gb24gdGhpcyBhbGdv cml0aG0sIHBsZWFzZSBzZWUgUkZDIDE5NDguDQorICovDQorDQorI2RlZmlu ZSBJU05fUkVTRUVEX0lOVFZMIDM2MDANCisjZGVmaW5lIElTTl9CWVRFU19Q RVJfU0VDT05EIDEwNDg1NzYNCisNCitpbnQgaXNuX3Jlc2VlZF90aW1lOw0K K3VfY2hhciBpc25fc2VjcmV0WzMyXTsNCit1X2ludDMyX3QgaXNuX29mZnNl dDsNCisNCiB0Y3Bfc2VxDQotdGNwX25ld19pc24oKQ0KK3RjcF9uZXdfaXNu KHRwKQ0KKwlzdHJ1Y3QgdGNwY2IgKnRwOw0KIHsNCi0JaWYgKCh0Y3Bfc2Vx X2dlbnNjaGVtZSA+IDEpIHx8ICh0Y3Bfc2VxX2dlbnNjaGVtZSA8IDApKQ0K LQkJdGNwX3NlcV9nZW5zY2hlbWUgPSAxOw0KLQ0KLQlzd2l0Y2ggKHRjcF9z ZXFfZ2Vuc2NoZW1lKSB7DQotCQljYXNlIDA6CS8qDQotCQkJICogUmFuZG9t IHBvc2l0aXZlIGluY3JlbWVudHMNCi0JCQkgKi8NCi0JCQl0Y3BfaXNzICs9 IFRDUF9JU1NJTkNSLzI7DQotCQkJcmV0dXJuIHRjcF9pc3M7DQotCQljYXNl IDE6CS8qDQotCQkJICogT3BlbUJTRCByYW5kb21pemVkIHNjaGVtZQ0KLQkJ CSAqLw0KLQkJCXJldHVybiB0Y3Bfcm5kaXNzX25leHQoKTsNCitNRDVfQ1RY IGN0eDsNCit1X2ludDMyX3QgbWQ1X2J1ZmZlcls0XTsNCit0Y3Bfc2VxIG5l d19pc247DQorDQorCWlmIChpc25fcmVzZWVkX3RpbWUgPCB0aWNrcykgew0K KwkJLyogUmVzZWVkIHRoZSBzZWNyZXQgYW5kIG9mZnNldC4gKi8NCisJCXJl YWRfcmFuZG9tKCZpc25fb2Zmc2V0LCBzaXplb2YodV9pbnQzMl90KSk7DQor CQlyZWFkX3JhbmRvbSgmaXNuX3NlY3JldCwgc2l6ZW9mKGlzbl9zZWNyZXQp KTsNCisJCWlzbl9yZXNlZWRfdGltZSA9IHRpY2tzICsgKElTTl9SRVNFRURf SU5UVkwgKiBoeik7DQogCX0NCiANCisJaWYgKCgodHAtPnRfc3RhdGUgPT0g VENQU19MSVNURU4pIHx8ICh0cC0+dF9zdGF0ZSA9PSBUQ1BTX1RJTUVfV0FJ VCkpDQorCSAgICYmIHRjcF9zZXFfZ2Vuc2NoZW1lID09IDEpDQorCQlyZXR1 cm4gYXJjNHJhbmRvbSgpOw0KKwlNRDVJbml0KCZjdHgpOw0KKwlNRDVVcGRh dGUoJmN0eCwgKHVfY2hhciAqKSAmdHAtPnRfaW5wY2ItPmlucF9mcG9ydCwg c2l6ZW9mKHVfc2hvcnQpKTsNCisJTUQ1VXBkYXRlKCZjdHgsICh1X2NoYXIg KikgJnRwLT50X2lucGNiLT5pbnBfbHBvcnQsIHNpemVvZih1X3Nob3J0KSk7 DQorI2lmZGVmIElORVQ2DQorCWlmICgodHAtPnRfaW5wY2ItPmlucF92Zmxh ZyAmIElOUF9JUFY2KSAhPSAwKSB7DQorCQlNRDVVcGRhdGUoJmN0eCwgKHVf Y2hhciAqKSAmdHAtPnRfaW5wY2ItPmluNnBfZmFkZHIsDQorCQkJICBzaXpl b2Yoc3RydWN0IGluNl9hZGRyKSk7DQorCQlNRDVVcGRhdGUoJmN0eCwgKHVf Y2hhciAqKSAmdHAtPnRfaW5wY2ItPmluNnBfbGFkZHIsDQorCQkJICBzaXpl b2Yoc3RydWN0IGluNl9hZGRyKSk7DQorCX0gZWxzZQ0KKyNlbmRpZg0KKwkJ ew0KKwkJTUQ1VXBkYXRlKCZjdHgsICh1X2NoYXIgKikgJnRwLT50X2lucGNi LT5pbnBfZmFkZHIsDQorCQkJICBzaXplb2Yoc3RydWN0IGluX2FkZHIpKTsN CisJCU1ENVVwZGF0ZSgmY3R4LCAodV9jaGFyICopICZ0cC0+dF9pbnBjYi0+ aW5wX2xhZGRyLA0KKwkJCSAgc2l6ZW9mKHN0cnVjdCBpbl9hZGRyKSk7DQor CX0NCisJTUQ1VXBkYXRlKCZjdHgsICh1X2NoYXIgKikgJmlzbl9zZWNyZXQs IHNpemVvZihpc25fc2VjcmV0KSk7DQorCU1ENUZpbmFsKCh1X2NoYXIgKikg Jm1kNV9idWZmZXIsICZjdHgpOw0KKwluZXdfaXNuID0gKHRjcF9zZXEpIG1k NV9idWZmZXJbMF07DQorCW5ld19pc24gKz0gdGlja3MgKiAoSVNOX0JZVEVT X1BFUl9TRUNPTkQgLyBoeik7DQorCW5ld19pc24gKz0gaXNuX29mZnNldDsN CisJcmV0dXJuIG5ld19pc247DQogfQ0KIA0KICNkZWZpbmUgVENQX1JORElT U19ST1VORFMJMTYNCmRpZmYgLXUgLXIgbmV0aW5ldC5vbGQvdGNwX3VzcnJl cS5jIG5ldGluZXQvdGNwX3VzcnJlcS5jDQotLS0gbmV0aW5ldC5vbGQvdGNw X3VzcnJlcS5jCVRodSBKdWwgMTkgMjA6NDU6MDEgMjAwMQ0KKysrIG5ldGlu ZXQvdGNwX3VzcnJlcS5jCUZyaSBKdWwgMjAgMjI6Mzg6MjggMjAwMQ0KQEAg LTc1OCw3ICs3NTgsNyBAQA0KIAl0Y3BzdGF0LnRjcHNfY29ubmF0dGVtcHQr KzsNCiAJdHAtPnRfc3RhdGUgPSBUQ1BTX1NZTl9TRU5UOw0KIAljYWxsb3V0 X3Jlc2V0KHRwLT50dF9rZWVwLCB0Y3Bfa2VlcGluaXQsIHRjcF90aW1lcl9r ZWVwLCB0cCk7DQotCXRwLT5pc3MgPSB0Y3BfbmV3X2lzbigpOw0KKwl0cC0+ aXNzID0gdGNwX25ld19pc24odHApOw0KIAl0Y3Bfc2VuZHNlcWluaXQodHAp Ow0KIA0KIAkvKg0KQEAgLTg0NCw3ICs4NDQsNyBAQA0KIAl0Y3BzdGF0LnRj cHNfY29ubmF0dGVtcHQrKzsNCiAJdHAtPnRfc3RhdGUgPSBUQ1BTX1NZTl9T RU5UOw0KIAljYWxsb3V0X3Jlc2V0KHRwLT50dF9rZWVwLCB0Y3Bfa2VlcGlu aXQsIHRjcF90aW1lcl9rZWVwLCB0cCk7DQotCXRwLT5pc3MgPSB0Y3BfbmV3 X2lzbigpOw0KKwl0cC0+aXNzID0gdGNwX25ld19pc24odHApOw0KIAl0Y3Bf c2VuZHNlcWluaXQodHApOw0KIA0KIAkvKg0KZGlmZiAtdSAtciBuZXRpbmV0 Lm9sZC90Y3BfdmFyLmggbmV0aW5ldC90Y3BfdmFyLmgNCi0tLSBuZXRpbmV0 Lm9sZC90Y3BfdmFyLmgJVGh1IEp1bCAxOSAyMDo0NTowMSAyMDAxDQorKysg bmV0aW5ldC90Y3BfdmFyLmgJVGh1IEp1bCAxOSAyMDo0NjowMSAyMDAxDQpA QCAtNDE0LDcgKzQxNCw3IEBADQogdGNwX3NlcQl0Y3Bfcm5kaXNzX25leHQg X19QKCh2b2lkKSk7DQogdV9pbnQxNl90DQogCXRjcF9ybmRpc3NfZW5jcnlw dCBfX1AoKHVfaW50MTZfdCkpOw0KLXRjcF9zZXEgdGNwX25ld19pc24gX19Q KCh2b2lkKSk7DQordGNwX3NlcSB0Y3BfbmV3X2lzbiBfX1AoKHN0cnVjdCB0 Y3BjYiAqKSk7DQogDQogI2VuZGlmIC8qIF9LRVJORUwgKi8NCiANCg== --0-155072002-996034797=:31803-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 22:16:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 2377437B409; Tue, 24 Jul 2001 22:16:21 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f6P5GG541239; Tue, 24 Jul 2001 22:16:16 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Jul 2001 22:16:16 -0700 (PDT) From: Matt Dillon Message-Id: <200107250516.f6P5GG541239@earth.backplane.com> To: "David O'Brien" Cc: Mike Silbersack , arch@FreeBSD.ORG, Bosko Milekic , "David O'Brien" Subject: Re: cvs commit: src/sys/netinet tcp_usrreq.c References: <20010718121851.B26558@dragon.nuxi.com> <20010718214902.H6519-100000@achilles.silby.com> <20010724205513.H5825@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG My only comment here is to be mindful of the trouble we ran into with the buffer cache (for example)... running out of KVM space due to KVM not scaling with real memory. I think we not only want to try to scale w/ real memory, we also need to cap it based on KVM. For the suggestion below (2048 + MAXUSERS * 16), we have to be careful in regards to losing our ability to operate on machines with small amounts of memory. It may be a good idea to implement the real memory *AND* the KVM-based cap now in order to prevent both the low-memory case and the too-much-memory case from blowing up KVM. (I also agree re: maxfiles/sockets, with the same stipulation - based on the maximum malloc area size). I think KVM management has gotten to the point where we might as well setup page tables for the entire 1GB, which will cost us 1MB of ram for page tables. If we do that it will remove or greatly reduce one of the many problems we have to deal with. Then if someone decides to shift the kernel start address down we can simply assume that that means they want even *more* KVM space. The real and KVM scaling code would take care of the rest. -Matt :> In 4.x, the setting is currently at: :> (512 + MAXUSERS * 16) :> :> current was :> (1024 + MAXUSERS * 16) :> :> before your scaling change (to * 64). :> :> How about we instead change the constant amount, to perhaps: :> (2048 + MAXUSERS * 16) : :I am open to this change, but would like see others comment also on this :proposal. : :> (I'd like to do the scaling based on RAM size, :> but I don't have time at the moment.) : :Agreed. I started on a set of diffs, but have not had time to finish :them and test them. : :> Note that if we're increasing this, we should probably increase :> maxfiles/sockets - that's probably more important now. : :Any one else with an opinion on this? : :-- :-- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 24 23:24:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 03CB737B406 for ; Tue, 24 Jul 2001 23:24:45 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id QAA11392; Wed, 25 Jul 2001 16:24:29 +1000 (EST) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37641) with ESMTP id <01K6CRNS1FCGVFCCN9@cim.alcatel.com.au>; Wed, 25 Jul 2001 16:24:25 +1000 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f6P6OQ565918; Wed, 25 Jul 2001 16:24:26 +1000 (EST envelope-from jeremyp) Content-return: prohibited Date: Wed, 25 Jul 2001 16:24:26 +1000 From: Peter Jeremy Subject: Re: cvs commit: src/sys/netinet tcp_usrreq.c In-reply-to: <200107250516.f6P5GG541239@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Jul 24, 2001 at 10:16:16PM -0700 To: Matt Dillon Cc: arch@FreeBSD.ORG Mail-Followup-To: Matt Dillon , arch@FreeBSD.ORG Message-id: <20010725162426.R506@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <20010718121851.B26558@dragon.nuxi.com> <20010718214902.H6519-100000@achilles.silby.com> <20010724205513.H5825@dragon.nuxi.com> <200107250516.f6P5GG541239@earth.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Cc: trimmed] On 2001-Jul-24 22:16:16 -0700, Matt Dillon wrote: > I think KVM management has gotten to the point where we might as well > setup page tables for the entire 1GB, which will cost us 1MB of ram > for page tables. This is still a hit for small memory machines. 4.3-RELEASE states "minimum 16MB RAM" - 1MB a significant slice of this. > If we do that it will remove or greatly reduce one of > the many problems we have to deal with. Accepted. I think the idea of allocating page tables for KVM is worthwhile. I just think we need to make KVM scalable first. Would it be practical to move the kernel to the top of memory and have the KVM space grow down to a size determined by physical RAM (eg KVM is the same as physical RAM[1], capped to say 2GB) and then allocate page tables to suit. (This has the added advantage of not needing the kernel to be re-linked if you need >1GB KVM). [1] I don't think anything in KVM is currently pageable so it doesn't make sense to have more KVM than RAM. If this isn't true, or when we implement pageable KVM, we can increase the KVM to physical RAM ratio. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 0:48:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by hub.freebsd.org (Postfix) with ESMTP id 5919F37B405; Wed, 25 Jul 2001 00:48:45 -0700 (PDT) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.11.4/8.11.4) id f6P7SA522199; Wed, 25 Jul 2001 03:28:10 -0400 (EDT) (envelope-from barney) Date: Wed, 25 Jul 2001 03:28:05 -0400 From: Barney Wolff To: Mike Silbersack Cc: arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: TCP sequence numbers: RFC1948 patch ready for testing Message-ID: <20010725032805.A21133@tp.databus.com> References: <20010724230813.A31803-200000@achilles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010724230813.A31803-200000@achilles.silby.com>; from silby@silby.com on Tue, Jul 24, 2001 at 11:19:57PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have a few comments :) 1. Rekeying is completely unnecessary - talking of brute-forcing the MD5 of a 32-byte random secret is fantasy, for the forseeable future. Similarly, isn_offset adds nothing real to security. 2. By rekeying you risk violating the monotonicity of the isn across the rekeying, which is the whole point of not just doing random isn. 3. Unless I'm confused, hz is typically 100 or 1000, meaning that the signed-32 tick counters you're relying on to trigger rekeying will flip sign and overflow within the typical uptime of a server. You risk having the test fail for a long time, if isn_reseed_time is a large positive and ticks has become negative before you get to test it. Of course that's no loss, imo. 4. As a nit, if you're going to do the rekeying check, do it only when you're actually going to do the md5 work, not before the test that may return arc4random. 5. You seem to have ignored 1948's advice to include some configurable secret in the hash - are we really sure that read_random gives good bits right after reboot? Regards, Barney Wolff On Tue, Jul 24, 2001 at 11:19:57PM -0500, Mike Silbersack wrote: > > Hello all, the RFC1948-like sequence number generation patch is ready for > testing. The patch included will apply cleanly to both a recent -current > and a recent -stable. I've spent a good deal of time looking at tcpdump > logs, and it looks good to me. > > Please test and review this if you feel comfortable doing so. If you do > not feel comfortable doing so, please simply test it instead. :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 0:53:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 3133137B405 for ; Wed, 25 Jul 2001 00:53:32 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id C5B783E28; Wed, 25 Jul 2001 00:53:31 -0700 (PDT) To: Garrett Wollman Cc: Brian Somers , arch@FreeBSD.ORG Subject: Re: Changes to utmp, wtmp & lastlog entries In-Reply-To: <200107242306.f6ON6xi06524@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on "Tue, 24 Jul 2001 19:06:59 -0400 (EDT)" Date: Wed, 25 Jul 2001 00:53:31 -0700 From: Dima Dorfman Message-Id: <20010725075331.C5B783E28@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garrett Wollman writes: > < said: > > > Garrett, would you mind looking at importing the Austin API for this ? > > There is no ``importing'' to be done. Someone has to actually sit > down and write the code. I have absolutely zero cycles free to do > this myself, but I'd be happy to provide the relevant information Depending on how much there is to do (e.g., 100 routines vs. 10 routines, plus complexity, etc.), I can see about implementing it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 1: 1:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id A869E37B405; Wed, 25 Jul 2001 01:01:15 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.141.74.Dial1.SanJose1.Level3.net [209.245.141.74]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA03362; Wed, 25 Jul 2001 01:01:06 -0700 (PDT) Message-ID: <3B5E7CE2.C6A4EE4B@mindspring.com> Date: Wed, 25 Jul 2001 01:01:38 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Dillon Cc: "David O'Brien" , Mike Silbersack , arch@FreeBSD.ORG, Bosko Milekic , "David O'Brien" Subject: Re: cvs commit: src/sys/netinet tcp_usrreq.c References: <20010718121851.B26558@dragon.nuxi.com> <20010718214902.H6519-100000@achilles.silby.com> <20010724205513.H5825@dragon.nuxi.com> <200107250516.f6P5GG541239@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matt Dillon wrote: > I think KVM management has gotten to the point where we might as well > setup page tables for the entire 1GB, which will cost us 1MB of ram > for page tables. If we do that it will remove or greatly reduce one of > the many problems we have to deal with. Then if someone decides to shift > the kernel start address down we can simply assume that that means they > want even *more* KVM space. The real and KVM scaling code would take > care of the rest. Please do not do this. The FreeBSD footprint is already over 8M for a minimal install, which is ridiculous; I frequently did 386BSD in 4M, and cut down versions in 1M, and FreeBSD 1.x would install in 4M as well, without a lot of trouble. Burning 1M on page tables under the assumption that you'll have 1G or more of RAM is a _very_ bad idea. Handling additional page tables is the job of "growkernel". Personally, I run with most everything in 4M pages, which means a drastically reduced page table cost, but that is obviously not for everyone. I _do not_ currently recover the pages burnt for page tables set up before the VM is really up, which means that that 1M you waste won't be recoverable for me, at all (and I think I'm in the best position of anyone out there to recover it, right now). You would do much better to fix the startup code to do the right thing, rather than eliminating what I consider a very useful feature: sparse initial page table allocation. Also, be aware, if you were to produce an allocator that was not type stable for interrupt level allocations using anonymous backing pages for which entries exist, but pages do not, you would need to also resolve the isue, instead of sweeping it under the rug of static preallocation like this... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 1: 9:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 6583637B403 for ; Wed, 25 Jul 2001 01:09:23 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.141.74.Dial1.SanJose1.Level3.net [209.245.141.74]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA20060; Wed, 25 Jul 2001 01:09:11 -0700 (PDT) Message-ID: <3B5E7ECE.2060AD2C@mindspring.com> Date: Wed, 25 Jul 2001 01:09:50 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Jeremy Cc: Matt Dillon , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet tcp_usrreq.c References: <20010718121851.B26558@dragon.nuxi.com> <20010718214902.H6519-100000@achilles.silby.com> <20010724205513.H5825@dragon.nuxi.com> <200107250516.f6P5GG541239@earth.backplane.com> <20010725162426.R506@gsmx07.alcatel.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Jeremy wrote: > > If we do that it will remove or greatly reduce one of > > the many problems we have to deal with. > > Accepted. I think the idea of allocating page tables for KVM is > worthwhile. I just think we need to make KVM scalable first. I concur: scalability first, overoptimization at the expense of scarce resources second (if ever). > Would it be practical to move the kernel to the top of memory and have > the KVM space grow down to a size determined by physical RAM (eg KVM > is the same as physical RAM[1], capped to say 2GB) and then allocate > page tables to suit. (This has the added advantage of not needing the > kernel to be re-linked if you need >1GB KVM). Not really. The problem is the free reserve in user space, and user space mappings wanting (a) contiguity and (b) sparseness. > [1] I don't think anything in KVM is currently pageable so it doesn't > make sense to have more KVM than RAM. If this isn't true, or when > we implement pageable KVM, we can increase the KVM to physical RAM > ratio. You can allocate pageable kernel memory, it's just that most of the allocations are non-ppageable, and none of the kernel itself is, since we neither set nor respect the ELF attribute indicating "non-pageable" to protect things in our paging path (#pragma section(section_name)...). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 9: 2:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from technokratis.com (modemcable052.174-202-24.mtl.mc.videotron.ca [24.202.174.52]) by hub.freebsd.org (Postfix) with ESMTP id F1D7F37B409; Wed, 25 Jul 2001 09:01:27 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by technokratis.com (8.11.3/8.11.3) id f6PG4d624254; Wed, 25 Jul 2001 12:04:39 -0400 (EDT) (envelope-from bmilekic) Date: Wed, 25 Jul 2001 12:04:39 -0400 From: Bosko Milekic To: "David O'Brien" Cc: Mike Silbersack , arch@FreeBSD.ORG, Matt Dillon , "David O'Brien" Subject: Re: cvs commit: src/sys/netinet tcp_usrreq.c Message-ID: <20010725120439.A24103@technokratis.com> References: <20010718121851.B26558@dragon.nuxi.com> <20010718214902.H6519-100000@achilles.silby.com> <20010724205513.H5825@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010724205513.H5825@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Tue, Jul 24, 2001 at 08:55:13PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jul 24, 2001 at 08:55:13PM -0700, David O'Brien wrote: > On Wed, Jul 18, 2001 at 10:04:45PM -0500, Mike Silbersack wrote: > > I think you're right in increasing the number of mbufs, but changing the > > scaling factor is probably the wrong way to do it; it will cause people > > with custom kernels to have many thousands more mbufs than they expect. > > > > In 4.x, the setting is currently at: > > (512 + MAXUSERS * 16) > > > > current was > > (1024 + MAXUSERS * 16) > > > > before your scaling change (to * 64). > > > > How about we instead change the constant amount, to perhaps: > > (2048 + MAXUSERS * 16) > > I am open to this change, but would like see others comment also on this > proposal. This means that the absolute theoretical minimum is increased. I don't see it as much of a problem except on machines with really low amount of RAM, but then those [rare] guys can use the boot-time tunables accordingly. > > (I'd like to do the scaling based on RAM size, > > but I don't have time at the moment.) > > Agreed. I started on a set of diffs, but have not had time to finish > them and test them. > > > Note that if we're increasing this, we should probably increase > > maxfiles/sockets - that's probably more important now. > > Any one else with an opinion on this? > > -- > -- David (obrien@FreeBSD.org) -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 9:24: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from assaris.sics.se (h122n4fls32o892.telia.com [213.64.47.122]) by hub.freebsd.org (Postfix) with ESMTP id 767E037B41D for ; Wed, 25 Jul 2001 09:23:58 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id SAA29184; Wed, 25 Jul 2001 18:23:37 +0200 (CEST) (envelope-from assar) To: Mike Heffner Cc: Warner Losh , arch@FreeBSD.ORG Subject: Re: Making glob(3) portable (was Re: Importing lukemftpd) References: From: Assar Westerlund Date: 25 Jul 2001 18:23:35 +0200 In-Reply-To: Mike Heffner's message of "Tue, 24 Jul 2001 23:41:00 -0400 (EDT)" Message-ID: <5ly9pduge0.fsf@assaris.sics.se> Lines: 15 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Heffner writes: > In what way is it not as bad? I agree that we don't have all the error values > that NetBSD and OpenBSD have, but using a different one for this scenario than > what the other *BSDs use is not very portable either. The state where the FreeBSD error code had the same name as the Net/OpenBSD option was bad, because then code using GLOB_LIMIT would just build and fail badly at run-time. > IMO, removing GLOB_LIMITHIT, or whatever, and just using GLOB_NOSPACE with > errno=0 would be the first step in the direction of portability. Sure, we can do that. /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 12:34:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from d170h113.resnet.uconn.edu (d170h113.resnet.uconn.edu [137.99.170.113]) by hub.freebsd.org (Postfix) with SMTP id 1CB5D37B405 for ; Wed, 25 Jul 2001 12:34:54 -0700 (PDT) (envelope-from sirmoo@cowbert.2y.net) Received: (qmail 16584 invoked by uid 1001); 25 Jul 2001 19:35:15 -0000 Message-ID: <20010725193515.16583.qmail@d170h113.resnet.uconn.edu> References: <000f01c11315$094851e0$420d640a@HELL> <200107230354.f6N3stj13517@earth.backplane.com> <200107231538.f6NFcZl81468@khavrinen.lcs.mit.edu> <200107231557.f6NFvQb17025@earth.backplane.com> <200107231649.f6NGnq982448@khavrinen.lcs.mit.edu> <200107231707.f6NH7wU18016@earth.backplane.com> In-Reply-To: From: "Peter C. Lai" To: Garance A Drosihn Cc: Matt Dillon , arch@FreeBSD.ORG, Garrett Wollman , brian@FreeBSD.ORG Subject: Re: Changes to utmp, wtmp & lastlog entries Date: Wed, 25 Jul 2001 19:35:14 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Furthermore, there is a problem with the way that lastlog records logoffs via HUP. If someone ssh's in, and then HUPs the terminal without using "logout" or "exit" (e.g. by closing the window) then lastlog records that they are still logged in. This makes login accounting difficult. Now should I submit this as a separate PR about about lastlog or should this be tacked on to changes for lastlog/*tmp? Garance A Drosihn writes: > This is a spin-off of the thread in -security about: > bin/22595: telnetd tricked into using arbitrary peer ip > > I figured we might as well bring it up in -arch at this point. The > question is what (if any) changes should we make to the way entries > are made to utmp, wtmp, and lastlog. If you look at that PR, there > are some security implications wrt how those entries are currently > handled, and thus it would be a good idea to do something about them. > > I'm quoting some of the recent background here, but you'd want to > check that PR (and all the followup entries to it) for full details: > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=22595 > > > At 10:07 AM -0700 7/23/01, Matt Dillon wrote: >> Garrett Wollman wrote: >> :<> :> Garrett Wollman wrote: >> :> : SVR4 has an API. This API is standardized as a part of >> :> : the Austin Group process. >> : >> :> Fine.. then if you want to get all the third party program >> :> authors to use a magic API, be my guest. >> : >> : If they run on Solaris -- which most of them do -- then they already >> : do. Nice try, Matt, but far off the mark. >> : >> :-GAWollman >> >> Really.. Lets see. wu-ftpd... nope. proftpd... nope. Want me >> to continue? > > Still... If there *is* an API which would be common to both Solaris > and FreeBSD, then it should be much easier to get third-party program > authors to accept changes to use that API. > > As for the best change to make, let me suggest that we basically > follow both Matt's and Garrett's recommendations (which were made > in other messages in the thread). > > Let's increase the size of UT_HOSTSIZE to at least 56, so the field > can always hold the complete IP address (even for IPv6) in the field, > but let's encourage programs to use whatever the standardized API is > to make these entries. There will be a bit of a transition-hit when > the size of the field is changed, where anything that usees or sets > these records will need to be recompiled. Maybe we should do this > change as part of 5.0, and not MFC it. > > If you read all the entries in the PR, Brian noted that OpenBSD has > already changed UT_HOSTSIZE to be 256. I might go for something > larger than 56 (such as 64, just to be a computer geek who always > picks powers of 2...), but I don't think freebsd needs to go all > the way to 256. > > I don't feel too strongly about the actual solution decided upon, > but I did think it was about time to have this topic explicitly > mentioned in freebsd-arch, so we can figure out what is best to do > and then do whatever that is. > > -- > Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu > Senior Systems Programmer or gad@freebsd.org > Rensselaer Polytechnic Institute or drosih@rpi.edu > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message ----------- Peter C. Lai University of Connecticut Dept. of Residential Life | Programmer Dept. of Molecular and Cell Biology | Undergraduate Research Assistant/Honors Program http://cowbert.2y.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 15:15: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from purgatory.unfix.org (purgatory.xs4all.nl [194.109.237.229]) by hub.freebsd.org (Postfix) with ESMTP id AB1A137B406; Wed, 25 Jul 2001 15:14:51 -0700 (PDT) (envelope-from jeroen@unfix.org) Received: from HELL (hell.unfix.org [::ffff:10.100.13.66]) by purgatory.unfix.org (Postfix) with ESMTP id 260433146; Thu, 26 Jul 2001 00:14:47 +0200 (CEST) From: "Jeroen Massar" To: "'Peter C. Lai'" , "'Garance A Drosihn'" Cc: "'Matt Dillon'" , , "'Garrett Wollman'" , Subject: RE: Changes to utmp, wtmp & lastlog entries Date: Thu, 26 Jul 2001 00:14:31 +0200 Organization: Unfix Message-ID: <000701c11557$2e9e7840$420d640a@HELL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <20010725193515.16583.qmail@d170h113.resnet.uconn.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter C. Lai wrote: > > This is a spin-off of the thread in -security about: > > bin/22595: telnetd tricked into using arbitrary peer ip > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=22595 > > > > > > At 10:07 AM -0700 7/23/01, Matt Dillon wrote: > >> Garrett Wollman wrote: > >> :< >> :> Garrett Wollman wrote: > >> :> : SVR4 has an API. This API is standardized as a part of > >> :> : the Austin Group process. > >> : > >> :> Fine.. then if you want to get all the third party program > >> :> authors to use a magic API, be my guest. > >> : > >> : If they run on Solaris -- which most of them do -- then > they already > >> : do. Nice try, Matt, but far off the mark. > >> : > >> :-GAWollman > >> > >> Really.. Lets see. wu-ftpd... nope. proftpd... nope. Want me > >> to continue? > > > > Still... If there *is* an API which would be common to both Solaris > > and FreeBSD, then it should be much easier to get > third-party program > > authors to accept changes to use that API. What I've suggested on the security@ list was: Make a nice API which will wrap all this stuff up for good: - This API will log in a different file then wtmp/utmp/lastlog. - A program is free to use the API or not, though it is encouraged too (and basically the author of the program would be kinda stupid not to :) - API using programs can only "write" to the new API camouflaged system (be it a SQL database, a flat file whatever, the app won't see it). - The "old" utmp/wtmp/lastlog is wrapped in the API whenever something is queried... so... API using programs query for the last accounts used for logging in... The API then sees "hey we still use the old utmp/wtmp/lastlog stuff" and reads entries from there in addition to from it's own db/file whatever. The API should simply eat strings of undefined length or spit strings with predefined buffer lengths: Putlastlog(char *accountname, char *hostaddress, int af_type); Getlastlog(char *accountname, char *hostaddress, int *af_type, int acct_len, int host_len); Tada all problems solved.... And we could get more evil to have a small program in cron or something merge the "old" utmp/wtmp/lastlog stuff into the new API enabled form. And throw away the old entries. This could be done verywell as there are only a few programs 'relying' on reading from the files (eg w/who :). Another nice thing to do would be to make the API convinient to be used on other platforms, thus make a "old wrapper only" version which writes directly into utmp/wtmp/lastlog. This way programmers of the client apps are easier to be encouraged to use it, as they can simply use the wrapper on platforms which don't have the real API backend we want to have. Wrap the wrappers and make it all happy for yourself :) Greets, Jeroen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 15:28:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from d170h113.resnet.uconn.edu (d170h113.resnet.uconn.edu [137.99.170.113]) by hub.freebsd.org (Postfix) with SMTP id 4665C37B40B for ; Wed, 25 Jul 2001 15:28:27 -0700 (PDT) (envelope-from sirmoo@cowbert.2y.net) Received: (qmail 17039 invoked by uid 1001); 25 Jul 2001 22:28:49 -0000 Message-ID: <20010725222849.17038.qmail@d170h113.resnet.uconn.edu> References: <000701c11557$2e9e7840$420d640a@HELL> In-Reply-To: <000701c11557$2e9e7840$420d640a@HELL> From: "Peter C. Lai" To: "Jeroen Massar" Cc: "'Garance A Drosihn'" , "'Matt Dillon'" , arch@FreeBSD.ORG, "'Garrett Wollman'" , brian@FreeBSD.ORG Subject: Re: Changes to utmp, wtmp & lastlog entries Date: Wed, 25 Jul 2001 22:28:49 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG all true and good, but i think my issue was that suppose a 3rd party application doesn't log correctly at all (in the case i mentioned, it could be the shell's or pam's or sshd's fault (or some combination thereof) that it does not regard HUPing a shell as a proper logout.). Changing the way utmp/wtmp is recorded isn't going to change the data. However, i did say i probably posted to the wrong thread, but it is still related to the issue of erroneous data in lastlog. Jeroen Massar writes: > Peter C. Lai wrote: > > >> > This is a spin-off of the thread in -security about: >> > bin/22595: telnetd tricked into using arbitrary peer ip > >> > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=22595 >> > >> > >> > At 10:07 AM -0700 7/23/01, Matt Dillon wrote: >> >> Garrett Wollman wrote: >> >> :<> >> :> Garrett Wollman wrote: >> >> :> : SVR4 has an API. This API is standardized as a part of >> >> :> : the Austin Group process. >> >> : >> >> :> Fine.. then if you want to get all the third party program >> >> :> authors to use a magic API, be my guest. >> >> : >> >> : If they run on Solaris -- which most of them do -- then >> they already >> >> : do. Nice try, Matt, but far off the mark. >> >> : >> >> :-GAWollman >> >> >> >> Really.. Lets see. wu-ftpd... nope. proftpd... nope. Want me >> >> to continue? >> > >> > Still... If there *is* an API which would be common to both Solaris >> > and FreeBSD, then it should be much easier to get >> third-party program >> > authors to accept changes to use that API. > > > What I've suggested on the security@ list was: > > Make a nice API which will wrap all this stuff up for good: > - This API will log in a different file then wtmp/utmp/lastlog. > - A program is free to use the API or not, though it is encouraged too > (and basically the author of the program would be kinda stupid not to :) > - API using programs can only "write" to the new API camouflaged system > (be it a SQL database, a flat file whatever, the app won't see it). > - The "old" utmp/wtmp/lastlog is wrapped in the API whenever something > is queried... so... API using programs query for the last accounts used > for logging in... > The API then sees "hey we still use the old utmp/wtmp/lastlog stuff" > and reads entries from there in addition to from it's own db/file > whatever. > > The API should simply eat strings of undefined length or spit strings > with predefined buffer lengths: > > Putlastlog(char *accountname, char *hostaddress, int af_type); > Getlastlog(char *accountname, char *hostaddress, int *af_type, int > acct_len, int host_len); > > Tada all problems solved.... And we could get more evil to have a small > program in cron or something merge the "old" utmp/wtmp/lastlog stuff > into the new API enabled form. > And throw away the old entries. This could be done verywell as there are > only a few programs 'relying' on reading from the files (eg w/who :). > > Another nice thing to do would be to make the API convinient to be used > on other platforms, thus make a "old wrapper only" version which writes > directly into utmp/wtmp/lastlog. > This way programmers of the client apps are easier to be encouraged to > use it, as they can simply use the wrapper on platforms which don't have > the real API backend we want to have. > > Wrap the wrappers and make it all happy for yourself :) > > Greets, > Jeroen > ----------- Peter C. Lai University of Connecticut Dept. of Residential Life | Programmer Dept. of Molecular and Cell Biology | Undergraduate Research Assistant/Honors Program http://cowbert.2y.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 15:38:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from purgatory.unfix.org (purgatory.xs4all.nl [194.109.237.229]) by hub.freebsd.org (Postfix) with ESMTP id 65D8D37B408; Wed, 25 Jul 2001 15:38:32 -0700 (PDT) (envelope-from jeroen@unfix.org) Received: from HELL (hell.unfix.org [::ffff:10.100.13.66]) by purgatory.unfix.org (Postfix) with ESMTP id 418653146; Thu, 26 Jul 2001 00:38:30 +0200 (CEST) From: "Jeroen Massar" To: "'Peter C. Lai'" Cc: "'Garance A Drosihn'" , "'Matt Dillon'" , , "'Garrett Wollman'" , Subject: RE: Changes to utmp, wtmp & lastlog entries Date: Thu, 26 Jul 2001 00:38:14 +0200 Organization: Unfix Message-ID: <000f01c1155a$7e268c60$420d640a@HELL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <20010725222849.17038.qmail@d170h113.resnet.uconn.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter C. Lai [mailto:sirmoo@cowbert.2y.net] wrote: > all true and good, but i think my issue was that suppose a 3rd party > application doesn't log correctly at all (in the case i > mentioned, it could > be the shell's or pam's or sshd's fault (or some combination > thereof) that > it does not regard HUPing a shell as a proper logout.). > Changing the way > utmp/wtmp is recorded isn't going to change the data. > However, i did say i > probably posted to the wrong thread, but it is still related > to the issue of > erroneous data in lastlog. If you want to 'solve' that you will require kernel hooks of some kind which hook into the begin&exit calls of the task/thread/process. This way one can also catch broken/crashed applications. Then again lastlog/who != ps :) Greets, Jeroen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 17: 5:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 8B4FB37B409 for ; Wed, 25 Jul 2001 17:04:55 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 35910 invoked by uid 1000); 26 Jul 2001 00:04:54 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Jul 2001 00:04:54 -0000 Date: Wed, 25 Jul 2001 19:04:54 -0500 (CDT) From: Mike Silbersack To: Barney Wolff Cc: , Subject: Re: TCP sequence numbers: RFC1948 patch ready for testing In-Reply-To: <20010725032805.A21133@tp.databus.com> Message-ID: <20010725185434.V35719-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 25 Jul 2001, Barney Wolff wrote: > I have a few comments :) > > 1. Rekeying is completely unnecessary - talking of brute-forcing > the MD5 of a 32-byte random secret is fantasy, for the forseeable future. > Similarly, isn_offset adds nothing real to security. > > 2. By rekeying you risk violating the monotonicity of the isn across > the rekeying, which is the whole point of not just doing random isn. I'll go ahead and remove the isn_offset addition. I'm not really willing to remove the rekeying, though; we can't say that a faster method of brute force attack will not arise. Would a longer rekeying interval such as a day or two suffice? I'm not concerned about rekeying breaking a few connections given that it will only happen occasionally. > 3. Unless I'm confused, hz is typically 100 or 1000, meaning that the > signed-32 tick counters you're relying on to trigger rekeying will > flip sign and overflow within the typical uptime of a server. You > risk having the test fail for a long time, if isn_reseed_time is a > large positive and ticks has become negative before you get to test it. > Of course that's no loss, imo. Doh! I'll fix that in the next rev of the patch. > 4. As a nit, if you're going to do the rekeying check, do it only when > you're actually going to do the md5 work, not before the test that > may return arc4random. Will do as well. > 5. You seem to have ignored 1948's advice to include some configurable > secret in the hash - are we really sure that read_random gives good > bits right after reboot? I didn't think second-guessing the random dev would be a worthwhile endeavor, as it would probably just lead to less entropy. (Especially given that noone would ever set the configureable secret.) However, boot time randomness is a valid concern. We're slightly lucky in that the initial keying doesn't occur until the first connection, which isn't at a fixed time in the kernel startup, but is rather dependant on usage of the box. I'll check with Mark Murray on this. (And in 4.x, I'll use read_random_unlimited so that the entropy doesn't get truncated.) Thanks for the comments, Mike "Silby" Silbersack > > Regards, > Barney Wolff > > On Tue, Jul 24, 2001 at 11:19:57PM -0500, Mike Silbersack wrote: > > > > Hello all, the RFC1948-like sequence number generation patch is ready for > > testing. The patch included will apply cleanly to both a recent -current > > and a recent -stable. I've spent a good deal of time looking at tcpdump > > logs, and it looks good to me. > > > > Please test and review this if you feel comfortable doing so. If you do > > not feel comfortable doing so, please simply test it instead. :) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 17:39:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.tgd.net (rand.tgd.net [64.81.67.117]) by hub.freebsd.org (Postfix) with SMTP id 012B337B408 for ; Wed, 25 Jul 2001 17:39:05 -0700 (PDT) (envelope-from sean@mailhost.tgd.net) Received: (qmail 66726 invoked by uid 1001); 26 Jul 2001 00:38:59 -0000 Date: Wed, 25 Jul 2001 17:38:59 -0700 From: Sean Chittenden To: Mike Silbersack Cc: Barney Wolff , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: TCP sequence numbers: RFC1948 patch ready for testing Message-ID: <20010725173859.C65546@rand.tgd.net> References: <20010725032805.A21133@tp.databus.com> <20010725185434.V35719-100000@achilles.silby.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OBd5C1Lgu00Gd/Tn" Content-Disposition: inline In-Reply-To: <20010725185434.V35719-100000@achilles.silby.com>; from "silby@silby.com" on Wed, Jul 25, 2001 at = 07:04:54PM X-PGP-Key: 0x1EDDFAAD X-PGP-Fingerprint: C665 A17F 9A56 286C 5CFB 1DEA 9F4F 5CEF 1EDD FAAD X-Web-Homepage: http://sean.chittenden.org/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --OBd5C1Lgu00Gd/Tn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > 2. By rekeying you risk violating the monotonicity of the isn across > > the rekeying, which is the whole point of not just doing random isn. >=20 > I'll go ahead and remove the isn_offset addition. I'm not really willing > to remove the rekeying, though; we can't say that a faster method of brute > force attack will not arise. Would a longer rekeying interval such as a > day or two suffice? I'm not concerned about rekeying breaking a few > connections given that it will only happen occasionally. While I agree that rekeying isn't something that should be removed, I am concerned with your last sentence. Breaking TCP sessions strikes me as an indicator that there needs to be some way of configuring this. Is there any chance you could make this a tunable variable through sysctl such as the number of seconds between rekeying? Along similar lines, given that rekeying can be done lazily, would it be possible to rekey through the use of an external program that would be called by cron? If TCP sessions are going to be dropped, I want to be able to control, know, and plan when without giving up the added TCP security that this patch provides. -sc --=20 Sean Chittenden --OBd5C1Lgu00Gd/Tn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: Sean Chittenden iEYEARECAAYFAjtfZqIACgkQn09c7x7d+q3n1wCgq2pbyWeB1qwFW+R57u+nBK8S /gwAmwbrOVaXy3pXyIZcSr9OJ0WTOSnG =o2yj -----END PGP SIGNATURE----- --OBd5C1Lgu00Gd/Tn-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 18: 0:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 5CA4437B405 for ; Wed, 25 Jul 2001 18:00:42 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 36079 invoked by uid 1000); 26 Jul 2001 01:00:40 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Jul 2001 01:00:40 -0000 Date: Wed, 25 Jul 2001 20:00:40 -0500 (CDT) From: Mike Silbersack To: Sean Chittenden Cc: Barney Wolff , , Subject: Re: TCP sequence numbers: RFC1948 patch ready for testing In-Reply-To: <20010725173859.C65546@rand.tgd.net> Message-ID: <20010725195901.W36006-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 25 Jul 2001, Sean Chittenden wrote: > > day or two suffice? I'm not concerned about rekeying breaking a few > > connections given that it will only happen occasionally. > > While I agree that rekeying isn't something that should be > removed, I am concerned with your last sentence. Breaking TCP sessions > strikes me as an indicator that there needs to be some way of > configuring this. Is there any chance you could make this a tunable > variable through sysctl such as the number of seconds between rekeying? By "breaking a few connections", I was referring to delaying the establishment of a few connections when TIME_WAIT wraparound occurs, not the termination of active connections. I apologize for the confusion. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 18:38:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by hub.freebsd.org (Postfix) with ESMTP id CBE0937B405; Wed, 25 Jul 2001 18:38:18 -0700 (PDT) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.11.4/8.11.4) id f6Q1cCi29162; Wed, 25 Jul 2001 21:38:12 -0400 (EDT) (envelope-from barney) Date: Wed, 25 Jul 2001 21:38:12 -0400 From: Barney Wolff To: Sean Chittenden Cc: Mike Silbersack , Barney Wolff , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: TCP sequence numbers: RFC1948 patch ready for testing Message-ID: <20010725213812.A28964@tp.databus.com> References: <20010725032805.A21133@tp.databus.com> <20010725185434.V35719-100000@achilles.silby.com> <20010725173859.C65546@rand.tgd.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010725173859.C65546@rand.tgd.net>; from sean-freebsd-arch@chittenden.org on Wed, Jul 25, 2001 at 05:38:59PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Existing sessions would not be broken by rekeying. The risk is that some new session might fail - and this can happen any time a new session with the same tuple starts shortly after an old session which spans the rekeying event ends. If it becomes possible to brute-force (or smart-sneak) reverse MD5 in less time than the life of the Universe, the right answer is to change the hash, not to rekey. You guys don't seem to want to believe RFC1948: Note that the secret cannot easily be changed on a live machine. Doing so would change the initial sequence numbers used for reincarnated connections; to maintain safety, either dead connection state must be kept or a quiet time observed for two maximum segment lifetimes after such a change. Have you asked Steve Bellovin whether he still stands by those words? He's not that unapproachable, despite being one of the most prominent folks in computer networking and security around. But he earned that reputation by being right, pretty close to 100% of the time. Barney On Wed, Jul 25, 2001 at 05:38:59PM -0700, Sean Chittenden wrote: > > > 2. By rekeying you risk violating the monotonicity of the isn across > > > the rekeying, which is the whole point of not just doing random isn. > > > > I'll go ahead and remove the isn_offset addition. I'm not really willing > > to remove the rekeying, though; we can't say that a faster method of brute > > force attack will not arise. Would a longer rekeying interval such as a > > day or two suffice? I'm not concerned about rekeying breaking a few > > connections given that it will only happen occasionally. > > While I agree that rekeying isn't something that should be > removed, I am concerned with your last sentence. Breaking TCP sessions > strikes me as an indicator that there needs to be some way of > configuring this. Is there any chance you could make this a tunable > variable through sysctl such as the number of seconds between rekeying? > > Along similar lines, given that rekeying can be done lazily, > would it be possible to rekey through the use of an external program > that would be called by cron? If TCP sessions are going to be dropped, > I want to be able to control, know, and plan when without giving up the > added TCP security that this patch provides. -sc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 18:59:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id CEC9A37B401; Wed, 25 Jul 2001 18:59:44 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6Q1xct08072; Thu, 26 Jul 2001 02:59:38 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6Q1xbg70362; Thu, 26 Jul 2001 02:59:37 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200107260159.f6Q1xbg70362@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Peter C. Lai" Cc: Garance A Drosihn , Matt Dillon , arch@FreeBSD.ORG, Garrett Wollman , brian@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Changes to utmp, wtmp & lastlog entries In-Reply-To: Message from "Peter C. Lai" of "Wed, 25 Jul 2001 19:35:14 GMT." <20010725193515.16583.qmail@d170h113.resnet.uconn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Jul 2001 02:59:37 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Furthermore, there is a problem with the way that lastlog records logoffs > via HUP. If someone ssh's in, and then HUPs the terminal without using > "logout" or "exit" (e.g. by closing the window) then lastlog records that > they are still logged in. This makes login accounting difficult. Now should > I submit this as a separate PR about about lastlog or should this be tacked > on to changes for lastlog/*tmp? [.....] I think this is a separate bug. > ----------- > Peter C. Lai > University of Connecticut > Dept. of Residential Life | Programmer > Dept. of Molecular and Cell Biology | > Undergraduate Research Assistant/Honors Program > http://cowbert.2y.net/ -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 25 19:47:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from iatl0x01.coxmail.com (iatl0x02.coxmail.com [206.157.225.11]) by hub.freebsd.org (Postfix) with ESMTP id 67C7437B408; Wed, 25 Jul 2001 19:47:32 -0700 (PDT) (envelope-from mheffner@novacoxmail.com) Received: from enterprise.muriel.penguinpowered.com ([209.249.161.66]) by iatl0x01.coxmail.com (InterMail vK.4.03.02.00 201-232-124 license eaa2928f5bcba31507d4d280f1027278) with ESMTP id <20010726024733.DFLK27239.iatl0x01@enterprise.muriel.penguinpowered.com>; Wed, 25 Jul 2001 22:47:33 -0400 Message-ID: X-Mailer: XFMail 1.5.0 on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.5.0.FreeBSD:20010725224518:8043=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <5ly9pduge0.fsf@assaris.sics.se> Date: Wed, 25 Jul 2001 22:45:18 -0400 (EDT) Reply-To: Mike Heffner From: Mike Heffner To: Assar Westerlund Subject: Re: Making glob(3) portable (was Re: Importing lukemftpd) Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.5.0.FreeBSD:20010725224518:8043=_ Content-Type: text/plain; charset=us-ascii On 25-Jul-2001 Assar Westerlund wrote: | Mike Heffner writes: | |> IMO, removing GLOB_LIMITHIT, or whatever, and just using GLOB_NOSPACE with |> errno=0 would be the first step in the direction of portability. | | Sure, we can do that. How's the following patch look: Index: include/glob.h =================================================================== RCS file: /home/ncvs/src/include/glob.h,v retrieving revision 1.4 diff -u -r1.4 glob.h --- include/glob.h 2001/03/19 19:10:06 1.4 +++ include/glob.h 2001/07/26 02:45:43 @@ -77,11 +77,13 @@ #define GLOB_NOMAGIC 0x0200 /* GLOB_NOCHECK without magic chars (csh). */ #define GLOB_QUOTE 0x0400 /* Quote special chars with \. */ #define GLOB_TILDE 0x0800 /* Expand tilde names from the passwd file. */ -#define GLOB_MAXPATH 0x1000 /* limit number of returned paths */ +#define GLOB_LIMIT 0x1000 /* limit number of returned paths */ +/* backwards compatibility, this is the old name for this option */ +#define GLOB_MAXPATH GLOB_LIMIT + #define GLOB_NOSPACE (-1) /* Malloc call failed. */ #define GLOB_ABEND (-2) /* Unignored error. */ -#define GLOB_LIMIT (-3) /* Path limit was hit. */ __BEGIN_DECLS int glob __P((const char *, int, int (*)(const char *, int), glob_t *)); Index: lib/libc/gen/glob.3 =================================================================== RCS file: /home/ncvs/src/lib/libc/gen/glob.3,v retrieving revision 1.16 diff -u -r1.16 glob.3 --- lib/libc/gen/glob.3 2001/07/15 07:53:04 1.16 +++ lib/libc/gen/glob.3 2001/07/26 02:45:43 @@ -260,14 +260,13 @@ Expand patterns that start with .Ql ~ to user name home directories. -.It Dv GLOB_MAXPATH +.It Dv GLOB_LIMIT Limit the total number of returned pathnames to the value provided in -.Fa gl_matchc . -If -.Fn glob -would match more pathnames, -.Dv GLOB_LIMIT -will be returned. +.Fa gl_matchc +(default ARG_MAX). +This option should be set for programs that can be coerced to a denial of service +attack via patterns that expand to a very large number of matches, such as a long +string of */../*/.. .El .Pp If, during the search, a directory is encountered that cannot be opened @@ -377,21 +376,19 @@ .Aq Pa glob.h : .Bl -tag -width GLOB_NOCHECK .It Dv GLOB_NOSPACE -An attempt to allocate memory failed. +An attempt to allocate memory failed, or if +.Fa errno +was 0 +.Dv GLOB_LIMIT +was specified in the flags and +.Fa pglob\->gl_matchc +or more patterns were patched. .It Dv GLOB_ABEND The scan was stopped because an error was encountered and either .Dv GLOB_ERR was set or .Fa \*(lp*errfunc\*(rp\*(lp\*(rp returned non-zero. -.It Dv GLOB_LIMIT -The flag -.Dv GLOB_MAXPATH -was provided, and the specified limit passed to -.Fn glob -in -.Fa pglob\->gl_matchc -was reached. .El .Pp The arguments @@ -427,8 +424,8 @@ that the flags .Dv GLOB_ALTDIRFUNC , .Dv GLOB_BRACE , +.Dv GLOB_LIMIT , .Dv GLOB_MAGCHAR , -.Dv GLOB_MAXPATH , .Dv GLOB_NOMAGIC , .Dv GLOB_QUOTE , and Index: lib/libc/gen/glob.c =================================================================== RCS file: /home/ncvs/src/lib/libc/gen/glob.c,v retrieving revision 1.17 diff -u -r1.17 glob.c --- lib/libc/gen/glob.c 2001/03/28 23:55:51 1.17 +++ lib/libc/gen/glob.c 2001/07/26 02:45:45 @@ -170,9 +170,11 @@ if (!(flags & GLOB_DOOFFS)) pglob->gl_offs = 0; } - if (flags & GLOB_MAXPATH) + if (flags & GLOB_LIMIT) { limit = pglob->gl_matchc; - else + if (limit == 0) + limit = ARG_MAX; + } else limit = 0; pglob->gl_flags = flags & ~GLOB_MAGCHAR; pglob->gl_errfunc = errfunc; @@ -687,8 +689,10 @@ char *copy; const Char *p; - if (*limit && pglob->gl_pathc > *limit) - return (GLOB_LIMIT); + if (*limit && pglob->gl_pathc > *limit) { + errno = 0; + return (GLOB_NOSPACE); + } newsize = sizeof(*pathv) * (2 + pglob->gl_pathc + pglob->gl_offs); pathv = pglob->gl_pathv ? Index: libexec/ftpd/ftpd.c =================================================================== RCS file: /home/ncvs/src/libexec/ftpd/ftpd.c,v retrieving revision 1.78 diff -u -r1.78 ftpd.c --- libexec/ftpd/ftpd.c 2001/07/09 17:46:24 1.78 +++ libexec/ftpd/ftpd.c 2001/07/26 02:45:51 @@ -2658,7 +2658,7 @@ memset(&gl, 0, sizeof(gl)); gl.gl_matchc = MAXGLOBARGS; - flags |= GLOB_MAXPATH; + flags |= GLOB_LIMIT; freeglob = 1; if (glob(whichf, flags, 0, &gl)) { reply(550, "not found"); Index: libexec/ftpd/popen.c =================================================================== RCS file: /home/ncvs/src/libexec/ftpd/popen.c,v retrieving revision 1.20 diff -u -r1.20 popen.c --- libexec/ftpd/popen.c 2001/03/19 19:11:00 1.20 +++ libexec/ftpd/popen.c 2001/07/26 02:45:51 @@ -108,7 +108,7 @@ memset(&gl, 0, sizeof(gl)); gl.gl_matchc = MAXGLOBARGS; - flags |= GLOB_MAXPATH; + flags |= GLOB_LIMIT; if (glob(argv[argc], flags, NULL, &gl)) gargv[gargc++] = strdup(argv[argc]); else Mike -- Mike Heffner Fredericksburg, VA --_=XFMail.1.5.0.FreeBSD:20010725224518:8043=_ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7X4Q9FokZQs3sv5kRAlopAJ9g8AGULI7ro7+ATmsqDvpfQKsY8QCghFiY 9vjdx3G27nnALHVxxVSxgOQ= =lJTd -----END PGP SIGNATURE----- --_=XFMail.1.5.0.FreeBSD:20010725224518:8043=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 26 10:24:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id BD91737B408; Thu, 26 Jul 2001 10:24:17 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.129.59.Dial1.SanJose1.Level3.net [209.245.129.59]) by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id KAA16960; Thu, 26 Jul 2001 10:24:02 -0700 (PDT) Message-ID: <3B605255.EDBA1D3C@mindspring.com> Date: Thu, 26 Jul 2001 10:24:37 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Barney Wolff Cc: Sean Chittenden , Mike Silbersack , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: TCP sequence numbers: RFC1948 patch ready for testing References: <20010725032805.A21133@tp.databus.com> <20010725185434.V35719-100000@achilles.silby.com> <20010725173859.C65546@rand.tgd.net> <20010725213812.A28964@tp.databus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Barney Wolff wrote: > Existing sessions would not be broken by rekeying. The risk is that > some new session might fail - and this can happen any time a new > session with the same tuple starts shortly after an old session which > spans the rekeying event ends. > > If it becomes possible to brute-force (or smart-sneak) reverse MD5 > in less time than the life of the Universe, the right answer is to > change the hash, not to rekey. > > You guys don't seem to want to believe RFC1948: > > Note that the secret cannot easily be changed on a live machine. > Doing so would change the initial sequence numbers used for > reincarnated connections; to maintain safety, either dead connection > state must be kept or a quiet time observed for two maximum segment > lifetimes after such a change. > > Have you asked Steve Bellovin whether he still > stands by those words? He's not that unapproachable, despite being > one of the most prominent folks in computer networking and security > around. But he earned that reputation by being right, pretty close > to 100% of the time. Consider that sequence number rollover is faster than you think on a Gigabit system. 200,000 packets a second on unoptimized firmware is not impossible, and the theoretical maximum is closer to 1/2 million a second... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 26 11:53:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id AB01137B40D; Thu, 26 Jul 2001 11:53:14 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id LAA32363; Thu, 26 Jul 2001 11:51:48 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda32361; Thu Jul 26 11:51:31 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.4/8.9.1) id f6QIpPs06382; Thu, 26 Jul 2001 11:51:25 -0700 (PDT) Received: from UNKNOWN(10.1.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdGE6380; Thu Jul 26 11:50:39 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.4/8.9.1) id f6QIoaa04255; Thu, 26 Jul 2001 11:50:36 -0700 (PDT) Message-Id: <200107261850.f6QIoaa04255@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdzx4248; Thu Jul 26 11:50:02 2001 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: "Peter C. Lai" Cc: "Jeroen Massar" , "'Garance A Drosihn'" , "'Matt Dillon'" , arch@FreeBSD.ORG, "'Garrett Wollman'" , brian@FreeBSD.ORG Subject: Re: Changes to utmp, wtmp & lastlog entries In-reply-to: Your message of "Wed, 25 Jul 2001 22:28:49 GMT." <20010725222849.17038.qmail@d170h113.resnet.uconn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Jul 2001 11:50:02 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20010725222849.17038.qmail@d170h113.resnet.uconn.edu>, "Peter C. La i" writes: > all true and good, but i think my issue was that suppose a 3rd party > application doesn't log correctly at all (in the case i mentioned, it could > be the shell's or pam's or sshd's fault (or some combination thereof) that > it does not regard HUPing a shell as a proper logout.). Changing the way > utmp/wtmp is recorded isn't going to change the data. However, i did say i > probably posted to the wrong thread, but it is still related to the issue of > erroneous data in lastlog. This brings to mind an example I experienced about a month ago after upgrading a Sun system to Solaris 8. The system has MIT Kerberos V. After the upgrade, /var/adm became a wasteland of some useless files (with strange names to boot). A recompile of the application failed to resolve the issue. As in the case of Solaris 8, all applications that write to utmp/wtmp & utmpx/wtmpx need to be aware of any changes, hence applications that once were portable are now not. It is my hope that we avoid the Solaris 8 type of mess when overhauling utmp/wtmp. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD Ministry of Management Services Province of BC > > Jeroen Massar writes: > > > Peter C. Lai wrote: > > > > > >> > This is a spin-off of the thread in -security about: > >> > bin/22595: telnetd tricked into using arbitrary peer ip > > > >> > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=22595 > >> > > >> > > >> > At 10:07 AM -0700 7/23/01, Matt Dillon wrote: > >> >> Garrett Wollman wrote: > >> >> :< >> >> :> Garrett Wollman wrote: > >> >> :> : SVR4 has an API. This API is standardized as a part of > >> >> :> : the Austin Group process. > >> >> : > >> >> :> Fine.. then if you want to get all the third party program > >> >> :> authors to use a magic API, be my guest. > >> >> : > >> >> : If they run on Solaris -- which most of them do -- then > >> they already > >> >> : do. Nice try, Matt, but far off the mark. > >> >> : > >> >> :-GAWollman > >> >> > >> >> Really.. Lets see. wu-ftpd... nope. proftpd... nope. Want me > >> >> to continue? > >> > > >> > Still... If there *is* an API which would be common to both Solaris > >> > and FreeBSD, then it should be much easier to get > >> third-party program > >> > authors to accept changes to use that API. > > > > > > What I've suggested on the security@ list was: > > > > Make a nice API which will wrap all this stuff up for good: > > - This API will log in a different file then wtmp/utmp/lastlog. > > - A program is free to use the API or not, though it is encouraged too > > (and basically the author of the program would be kinda stupid not to :) > > - API using programs can only "write" to the new API camouflaged system > > (be it a SQL database, a flat file whatever, the app won't see it). > > - The "old" utmp/wtmp/lastlog is wrapped in the API whenever something > > is queried... so... API using programs query for the last accounts used > > for logging in... > > The API then sees "hey we still use the old utmp/wtmp/lastlog stuff" > > and reads entries from there in addition to from it's own db/file > > whatever. > > > > The API should simply eat strings of undefined length or spit strings > > with predefined buffer lengths: > > > > Putlastlog(char *accountname, char *hostaddress, int af_type); > > Getlastlog(char *accountname, char *hostaddress, int *af_type, int > > acct_len, int host_len); > > > > Tada all problems solved.... And we could get more evil to have a small > > program in cron or something merge the "old" utmp/wtmp/lastlog stuff > > into the new API enabled form. > > And throw away the old entries. This could be done verywell as there are > > only a few programs 'relying' on reading from the files (eg w/who :). > > > > Another nice thing to do would be to make the API convinient to be used > > on other platforms, thus make a "old wrapper only" version which writes > > directly into utmp/wtmp/lastlog. > > This way programmers of the client apps are easier to be encouraged to > > use it, as they can simply use the wrapper on platforms which don't have > > the real API backend we want to have. > > > > Wrap the wrappers and make it all happy for yourself :) > > > > Greets, > > Jeroen > > > > > > ----------- > Peter C. Lai > University of Connecticut > Dept. of Residential Life | Programmer > Dept. of Molecular and Cell Biology | > Undergraduate Research Assistant/Honors Program > http://cowbert.2y.net/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jul 26 15: 1:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 89EC237B405; Thu, 26 Jul 2001 15:01:18 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id AAA47576; Fri, 27 Jul 2001 00:01:16 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Mike Smith Cc: arch@freebsd.org Subject: Re: moving struct module out of kern_module.c References: <200107222019.f6MKJBI01159@mass.dis.org> From: Dag-Erling Smorgrav Date: 27 Jul 2001 00:01:16 +0200 In-Reply-To: <200107222019.f6MKJBI01159@mass.dis.org> Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Smith writes: > > Currently, struct module is defined in kern_module.c and opaque to the > > rest of the kernel. I'd like to move the definition out into module.h > > so linprocfs can access it. Any objections? > Why? I wanted to implement proc/modules and proc/syms, but right now I'm not sure they're meaningful at all (and I don't know of anything that requires them), so never mind. If it comes up again I'll write accessor functions. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 27 5:30:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id 7798837B403 for ; Fri, 27 Jul 2001 05:30:21 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id OAA52708; Fri, 27 Jul 2001 14:30:10 +0200 (CEST) (envelope-from assar) To: Mike Heffner Cc: arch@FreeBSD.ORG Subject: Re: Making glob(3) portable (was Re: Importing lukemftpd) References: From: Assar Westerlund Date: 27 Jul 2001 14:30:10 +0200 In-Reply-To: Mike Heffner's message of "Wed, 25 Jul 2001 22:45:18 -0400 (EDT)" Message-ID: <5lr8v2mu5p.fsf@assaris.sics.se> Lines: 17 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Heffner writes: > On 25-Jul-2001 Assar Westerlund wrote: > | Mike Heffner writes: > | > |> IMO, removing GLOB_LIMITHIT, or whatever, and just using GLOB_NOSPACE with > |> errno=0 would be the first step in the direction of portability. > | > | Sure, we can do that. > > How's the following patch look: Ok, except I don't really like this errno part. I think it's bad using errno as a substitute for different error codes from glob() and it's not really going to be portable either, is it? Does the others set errno = 0 if the limit is reached? /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 27 10:16: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [206.40.252.115]) by hub.freebsd.org (Postfix) with ESMTP id 96EDA37B403 for ; Fri, 27 Jul 2001 10:16:06 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f6RHFYo44335; Fri, 27 Jul 2001 10:15:34 -0700 (PDT) (envelope-from obrien) Date: Fri, 27 Jul 2001 10:15:29 -0700 From: "David O'Brien" To: Kris Kennaway Cc: arch@FreeBSD.org Subject: Re: Nuking all malloc wrappers (Re: cvs commit: src/usr.bin/nm nm.c) Message-ID: <20010727101529.B43542@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <200107241408.f6OE83j65583@freefall.freebsd.org> <20010724130418.A34051@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010724130418.A34051@xor.obsecurity.org>; from kris@obsecurity.org on Tue, Jul 24, 2001 at 01:04:18PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jul 24, 2001 at 01:04:18PM -0700, Kris Kennaway wrote: > I don't understand why you're doing this. Increasing code duplication > by expanding out a local function seems like a pessimization to me. Check the diffs. Two programs wrote "emalloc" as: void * emalloc(size_t s) { void * p; if ((p = malloc(s)) == NULL) errx(1, NULL); bzero(p, s); (or memset(p, 0, s)) return p; } ie, they rolled their own calloc(). That is a pestimazation as your libc may easily have a platform-specific optimized one. And the name emalloc implies malloc, not calloc semantics. So it is misleading to the reader. Which leads to the issue of someone not knowing emalloc is used in a particular program (or estrdup), so they use straight malloc or strdup -- breaking coherence w/in the program. (yes I found cases of this) Another case of "optimized" wrapper was the realloc one that didn't trust that our libc was ANSI compliant, so it tested `p' for NULL and called malloc if it was, else it went ahead and called realloc. Since ANSI says that is exactly how realloc must function, effectively we were testing for a NULL `p' twice. Again in this case, my change wasn't a pessimization. But rather it lead to easier to read and audit code. Also, in all but the xlint case, I there were only a hand full of "emalloc" uses. So they were only saving a hand full of testing malloc's return value, while adding the code overhead of another function call. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 27 10:20:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [206.40.252.115]) by hub.freebsd.org (Postfix) with ESMTP id 582D137B406 for ; Fri, 27 Jul 2001 10:20:33 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f6RHJxQ44354; Fri, 27 Jul 2001 10:19:59 -0700 (PDT) (envelope-from obrien) Date: Fri, 27 Jul 2001 10:19:54 -0700 From: "David O'Brien" To: Kris Kennaway Cc: Mike Heffner , arch@FreeBSD.ORG Subject: Re: Importing lukemftpd Message-ID: <20010727101954.C43542@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010717103604.B79329@xor.obsecurity.org> <20010719112221.A84356@dragon.nuxi.com> <20010719123015.A44746@xor.obsecurity.org> <20010719203700.B94074@dragon.nuxi.com> <20010719210332.A78418@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010719210332.A78418@xor.obsecurity.org>; from kris@obsecurity.org on Thu, Jul 19, 2001 at 09:03:33PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jul 19, 2001 at 09:03:33PM -0700, Kris Kennaway wrote: > You and John are being paid to work full-time on FreeBSD, and the > projects you mentioned are projects you do during your >8 hours a day > of paid FreeBSD hacking time. If you were working on these in your > own time, say from 10pm at night after a hard day at work, When we work >8 hours a day, we *are* working on XYZ in our own time. :-) > Auditing of a non-trivial application is time-consuming and difficult. > The kinds of bugs I expect might be found in something like ftpd are > not the trivial ones involving misuse of sprintf(), It would still be nice to see even this type/level of auditing of LukeM ftpd. > but the deeply > embedded ones which rely on interactions between several different > parts of the code. That requires someone to sit down for a week and > really become intimate with the code, which isn't something that most > people can do in their spare time for an hour or two here and there > (which is why no-one's done this so far). Who do you trust to do this review? Me? Anybody? Only members of the S.O. team? Any of the typical contributors to -audit? Surely given your stance on this issue, just anyone coming forward saying they've "audited" the code will appease you. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 27 11:45: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 175B937B401 for ; Fri, 27 Jul 2001 11:45:03 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f6RIj2g21259 for arch@freebsd.org; Fri, 27 Jul 2001 11:45:02 -0700 Date: Fri, 27 Jul 2001 11:45:02 -0700 From: Brooks Davis To: arch@freebsd.org Subject: Where to put include files? Message-ID: <20010727114502.A20206@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable While testing some the ancontrol fixes I just committed on beast, I ran into on of the side effects of the evil -I${CURDIR}/../../sys mess which is that you have to edit the makefile to build ancontrol outside a tree. The answer is of course to install the problem header file if_aironet_ieee.h in an appropriate place in /usr/include, but where. Last time this came up, brian suggested /usr/include/sys and did that with digiio.h but I can't seem to find a concensus in the archives. Was one reached and if so, what was it? -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7YbatXY6L6fI4GtQRAjY0AKCaobYd+0XLYHzugpJV2ka+SOiQpACggERR aJg58frmdgczCnvIf67JRXY= =m7NK -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 27 12: 2:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 8EF9A37B401 for ; Fri, 27 Jul 2001 12:02:43 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6RJ2fr25316; Fri, 27 Jul 2001 20:02:42 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6RJ2fc12569; Fri, 27 Jul 2001 20:02:41 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200107271902.f6RJ2fc12569@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Brooks Davis Cc: arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Where to put include files? In-Reply-To: Message from Brooks Davis of "Fri, 27 Jul 2001 11:45:02 PDT." <20010727114502.A20206@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jul 2001 20:02:41 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > While testing some the ancontrol fixes I just committed on beast, I ran > into on of the side effects of the evil -I${CURDIR}/../../sys mess which > is that you have to edit the makefile to build ancontrol outside a tree. > The answer is of course to install the problem header file > if_aironet_ieee.h in an appropriate place in /usr/include, but where. > Last time this came up, brian suggested /usr/include/sys and did that > with digiio.h but I can't seem to find a concensus in the archives. Was > one reached and if so, what was it? I think the concensus was that ``it depends''. I'd tend to suggest renaming /sys/dev/an/if_aironet_ieee.h to /sys/sys/anio.h. > -- Brooks -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 27 12: 7:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-169-104-149.dsl.lsan03.pacbell.net [64.169.104.149]) by hub.freebsd.org (Postfix) with ESMTP id 81CFC37B401; Fri, 27 Jul 2001 12:07:55 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id AED3166B25; Fri, 27 Jul 2001 12:07:54 -0700 (PDT) Date: Fri, 27 Jul 2001 12:07:54 -0700 From: Kris Kennaway To: David O'Brien Cc: Kris Kennaway , Mike Heffner , arch@FreeBSD.ORG Subject: Re: Importing lukemftpd Message-ID: <20010727120754.B34272@xor.obsecurity.org> References: <20010717103604.B79329@xor.obsecurity.org> <20010719112221.A84356@dragon.nuxi.com> <20010719123015.A44746@xor.obsecurity.org> <20010719203700.B94074@dragon.nuxi.com> <20010719210332.A78418@xor.obsecurity.org> <20010727101954.C43542@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="24zk1gE8NUlDmwG9" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010727101954.C43542@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Fri, Jul 27, 2001 at 10:19:54AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --24zk1gE8NUlDmwG9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 27, 2001 at 10:19:54AM -0700, David O'Brien wrote: > On Thu, Jul 19, 2001 at 09:03:33PM -0700, Kris Kennaway wrote: > > You and John are being paid to work full-time on FreeBSD, and the > > projects you mentioned are projects you do during your >8 hours a day > > of paid FreeBSD hacking time. If you were working on these in your > > own time, say from 10pm at night after a hard day at work, >=20 > When we work >8 hours a day, we *are* working on XYZ in our own time. :-) And the project thanks you for it ;-) > > but the deeply > > embedded ones which rely on interactions between several different > > parts of the code. That requires someone to sit down for a week and > > really become intimate with the code, which isn't something that most > > people can do in their spare time for an hour or two here and there > > (which is why no-one's done this so far). >=20 > Who do you trust to do this review? Me? Anybody? Only members of the > S.O. team? Any of the typical contributors to -audit? Surely given your > stance on this issue, just anyone coming forward saying they've > "audited" the code will appease you. I'd want to be convinced that a thorough job has been spent looking for problems -- ultimately it comes down to someone I trust saying "I've gone through the code thoroughly and didn't find any more problems". A good indicator of this will probably be patches fixing problems in the code discovered during the audit :-) Kris --24zk1gE8NUlDmwG9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7YbwJWry0BWjoQKURAuqkAJsFx0yjixhEG1jEswsJfdRQHmMPBwCeIpKp U+lnAAoE+L4/Tw8o7oMQ21A= =4dls -----END PGP SIGNATURE----- --24zk1gE8NUlDmwG9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 27 17:51: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 76D8237B401 for ; Fri, 27 Jul 2001 17:50:59 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f6S0oxM60308 for ; Fri, 27 Jul 2001 17:50:59 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 3CE73380B; Fri, 27 Jul 2001 17:50:59 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Brian Somers Cc: Brooks Davis , arch@FreeBSD.ORG Subject: Re: Where to put include files? In-Reply-To: <200107271902.f6RJ2fc12569@hak.lan.Awfulhak.org> Date: Fri, 27 Jul 2001 17:50:58 -0700 From: Peter Wemm Message-Id: <20010728005059.3CE73380B@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Brian Somers wrote: > > While testing some the ancontrol fixes I just committed on beast, I ran > > into on of the side effects of the evil -I${CURDIR}/../../sys mess which > > is that you have to edit the makefile to build ancontrol outside a tree. > > The answer is of course to install the problem header file > > if_aironet_ieee.h in an appropriate place in /usr/include, but where. > > Last time this came up, brian suggested /usr/include/sys and did that > > with digiio.h but I can't seem to find a concensus in the archives. Was > > one reached and if so, what was it? > > I think the concensus was that ``it depends''. > > I'd tend to suggest renaming /sys/dev/an/if_aironet_ieee.h to > /sys/sys/anio.h. The other option is /usr/include/dev/an/if_aironet_ieee.h. We already have the infrastructure to install this. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 27 19:28:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from iatl0x01.coxmail.com (iatl0x02.coxmail.com [206.157.225.11]) by hub.freebsd.org (Postfix) with ESMTP id 52F9137B401; Fri, 27 Jul 2001 19:28:23 -0700 (PDT) (envelope-from mheffner@novacoxmail.com) Received: from enterprise.muriel.penguinpowered.com ([209.249.198.96]) by iatl0x01.coxmail.com (InterMail vK.4.03.02.00 201-232-124 license eaa2928f5bcba31507d4d280f1027278) with ESMTP id <20010728022822.LOR20831.iatl0x01@enterprise.muriel.penguinpowered.com>; Fri, 27 Jul 2001 22:28:22 -0400 Message-ID: X-Mailer: XFMail 1.5.0 on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.5.0.FreeBSD:20010727222547:354=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <5lr8v2mu5p.fsf@assaris.sics.se> Date: Fri, 27 Jul 2001 22:25:47 -0400 (EDT) Reply-To: Mike Heffner From: Mike Heffner To: Assar Westerlund Subject: Re: Making glob(3) portable (was Re: Importing lukemftpd) Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.5.0.FreeBSD:20010727222547:354=_ Content-Type: text/plain; charset=us-ascii On 27-Jul-2001 Assar Westerlund wrote: | | Ok, except I don't really like this errno part. I think it's bad | using errno as a substitute for different error codes from glob() and | it's not really going to be portable either, is it? Does the others | set errno = 0 if the limit is reached? I don't really like it too much either, but this is what NetBSD and OpenBSD use so it's purely for compatibility reasons. Mike -- Mike Heffner Fredericksburg, VA --_=XFMail.1.5.0.FreeBSD:20010727222547:354=_ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7YiKqFokZQs3sv5kRAmLSAJoCJ+lQ3A6gKbzohw97GS40TFQPSgCdFqrP jXYoYTKkogskzhpSKGAUl60= =7wmx -----END PGP SIGNATURE----- --_=XFMail.1.5.0.FreeBSD:20010727222547:354=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 27 20:38:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by hub.freebsd.org (Postfix) with ESMTP id 945DB37B401 for ; Fri, 27 Jul 2001 20:38:08 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.11.3/8.11.3) id f6S3aW529051; Fri, 27 Jul 2001 20:36:32 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200107280336.f6S3aW529051@ambrisko.com> Subject: Re: Where to put include files? In-Reply-To: <20010728005059.3CE73380B@overcee.netplex.com.au> "from Peter Wemm at Jul 27, 2001 05:50:58 pm" To: Peter Wemm Date: Fri, 27 Jul 2001 20:36:32 -0700 (PDT) Cc: Brian Somers , Brooks Davis , arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm writes: | Brian Somers wrote: | > > While testing some the ancontrol fixes I just committed on beast, I ran | > > into on of the side effects of the evil -I${CURDIR}/../../sys mess which | > > is that you have to edit the makefile to build ancontrol outside a tree. | > > The answer is of course to install the problem header file | > > if_aironet_ieee.h in an appropriate place in /usr/include, but where. | > > Last time this came up, brian suggested /usr/include/sys and did that | > > with digiio.h but I can't seem to find a concensus in the archives. Was | > > one reached and if so, what was it? | > | > I think the concensus was that ``it depends''. | > | > I'd tend to suggest renaming /sys/dev/an/if_aironet_ieee.h to | > /sys/sys/anio.h. | | The other option is /usr/include/dev/an/if_aironet_ieee.h. We already have | the infrastructure to install this. That probably make the most sense since I see that's been done for the wavelan driver in -current. Initially I was only looking in -stable in which only usb & ppbus was there. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 28 4:26:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mydomain.com (t3o102p2.telia.com [194.255.255.2]) by hub.freebsd.org (Postfix) with ESMTP id 5D5FA37B406; Sat, 28 Jul 2001 04:26:10 -0700 (PDT) (envelope-from world1web@www.com) Date: Sat, 28 Jul 2001 13:26:07 +0100 From: WORLD1-WEB To: WORLD1-WEB@FreeBSD.ORG Subject: INCREDIBLE .. WORLDS NO.1 !! Message-Id: <20010728112610.5D5FA37B406@hub.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ladies & Gentlemen, Are you ready to the experience of a lifetime ? As affiliates of the CIL group, we offer you to PLUGIN to the largest SEX-SERVER on the WEB, in order to get more than 3000 MegaBytes of the best and most sensational SEX on the entire Web! Why on earth do you think that thousands of people from 13 countries daily choose to visit 2 particular WebSites ? Very EASY answer! - The largest and most incredible content of LIVE SEX is offered! - State-of-the-art LIVE SHOWS with the wildest and most horny amateurs and pornstars in the world! - Hardcore LIVE SEX that hasnīt crossed your imagination! - Incredible & amazing themes from soft sex to the most bizarre sex! - Beautiful Girls & wild studs from almost every country, allowing you to watch, see & chat with awsome amateurs & pornstars who are blond, who are black, who are Scandinavian, who are Asian, who have BIG tits, who are shaved, who are pregnant who are .... you just name it ! - The best ever made SPY-CAMS, WATCH-CAMS, POOL-CAMS, SHOWER-CAMS, AMATEUR-CAMS ... etc! - Several high quality Interactive Cams & LIVE SEX Chat, where you are in controle ! - Much much more ... too much to mention ! EVERYTHING is offered 100% ANONOMOUSLY & you donīt need to sign-up or have a creditcard ... How simple is that ? PLUGIN now to our MEGA SEX-SERVER through any of the 2 AwardWinning Sites listed below, and get instantly access to more than 3000 MegaBytes of State-of-the-art WebSex! RIGHT HERE AT: http://siam.to/sexywebtv (This Site just has EVERYTHING you can imagine) ... If this Site does not open properly ... please try http://cyberu.to/hotweb Or this one, if you just love true LESBIAN SEX, CHAT and MORE from Sunny Ibiza in Spain: http://siam.to/sexybabestv ... If this Site does not open properly ... please try http://cyberu.to/hotbabes Enjoy your trip to paradise! VERY IMPORTANT HINT: To get DIRECT ACCESS to the webpages in the future, ALLWAYS keep the DIALER on your desktop or elsewhere on your PC ... Its easy, small and 100% harmless. Yours sincerely, WORLD1-WEB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message