Re: Unmapping fpages

[R. Koot]

Espen Skoglund wrote:

> [R Koot]
>  
>
> > This is exectly what my first reply was, but the problem is that
> > we're talking about the physmem server, and that memory would
> > *always* be remapped into another adresses space soon after being
> > unmapped (into creditcard_and_password_storage_serv for example). If
> > the original server didn't do an l4_unmap it would now be able to
> > read the memory of that other server.
> >    
>
> In which case the physmem server would unmap the memory from *all*
> spaces before giving it out to creditcar_and_password_storage_serv.
> Unmapping the memory from all servers is no problem.
>  
But this would at best have a high (and maybe unnecessary) performance 
penalty associated with it. The problem here isn't that it's can't be 
done the way it is now, it's just that there might be a better way (or 
maybe not, it would be necessary to investigate both the benefits and 
cost first). The main problem with the current implementation is that it 
creates interdependencies between servers (maybe I should be more 
careful in my wording and say "it's more/very/too difficult to design a 
system which there aren't any with the current L4_Unmap implementation, 
but I won't). Interdependencies make the system complex. more difficult 
to analize, cause performance and scalability problems, cause hidden 
bugs and, as Neal mentioned, open up the possibility of DoS attacks.

>  
>
> > Mapping a page should return a capability, and unmap should work on
> > those capabilities not on fpages?
> >    
>
> You're viewing L4 as a pure capability system.  L4 was never designed
> to be a pure capability system.
>
>  
I'm not. I think L4 gains much of it's elegance and performance by 
staying close to the hardware and a capability system is somethink that 
can be build on top op L4. The word capability was maybe chosen badly in 
this context. I think identifier (like Thread IDs) would better descibe 
it's purpose.

Now I really don't know how the mapping database is implented (are there 
any papers on this subject?) but I guess it would be some kind of tree 
structure which L4_Unmap iterates over. The fpage you're unmapping 
specifies the starting node in this tree. Each branch would be a mapping 
made from that fpage. L4_Unmap would unmap each branch, now my 
suggestion would be to add another parameter to L4_Unmap to allow it to 
unmap only one of the branches.

> Yes, it is true, we can incorporate loads of "fixes" into the L4 API,
> but doing so almost always raises new problems and/or implementation
> issues.  That's why we tend to be very conservative about extending
> current APIs.  What many people see as "an easy fix" tend to be not as
> easy when you look at all the consequences.
I think "loads of 'fixes'" would apply to this case (adding support for 
ELF TLS would IMHO). L4_Unmap is the only syscall that hasn't changed 
since v2, I believe it is showing some defects and it should be 
considered to fix this in the kernel instead of user-mode.


Ruud