l4-hurd
[Top][All Lists]
Advanced

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

Re: problems with hierarchy: L4 pagers


From: Marcus Brinkmann
Subject: Re: problems with hierarchy: L4 pagers
Date: Tue, 18 Oct 2005 23:52:19 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

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






reply via email to

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