[Top][All Lists]

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

Re: Unmapping fpages

From: Espen Skoglund
Subject: Re: Unmapping fpages
Date: Wed, 29 Dec 2004 13:13:37 +0100

[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.

> 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.

> That is what I thought, but this post made me doubt (the manual
> isn't very clear on this). If I mapped two consecutive 4MB fpages
> into spaces A and B then mapped this area as a single 8MB fpage into
> space C, I guess I can't unmap the fpage from B without also
> unmapping the page form A *because of* the mapping into C.

Yes.  This is correct.

> I think these inter-dependancies are aestatically unacceptable, a
> genuine problem in real-world systems and quite easy to fix (without
> performance penalties).

They are unaesthetic to you because you're assuming that L4 should
behave as a typical capability based system.

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.


reply via email to

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