[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Message passing in user-land

From: David Walter
Subject: Re: Message passing in user-land
Date: Mon, 15 Jul 2002 13:29:03 -0400
User-agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Common Lisp, i386-debian-linux)

rreale@iol.it writes:

> On Mon, Jul 15, 2002 at 08:03:55AM -0700, James Morrison wrote:
>>  Who delegates where the shared memory is
> But, I think, whatever component does now memory management.
>>  and who has access to it?
> Of  course, the processes  involved  in message passing.   I've some
> vague ideas on how this could  be performed, but  because of my poor
> English it's not so simple  for me to  put them down.  Nevertheless,
> if you think it's not wholly time lost, I'll try to do my best.

There is a dependency on someone  arbitrating who has control over the
memory.  Eventually it boils down to one of two models (oversimplified
but hopefully this will help clarify things)

    1.  Some   priviledged user/process   determines  which memory  is
    available for communication.

    2. A free for all, anyone  can arbitrarily choose to negotiate who
    to communicate with, and or which memory to use.

In  traditional  multi{user,tasking}  OS   design  the  kernel  or   a
supervisory program   running with  some  special  priviledge  accepts
requests and grants(or denies) communication channels or allocation of
memory [1].   In  a   microkernel design,  this  may  be  left  to  an
independent  'user  space' process,   but   still  it  runs  with  the
priviledge of making the decision.

In  [2] the process can  access memory as  it wants.  One problem with
[2] is  that, (as in  {IBM-PC/MS}/DOS) a mis-behaving or  evil process
can access memory which is being used by other processes.  In the case
of an errant uninitialized or   faulty pointer, the address can  cause
_bad_(TM) things to occur.

Bad things include overwriting memory in other programs address space,
including  device drivers  and system resources.   Imagine overwriting
the console driver's  interface,   or replacing an  interrupt  vectors
pointer to point to a memory location with your evil routine, then you
can capture keystrokes, or lock the machine.

This type of   problem   (lockup's  or freezing or   misbehaviour   of
programs)  was a  frequent occurrence  with   pc's, up  to the current
implementations of windows (non/NT (aka OS/2) kernel).

Hope springs eternal!

/ \

reply via email to

[Prev in Thread] Current Thread [Next in Thread]