[Top][All Lists]

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

Re: Meaning of self-paging

From: Jonathan S. Shapiro
Subject: Re: Meaning of self-paging
Date: Fri, 13 Jan 2006 21:46:54 -0500

Before I go an address pinning and interference control, I want to
describe some background constraints on the solution. Hurd alone might
not be concerned about these constraints, but Coyotos is (in some
respects) a much more conservative design:

1. (Originally): The kernel will not rely on an application for kernel

   (Updated): The kernel will only rely on the correctness of driver
   code for kernel correctness, and then only in a restricted way.

2. Because of multilevel and covert channel security concerns, the
   kernel cannot query arbitrary processes when attempting to satisfy
   a resource request. For example: if a top secret process needs
   a page frame, we definitely cannot ask a public process to evict.

So in general, the design pattern has to be that the application tells
the kernel in advance what the policy is, and the kernel implements it.
Because the kernel has other constraints concerning storage allocation,
this tends to limit things to some fairly simple policies, but they may
be sufficient in practice.

Finally, I want to emphasize that the mechanisms I'm about to describe
on the coyotos-dev list are intended to serve as bottom-level
mechanisms. There are a variety of policies that people can (and will)
build at user level on top of these. As an example of the kind of thing
that I mean, the mechanisms implement only "hard" constraints --
however, they provide enough fault handling support to allow
applications to implement soft constraints by changing the kernel hard

Okay. On to the mechanisms. Further postings on coyotos-dev, so that the
discussion will occur on the right list.


reply via email to

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