From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Thu, 30 Jul 2009 17:01:04 +0200 From: cinap_lenrek@gmx.de In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-xbhefkoukcsuscsdzetzqqtovq" Subject: Re: [9fans] Race condition in /sys/src/9/pc/trap.c? Topicbox-Message-UUID: 323a41f6-ead5-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-xbhefkoukcsuscsdzetzqqtovq Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit hm... what about the other stuff port/sysfile.c? they also just checks pointers with validaddr and then call into the device handler without locking anything / holding anything. -- cinap --upas-xbhefkoukcsuscsdzetzqqtovq Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-bounces+cinap_lenrek=gmx.de@9fans.net> X-Flags: 0000 Delivered-To: GMX delivery to cinap_lenrek@gmx.de Received: (qmail invoked by alias); 30 Jul 2009 14:42:36 -0000 Received: from gouda.swtch.com (EHLO gouda.swtch.com) [67.207.142.3] by mx0.gmx.net (mx096) with SMTP; 30 Jul 2009 16:42:36 +0200 Received: from localhost ([127.0.0.1] helo=gouda.swtch.com) by gouda.swtch.com with esmtp (Exim 4.69) (envelope-from <9fans-bounces@9fans.net>) id 1MWWlW-0003c5-BT; Thu, 30 Jul 2009 14:37:54 +0000 Received: from [195.207.5.2] (helo=plan9.cs.bell-labs.com) by gouda.swtch.com with esmtp (Exim 4.69) (envelope-from ) id 1MWWlU-0003c0-7a for 9fans@9fans.net; Thu, 30 Jul 2009 14:37:52 +0000 To: 9fans@9fans.net Date: Thu, 30 Jul 2009 16:37:50 +0200 From: Sape Mullender Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: geoff@plan9.bell-labs.com, jmk@plan9.bell-labs.com Subject: Re: [9fans] Race condition in /sys/src/9/pc/trap.c? X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.10 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces@9fans.net Errors-To: 9fans-bounces+cinap_lenrek=gmx.de@9fans.net X-GMX-Antivirus: 0 (no virus found) X-GMX-Antispam: 0 (Mail was not recognized as spam) X-GMX-UID: b8tEIvdsZDI4apF02WY29oNxemhmYwHB > On Thu, 30 Jul 2009, erik quanstrom wrote: > >> On Thu Jul 30 00:05:45 EDT 2009, elly1@andrew.cmu.edu wrote: >>> My familiarity with the kernel source code is superficial to say the >>> least, but it seems to me that this code (from /sys/src/9/pc/trap.c) >>> contains a race condition: >>> >>> 702 if(sp<(USTKTOP-BY2PG) || sp>(USTKTOP-sizeof(Sargs)-BY2WD)) >>> 703 validaddr(sp, sizeof(Sargs)+BY2WD, 0); >>> 704 >>> 705 up->s = *((Sargs*)(sp+BY2WD)); >>> >>> We verify that the address is correct; is there any reason another thread >>> in the same address space cannot start running after line 703 completes >>> and unmap that memory, causing us to access unmapped memory at line 705? >>> The system call entry is itself an interrupt gate, but line 689 is >>> spllo(), and we appear to hold no locks at this point. >> >> plan 9 threads are cooperatively scheduled. so >> the correct term is proc. but you are correct, >> another proc sharing memory with this one >> could be running. however, that proc would >> not have access to this proc's stack. (rfork >> doesn't allow shared stack.) and even if it >> did, plan 9 stacks don't shrink. > > What if sp points inside a segment which is not the actual stack segment? > Then could someone else come along and segdetach() it in between the two > mentioned lines? > >> let's suppose that the address is invalid later. >> the kernel always moves data to/from user >> buffers outside of any locks because even >> valid targets may be paged out. if the address >> is truely invalid, waserror() will be true and >> the else branch starting at 714 will be executed >> >> - erik > > -- Elly I think you may be right, Elly. Multithreaded programs indeed have their stack running outside the stack segment, so this could happen there. splhi won't even do on a multiprocessor. One should probably lock down the segment. We've never seen this happen, of course — or rather, we haven't noticed this as the cause of a crash. Sape --upas-xbhefkoukcsuscsdzetzqqtovq--