Re: ipc security

[Espen Skoglund]

[Marcus Brinkmann]
>> I tend to agree with Neal that using redirectors for all IPC
>> operations is too much overhead, however, it would be neccesary if
>> this problem cannot be solved.

I'm currently working on new mechanisms and abstractions witin L4 that
provides much more flexibility to efficiently managing communication
channels.  (Sorry, no, I don't have the specs yet.)

>> - The other solution is to put the page tables in user space, like
>> the UTCB area.  In that case, an address space will have a maximum
>> number of mappings.  This seems like a theoretically nice solution,
>> however I don't know if it fits at all into the current design of
>> the kernel, and I expect it to be a huge change.  I also don't know
>> the performance implications.  I'm guessing the L4 people thought
>> of it and rejected it for some reason.  It's not something we
>> should do, anyway.

> Yeah, this is the holy grail here, I guess.  I think EROS has
> something like that.  You could ask the L4 people, of course.  Maybe
> it's planned for a future version.

The way that L4 poeple tend to view how kernel resources should be
managed is something similar to [1].  As for controlling mappings
(i.e., controlling who is allowed to map), this may very well find its
way into the next version of the L4 API that I mentioned above.

> String items are usually faster for more than around 40 words on
> ia32 (IIRC).  And, as I said above, you are underestimating the
> overhead for containers, which is many more times than the overhead
> to deal with string items.

Breakdowns of costs for the IDL compiler and the overhead of
marshalling arguments with IDL4 is analyzed in [2].

> A variant of this is described in the paper I mentioned in my mail
> (I should dig out a proper reference for you).  I think it's a model
> considered by the EROS people.

The paper you are referring to is [3].  I can't remember the detail,
but after looking through the paper when it was published we concluded
that we could solve the problem in the same manner as described in the
paper.

        eSk


[1] 
http://i30www.ira.uka.de/research/documents/l4ka/userlevel-mgmt-of-kernel-mem.pdf
[2] 
http://i30www.ira.uka.de/teaching/thesisdocuments/haeberlen_study_idl4opt.pdf
[3] http://www.eros-os.org/papers/IPC-Assurance.ps