Processes and Communication (2)

Dennis Marer dmarer@td2cad.intel.com
Tue, 9 Mar 93 16:48:58 PDT


Hi!

>    Imagine a system that automatically changes the protection level
> when the code enters a particular code area. Each protected block of
> code would provide a special block of memory containing jump
> operations. This block would allow other code to execute it, and
> executing it causes a protection switch, so when the CPU hits the jump
> target, the processor will be executing with a new set of rights.

For anyone who has familiarity with the 386, you know how incredibly
easy this is to accomplish!  There exists two tables, the Global
Descriptor Table and the Local Descriptor Table, in which entries can
be made to reference segments, tasks, and *procedures*.  Calling one
of these "gates" automatically transfers the task to a higher priviledge
level, allowing it to access parts of memory it couldn't before, or
possibly directly access I/O ports, etc.

One disadvantage: there are only 8192 global entries and 8192 local
(to the task) entries available.  I could see a large task running
short real quick...of course, not *every* method of every object would 
need to go in these tables, just those which operate at a different
priviledge level.

> Hence, communication would be via normal function calls. Even if this
> communication mechanism isn't used, any secure communication method
> between entities with different protection levels would suffice for a
> complete system. One entity could have memory allocation rights, while
> another might have access to a particular device, while others may
> provide high-level services. Accessing these resources is simply a
> matter of communicating with the entities that provide them.

It wouldn't be too difficult to implement a secure method on any
processor, granted its not too antiquated.  Even the 680x0 has its
notion of a supervisor/user mode, which suits our purposes.

>    Please keep the flames down to simmer; this is all hypothetical/
> theoretical stuff, and won't necessarily apply to MOOSE. However,
> there may be some ideas we can use in there somewhere.

I can't think of any other way to accomplish what we need to do without
some sort of mechanism like this.  It's completely transparent to the
programmer and even to the compiler.  I like it!

Just had to put by $0.02 in on the implementation side of this scheme...

		Dennis