Re: Progress on AdaOS

[dmitry@elros.cbb-automation.de (Dmitry A. Kazakov)]

On Fri, 07 Sep 2001 15:58:30 GMT, Darren New <dnew@san.rr.com> wrote:

>> If there is "a process that supplies a service", then it is another
>> process, i.e. the method is executed on another context.
>
>I'm not sure how you would enforce any sort of access control in the
>case of only having one context, actually.

Well there should be several contexts of one process. For instance,
let an application owns a "safe" object. It is safe in the sense that
its data cannot be accessed otherwise than through the object's
methods. To enforce this the corresponding memory pages should be
normally inacessible for [read/]write. However when an object's method
is called, there should be a context switch upon the call that would
make the memory pages accessible for read/write. Upon return the
context is switched back.

I very like the idea, someone mentioned in a parallel thread, that the
access rights can be made dependant on the page the PC points to.

>> This is
>> another case and a heavy weighted one. It would be very inefficient to
>> have a separate process for every object.
>
>It doesn't need to be a separate process for every object. Indeed, in
>Ameoba (Tannenbaum's OS), all the files are managed by one process.

It is no matter one or many. It is like the difference between
rendezvous and protected objects. You simply need both of them because
rendezvous are inherently slow when compared with protected objects
and yet not all necessary things can be made using solely protected
objects.

>You have a capability for each file, a capability for each server, a
>capability for each directory, a capability for each process (so you can
>kill it, debug it, etc), and so on. 

It is OK to me.

>You don't have a capability for each array or tagged object, for
>example, because you're not trying to protect them from yourself.

Yes, but there are exceptions. Consider an object OpenKeyPair given to
an application. The application is allowed to use its public methods
(Code/Sign/Encode), but it cannot read its data, create a copy of it
or pass it to another application.

I have nothing against capacities if they allow to have access rights
to object's methods and members dependent on the access level to the
object itself. [Of course only "safe" objects are considered.]

>> This will also exclude
>> passive objects [= Ada protected objects] which have no task
>> associated with.
>
>I think if you have the protected object in your data space, there's not
>much point in enforcing an administrative limitation on who can get to
>it. On the other hand, if your hardware supports capabilities directly,
>then there's no problem with doing this. 

IMO it is very important to have *safe* objects living in the process
space, because then a lot of things could be made within the process
time quant, which otherwise would be served by some driver, ACP etc,
with a catastrophic impact on real-time issues.

>Think of a capability as vaguely similar to a trap instruction, perhaps.
>You're granted a capability by the OS putting the address of the routine
>to call into the interrupt vectors where you can get to it with a system
>trap. The OS then checks that your arguments are legal. Same thing.

Agree. It is how it could be implemented in a machine of usual
achitecture. Maybe sometimes CPUs will support type tags, then... [at
least 15 years old idea] (:-))

Regards,
Dmitry Kazakov