It was our last best hope for peace...

[Ray Dillinger]

On Wed, 7 Oct 1998, Kragen wrote:

>Looks like pointer security etc. in hardware is dead for a while,
>again.
>
>I suspect that pointer security in general will make a comeback,
>though.  

I've been investigating operating systems lately, and pointer
security is, to say the least, an interesting problem.  UNIX and
its kin (windows, etc) handle the problem by having each
"Process" use a different mapping of physical memory to
addresses.  Within each "Process", there can be numerous
"Threads", which are autonomous flows of control which all use
the same mapping of memory to addresses.  

Most of UNIX's (and some other OS's) security, such as it is, is
based on the idea that *UNLESS* a process is running in kernel
mode, or with suitable priveleges provided by the kernel, the
physical locations of the ports representing access to raw
hardware are not available in its memory mapping, and that no 
two arbitrarily chosen processes have no physical memory
locations in common available to them.  

The cost of switching the address-to-memory mappings in such
systems imposes a high penalty on context switching between
processes, while context switching between threads is easy.  
There is hardware available (MMU's) that automate some of the
functions, but even so, it's still the worst part of the 
context switch. 

In other systems, like the BeOS, there is exactly ONE mapping of
physical memory to addresses, and every process uses it.  Thus,
different processes are implemented as what in UNIX would be
called different threads.  This makes context switching a lot
easier, allows much finer-grained parallelism, gets more use out
of multiple processors, and a bunch of other nice things.  But 
in such an operating system, how do you keep a buggy program
from writing a random value into the middle of another's data
(or code!!) causing crashes?  


			Bear