At Tue, 18 Oct 2005 15:25:42 +0200, Espen Skoglund wrote: > One way to look at the in-kernel mapping database is as a cache for > mapping information. Inserts to and removals from the cache happen by > MAP or UNMAP operations. However, by virtue of being a cache the real > mapping information must be stored somewhere else, i.e., in user-level > pagers. If the pagers do not record the mapping information, then > yeah, tough luck, you'll have a hard time reconstructing the mappings.
Believe it or not, I was actually thinking today (and yesterday, and the day before) of writing an email to Jonathan and this list explaining this "mapping database as a cache" concept, but what I had in mind was not as clear as what you said. I thank you for this mail, it was important an important clarification to be able to focus on what the real issues are with the L4 design (if any :). I have two griefs with this design. One is purely pragmatic, while the other is, as far as I understood it, at the root of at least one of Jonathans objections. First, a purely pragmatical point: While having the mapping database as a cache is a worthwhile concept in the case of memory resources, it doesn't seem to make much sense to me for capabilities to endpoints. I am well aware that there are applications (persistence, etc) which require to keep the mechanisms for all resources in L4 consistent. However, please also consider this: A typical client process will probably have about a couple of dozen endpoint capabilities. A typical server maybe a couple of hundreds. From a purely pragmatical point of view, caching of mapping information (which _must_ be done in L4 to get a reliable structure) seems to be a burden to me, of little utility beyond those imposed by the L4 design in the first place. In other words, there doesn't seem to be any "outside" pressure for endpoint capability caching. All pressure in this direction seems to be intrinsic in the L4 design itself. Second, and more importantly. As you go up the chain of processes providing the fault handlers for their clients, you will eventually end up at a place where more than one user is served in the same process. There must be, because there can be only a single process at the top, and there are many users at the bottom. So, the user's pagers have to be coalesced at some point in between. This is the point where DoS attacks become dangerous, as far as I understood Jonathans remark in a reply to Neal: > I am arguing, and I have argued to the L4 team, that implementing paging > in a way that breaks resource bindings is simply broken. Various > individuals have proposed various "solutions" to this problem within the > L4 primitive set. All of the solutions that I have heard so far involve > a central region manager (or something conceptually playing the same > role) and make it impossible to eliminate system-wide denial of > resource. I consider any design that imposes this requirement to be > entirely unacceptable. If I want broken architecture, I can run Linux. The "central region manager" would be the process which coalesces different user pagers into a single pager. The system-wide denial of resource attack finds a foothold in this manager process. Jonathan makes a very broad argument here, that would apply to a wide variety of possible system architectures on top of the L4 microkernel design. Does the problem exist as I described? Do you recognize it? And if yes, what is your response? If not, what is your suggested solution? If I made a mistake, please correct me. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
