[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?
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.
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"
(idem).
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.