Date: Fri, 29 Aug 2003 20:31:18 -0700 From: Lev Walkin <vlm@netli.com> To: zera holladay <zera_holladay@yahoo.com> Cc: hackers@freebsd.org Subject: Re: Shared memory question Message-ID: <3F501A86.4010805@netli.com> In-Reply-To: <20030830025645.37066.qmail@web41408.mail.yahoo.com> References: <20030830025645.37066.qmail@web41408.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F501A86.4010805>