[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unmapping fpages
Re: Unmapping fpages
Sat, 01 Jan 2005 16:22:17 +0100
Mozilla Thunderbird 1.0 (X11/20041206)
Espen Skoglund wrote:
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.
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.
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
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.
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.
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.
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.
- Re: Unmapping fpages,
R. Koot <=