[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unmapping fpages
Re: Unmapping fpages
Wed, 29 Dec 2004 04:46:34 +0100
Mozilla Thunderbird 1.0 (X11/20041206)
Espen Skoglund wrote:
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.
[Neal H Walfield]
We are running into a problem when the client deallocates the
physical memory. physmem needs to make sure that it doesn't have an
exant mapping and it cannot trust (most) clients to do an l4_unmap.
Ask yourself: in which case does it really matter that the client does
not have read-only access to the memory (e.g., to the C library)?
Surely, the client can not modify the memory. And if the contents of
the memory will not change (as probably is the case with a library),
there is no leakage of information anyway. Why not just trust the
client to perform the unmap in these cases?
Mapping a page should return a capability, and unmap should work on
those capabilities not on fpages?
If it happens that one
particular client mapping needs to be revoked (e.g., due to it being a
read-write mapping), and should be revoked separately from the other
mappings, then you'll have to use some sort of alias mapping that the
server *only* maps to one client so that he can revoke this one
mapping at a later stage.
Yes, I know, the situation is not ideal. We do, however, have ideas
on how to remedy the situation should it prove to be a real problem.
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. I think these inter-dependancies
are aestatically unacceptable, a genuine problem in real-world systems
and quite easy to fix (without performance penalties).
The other problem, and the one which is far worse in my analysis, is
that physmem cannot actually flush the 16kb fpage that it gave to
the client: it must flush the fpage that it has because it would be
"[p]artially unmapping an fpage [which] might or might not work"
The "partially unmapping" refers to established mappings. The server
would revoke the existing mapping in the client, not in the server
itself (i.e., it would do an unmap rather than a flush). As such,
given that the server only did a partial mapping to the client in the
first place, the "partial unmap" does not apply here.