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
[EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
