From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 29 20:31:02 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 6960816A4BF for ; Fri, 29 Aug 2003 20:31:02 -0700 (PDT) Received: from smtp.netli.com (ip2-pal-focal.netli.com [66.243.52.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85A8C44003 for ; Fri, 29 Aug 2003 20:31:01 -0700 (PDT) (envelope-from vlm@netli.com) Received: (qmail 12326 invoked by uid 84); 30 Aug 2003 03:31:01 -0000 Received: from vlm@netli.com by l3-1 with qmail-scanner-0.96 (uvscan: v4.1.40/v4121. . Clean. Processed in 0.152333 secs); 30 Aug 2003 03:31:01 -0000 Received: from unknown (HELO netli.com) (172.17.1.12) by mx01-pal-lan.netli.lan with SMTP; 30 Aug 2003 03:31:00 -0000 Message-ID: <3F501A86.4010805@netli.com> Date: Fri, 29 Aug 2003 20:31:18 -0700 From: Lev Walkin Organization: Netli, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030820 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: zera holladay References: <20030830025645.37066.qmail@web41408.mail.yahoo.com> In-Reply-To: <20030830025645.37066.qmail@web41408.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org Subject: Re: Shared memory question 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: Sat, 30 Aug 2003 03:31:02 -0000 zera holladay wrote: > When one uses the term "shared memory" while > discussing Unix, then what is generally the meaning of > that term? I have read that some Unixes have "shared > memory" for "shared objects." > > However, I believe the term "shared memory" more > generically refers to user space as opposed to kernel > space? Further, the kernel should allocate and > deallocate memory for user space as requested so as > not to crash the system. If this is correct, then it > is very unlikely that a program running in user space > will ever crash a properly configured unix system? Shared memory is just a chunk of memory which may be created by one program and attached to (by) many other programs. Yes, the management (allocation and deallocation) of shared memory chunks are done in kernel. User space applications have to use shmget(2), shmat(2), shmdt(2) system calls to obtain, attach and release the chunk of shared memory. When the memory is attached by several processes, the pages of memory are physically the same, so any change made by one of the participating programs immediately becomes visible by others. If user space program crashes, kernel detaches the shared memory from this particular program, but it still remains available for any other program that is using this shared memory segment. The problem lies in the different space: if the the program has high privileges and does not properly handle shared memory permissions, than it is possible for some other program to maliciously modify the data in that shared memory segment to somehow affect program's behavior, up to executing arbitrary programs with enhanced privileges, and so on. So, it is possible that some damage to the system can be done through exploiting unsafely coded process with too much privileges, which could result in a crash of a properly configured unix system. "Shared objects", most certainly, were used to refer to shared libraries (roughly corresponding to .DLL files in Windows). If many programs use the same shared libraries, than it is wise to share their code to not to waste [virtual] memory. To solve this problem, certain regions of library code is mapped into the memory and shared between many applications. Of course in this case permissions are set appropriately to not to allow arbitrary program to change the shared portion of the library (alternatively, any change will result in a copy-on-write, and only the program itsel will see the changed portion). > Thank you for your patience. > > Zera -- Lev Walkin vlm@netli.com