Okay guys, you've caught me in my old-timer self. All 'nix pointers are
offsets from a set of base registers set by the operating system when
the program loads. In the old 8086 architecture, these base registers
were the CS, DS, SS, and ES for control segment, data segment, stack
segment and extra segment. When the operating system switched contexts
(started running another program) it would push the registers out on a
stack and pop them off to return, aided by push and pop hardware
instructions. On that architecture, in particular, segments overlapped
and offsets could easily address another segment. Heck, we had processes
updating the graphics memory with application data. An application
program could also change the segment registers which really made it
interesting. Intel processors since the 80386 have isolated segments and
provided more features the operating system can use to limit a program's
ability to affect segment registers and memory outside it's assigned
space. There are still opportunities for a program to come up with an
address (base + offset) outside the space the operating system has
allocated for it. A 32 bit offset gives you lots rope to hang yourself.
Try calling a function with a lot of local variables recursively and
infinitely on 'nix. On some, it will just run out of space on the stack
and throw an error. On others, it will start clobbering the operating
system and drivers (even though the definition of a job (or process) on
'nix is a unique stack). It depends a lot on the flavor of 'nix and the
processor running it. Newer stuff has better isolation. All the new
hardware and OS software is doing virtual memory translation on most
user process space. That layer of abstraction allows the OS to assign a
2**32 byte virtual space to each 32 bit offset register (or 64 for 64
bit machines); in that case, it would be impossible to run the offset
outside the assigned space.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, August 26, 2008 4:12 PM
To: Midrange Systems Technical Discussion
Subject: Re: What should I say to a *nix community?
In 'nix, you can easily do that. For 'nix, all pointers are offsets
from some base register set by the operating system. For i all
pointers are absolute pointers into virtual memory; those pointers are
also capabilities which limit the offsets that can be derived from
that pointer. For i, you can't run off the end of the memory space
allocated for the job or by any ALLOC/MALOC type operation.
In the Unixes I've worked in, each process has it's own address space.
Thus, if one process is pointing to address 12345 and another process is
also pointing to 12345, there's no conflict -- they're referring to
different places in memory, because each process has it's own address
space.
If, somehow (usually due to memory corruption) you end up with an offset
the goes outside of what's been allocated to your address space, you end
up with a SIGSEGV (segmentation violation).
The only way to get memory that's shared across processes is to
specifically ask the kernel for a shared memory segment by calling the
appropriate API.
By contrast, on i, there's only one address space for everything
(including both disk and memory) across all jobs.
So, it's actually HARDER for one process to interfere with another's
memory in the Unixes I've worked in. Granted, there are many, many
different flavors of Unix, and they're all different.
However, a pointer on i (provided we're talking about traditional SLS
pointers, not teraspace) is much different from on other platforms. It's
more like a data structure containing various bits of information.
Space pointers contain both the space they point to, and the offset
within that space. When you add/subtract from the address, you only
modify the offset, you don't modify the space. Therefore, you can never
use addition/subtraction on a pointer to access a different space.
Also, different types of pointers are used to execute program code vs.
modify memory. That makes it difficult (although, not impossible -- at
least, it's still possible in V5R3) to modify code in memory and then
execute it.
By contrast, Unix uses the same sort of pointer (which is just an
offset) for both code and data -- so you can potentially add/subtract
from a data field to get into the executable code's memory, and them
modify it... A common source of security holes.
So there are pros and cons -- but the worst model is that of Windows. I
strongly recommend that you avoid Windows at any cost.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
