elysium-developers

[elysium-developers] Re: elysium-developers digest, Vol 1 #24 - 11 msgs

[Rogelio M. S. Jr. <ro...@ev...>]

> > Why don't we use ASH's (Application Specific Handlers)?
> > Isn't that the way it is done on XOK?
>
> As the solution to what?
>

Inerrupt handling. But then we still have to see how to run the interrupt handler.
In its own task or within the context of the inerrupted  task. We currently use the
former scheme right?

> > Can we use the I/O permission map to control access to io ports?
>
> That's the plan. Each address space will have it's own I/O permissions.
>
>

I see. That also means a TSS for each address space.

>
> > Can we do capabilities the way it was done in Amoeba?
>
> What do you mean? Securing them by means of encryption?
>

Yes and more. Revocation would simply involve changing a random number.
Like:
      struct cap {
   int own_pid;
   int obj_id;
   int rights;
   long check; /*random number which is a copy of random number stored in protected
object*/

Revocations would be simpler this way.
}

>
>
>
> I can't see why it shouldn't be 'exo-ish'. The primary exo principle is
> that the system shouldn't enforce any abstractions that aren't strictly
> necessary for protection. If the kernel can make sure that processes are
> still protected from each other without using multiple address spaces I
> see no reason not to. On the other hand I can't see the benefits of
> mapping all *physical* memory into one address space.
>

I Agree.

Re: [elysium-developers] Miscellaneous

[Kasper V. L. <ve...@da...>]

"Rogelio M. Serrano Jr." wrote:
> > > Why don't we use ASH's (Application Specific Handlers)?
> > > Isn't that the way it is done on XOK?
> >
> > As the solution to what?
> 
> Interrupt handling. But then we still have to see how to run the interrupt handler.
> In its own task or within the context of the inerrupted  task. We currently use the
> former scheme right?

Yes, we do. But I'm not sure ASHs is the right solution. Personally I
would rather go for the 

> > > Can we use the I/O permission map to control access to io ports?
> > >
> > That's the plan. Each address space will have it's own I/O permissions.
> >
> I see. That also means a TSS for each address space.

Not necessarily. I'm planning to use only one TSS. To make it work the
I/O permission bitmap will simply be mapped differently in different
address spaces. That's why each address space - and not each process -
has it's own I/O permissions. The other parts of the TSS will be shared
among all processes.

> > > Can we do capabilities the way it was done in Amoeba?
> >
> > What do you mean? Securing them by means of encryption?
> >
> Yes and more. Revocation would simply involve changing a random number.
>
> Like:
> struct cap {
>    int own_pid;
>    int obj_id;
>    int rights;
>    /* random number which is a copy of random number stored in protected object */
>    long check; 
> };
>
> Revocations would be simpler this way.

If capabilities are to reside in - unprotected - user space we'll need
to use encryption, but AFAIK revocation isn't easier with encrypted
capabilities than with clists in kernel space (IMHO it would be easier
with the kernel controlled clists). 

/Kasper

-- 
-------------------------------------------------------------------
Kasper Verdich Lund, Computer Science Department, Aarhus University
Office: 34P.218              | Phone: (+45) 8942 5680
Email:  ve...@da...  | WWW: http://www.daimi.au.dk/~verdich

Re: [elysium-developers] Miscellaneous

[Kasper V. L. <ve...@da...>]

[snip: using ASHs for interrupt handling] 
> Yes, we do. But I'm not sure ASHs is the right solution. Personally I
> would rather go for the

Maybe I should elaborate a bit :-)

We can avoid the context switches associated with interrupt handling by
mapping a set of 'small address spaces' into all address spaces, and
protecting them using segmentation. To the affected processes (the
process running when the interrupt handler is invoked, and the interrupt
handler process) there will be no difference. They'll still run in a
virtual address space of their own, although they now are protected by
means of segmentation instead of paging.

I refer to "Improved Address Space Switching on Pentium Processors by
Transparently Multiplexing User Address Spaces" (J. Liedtke), which is
available from

http://i30www.ira.uka.de/publications/pubcat/As-pent.ps

/Kasper

-- 
-------------------------------------------------------------------
Kasper Verdich Lund, Computer Science Department, Aarhus University
Office: 34P.218              | Phone: (+45) 8942 5680
Email:  ve...@da...  | WWW: http://www.daimi.au.dk/~verdich