From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 15 01:05:10 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE71F37B401 for ; Tue, 15 Jul 2003 01:05:10 -0700 (PDT) Received: from HAL9000.homeunix.com (ip114.bella-vista.sfo.interquest.net [66.199.86.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0957343F3F for ; Tue, 15 Jul 2003 01:05:10 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h6F854Lv034689; Tue, 15 Jul 2003 01:05:04 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h6F851GO034688; Tue, 15 Jul 2003 01:05:01 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 15 Jul 2003 01:05:01 -0700 From: David Schultz To: Pawel Jakub Dawidek Message-ID: <20030715080501.GA34504@HAL9000.homeunix.com> Mail-Followup-To: Pawel Jakub Dawidek , "Alan L. Cox" , freebsd-hackers@freebsd.org References: <20030712202216.GG4973@garage.freebsd.pl> <3F10762E.D17A7307@imimic.com> <20030712213249.GJ4973@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030712213249.GJ4973@garage.freebsd.pl> cc: "Alan L. Cox" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Bug in VM pages protection handling. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2003 08:05:11 -0000 On Sat, Jul 12, 2003, Pawel Jakub Dawidek wrote: > On Sat, Jul 12, 2003 at 03:57:18PM -0500, Alan L. Cox wrote: > +> > I've just send PR for this: > +> > > +> > http://www.freebsd.org/cgi/query-pr.cgi?pr=54418 > +> > > +> > I'll be greatful if somebody could review, commit and MFC it > +> > as soon as possible. I need to hold CerbNG next release until > +> > it will be fixed. > +> > > +> > +> As I've said in private e-mail, this is not a bug. You're really asking > +> for a change in "specification". Reductions in max_protection have had > +> permanent effect since the late 1980's. > > You've also asked my in private mail why I need this, I'll answer here. > > I need this to protect syscall arguments that I'm checking in CerbNG. > If I need to check an argument I've to be sure that kernel will check > exactly that same argument (here is ugly race). > So what I do is memory allocaton in process' vmspace, copy argument > there, mark newly allocated pages as read-only and call original > syscall with new pointer(s). Those pages are freed after that and > everything will be correct, but somebody has reported me about > 'bus error'. I've track this problem for two days. It occurs for > majordomo, when perl is trying to execute something, nevermind. > Pages are marked as read-only for child process, but parent > process is killed with SIGBUS signal. I don't mees with this parent > process at all, but it looks they're sharing some memory or some > pages/map is mirrored (copy-on-write mechanism?) with VM_PROT_READ > protection. So let me see if I've got the sequence of events straight: 1) The process forks 2) The child makes a system call that results in the creation of a new read-only map entry. 3) The parent calls mmap() (for example) to create a read-write map entry with the same virtual address. 4) Somehow the parent's permissions end up being read-only, not read-write, and the parent dies. Is this correct? If so, this doesn't sound like a problem with vm_map_protect(), but rather with your handling of map entry sharing. My first inclination, as a non-expert, would be that you're not taking MAP_ENTRY_NEEDS_COPY into account. This is an optimization that allows two processes to share map entries until a COW fault is taken in one of them. This speeds up fork(2) greatly because VM objects are not allocated unnecessarily.