[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unmapping fpages

From: R. Koot
Subject: Re: Unmapping fpages
Date: Sat, 01 Jan 2005 16:22:17 +0100
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]