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 correctness. (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 guarantee. Okay. On to the mechanisms. Further postings on coyotos-dev, so that the discussion will occur on the right list. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
