From owner-freebsd-arch@FreeBSD.ORG Thu Apr 15 04:08:37 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FB7116A4CE for ; Thu, 15 Apr 2004 04:08:37 -0700 (PDT) Received: from srv01.sparkit.no (srv01.sparkit.no [193.69.116.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id C632843D4C for ; Thu, 15 Apr 2004 04:08:36 -0700 (PDT) (envelope-from eivind@FreeBSD.org) Received: from ws ([193.69.114.88]) by srv01.sparkit.no (8.12.10/8.12.10) with ESMTP id i3FB8XcZ006299; Thu, 15 Apr 2004 13:08:33 +0200 (CEST) (envelope-from eivind@FreeBSD.org) Received: from ws (localhost [127.0.0.1]) by ws (8.12.9/8.12.10) with ESMTP id i3FB7OY8001682; Thu, 15 Apr 2004 11:07:24 GMT (envelope-from eivind@ws) Received: (from eivind@localhost) by ws (8.12.9/8.12.10/Submit) id i3FB7OeG001680; Thu, 15 Apr 2004 11:07:24 GMT (envelope-from eivind) Date: Thu, 15 Apr 2004 11:06:22 +0000 From: Eivind Eklund To: "Devon H. O'Dell" Message-ID: <20040415110622.GA1370@FreeBSD.org> References: <407CF5B8.2060909@sitetronics.com> <20040414112800.GA69649@stack.nl> <407D25A7.8090502@sitetronics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <407D25A7.8090502@sitetronics.com> User-Agent: Mutt/1.5.4i cc: Jilles Tjoelker cc: freebsd-arch@FreeBSD.org Subject: Re: [patch] lockf(3) user-exploitable kernel panic X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 11:08:37 -0000 On Wed, Apr 14, 2004 at 01:51:03PM +0200, Devon H. O'Dell wrote: > Jilles Tjoelker wrote: > >e) add a line 'struct proc;' to sys/ucred.h > > Thanks for this suggestion; I wasn't aware that this was reasonably > possible from an architectural standpoint. Most of the sys/* files are really owned by the implementation, and it is usually OK to introduce forward declarations into them. We try to avoid namespace poisoning (introducing unknown variables) for the official files, but that also happens sometimes. Also, many of the files (including sys/ucred.h) has an #ifdef _KERNEL section. This section is totally owned by the implementation, and it is (almost) always OK to add forward declarations. The list of official sys/ includes can be fetched at http://www.opengroup.org/onlinepubs/007904975/basedefs/sys/ > >>3) Does this work justify my going through the modified files and doing > >>style(9) changes on them? I'm willing to do this; mux@ has encouraged > >>it; style(9) suggests that I do it if my code comprises 50% or more of > >>the new files (which it doesn't). Again, if this is useful, I'll > >>certainly do this. > > > >Some of the files have a mixture of K&R-style and ANSI function > >definitions. > > I'll look into implementing style(9) changes then. I know my patch fails > a style(9) check in some contexts, so I'll go a general cleanup as well. Please do that separately from the main patch. We try quite hard to not mix stylistic and functional changes in a single patch, to make it easy to use the version history (and easy for people to review the patches). > sh has been fixed. I was under the impression that csh used libutil for > this (libutil has been fixed). I'll take a deeper look into shells in > base and in ports and figure out what changes I need to make there. > While I'm at it, I don't think it'd be a bad idea to go ahead and build > in the RLIMIT_SBSIZE to bash and bash2. If it is easy, it might be worthwhile to patch the shells to use libutil and submit those patches back to the maintainers. > >Limiting the number of locked regions is not uncommon, e.g. Solaris does > >it (the manpage seems to indicate a per-system limitation only, though). > > > >Interesting part from Linux getrlimit(2) manpage: > > RLIMIT_LOCKS > > A limit on the combined number of flock() locks and > > fcntl() > > leases that this process may establish (Linux 2.4 and later). > > > >Per-user instead of per-process limits are harder to implement but > >more effective. > > Ok. I was not aware that Linux had this fix / feature already. I'll take > a look into the CVS repos of the other BSDs and see if it's something I > can suggest a patch for in those worlds. It'd be nice to be compatible with Linux here, as it means just a define is needed for making apps work with it on FreeBSD (it may even automatically happen due to configure scripts.) Eivind.