pointer implementation far19

[Francois-Rene Rideau]

>> Hi!
(>> is Dennis, >> > is Gary)

>> >    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.
 I already thought about using segment as direct pointers to objects (a long
time before MOOSE); but as for obvious security reasons an application can't
modify its descriptor tables, the system should do it; then, each time you
assign a new value to a segment, you must use a system call. It's pretty
slow ! The only solution that arose was again the system low-level
interpreter: if you trust it, you can allow it to modify segments directly,
and it can be quick if algorithms involving lists and pointers are
implemented in the interpreter.
 Whatever, segments can't be the only way to point: offsets are far quicker,
and suffice for internal calculation. Segments should be used only for
inter-object communication; then, descriptor tables can be used as pointer
tables (could you remind me if DT addresses point to real or virtual
memory ?).
 Finally, that's a purely 386 specific hack. You can't expect it to work
on any other system. What I mean is we mustn't build MOOSE specification
around an unportable hack, which does not mean this hack isn't interesting
for implementation.

>> > 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.

On other processors, an interpreter is compulsory to ensure security,
but for very sure assembler (device) routines.

>> >    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
>>