On Sat, 2005-11-05 at 20:00 +0000, Brian Brunswick wrote: > But isn't this communication channel present even without any > self-paging? If the system goes ahead and alters my residency in > response to the actions of another task, that will be easily > detectable by latency measurements, and provide the channel anyway.
Good question. Yes, latency is observable. The difference is that if the system comes to you and says "please remove a page", you have very specific knowledge of when the pressure happened and what form it took. If the system simply removes the page, you have no direct knowledge of these things. The reduced precision of knowledge translates into a reduction in the feasible channel bandwidth. In systems where we are really concerned about such things, there are further steps that the paging agent can take to reduce the information available to the receiver. I don't see how to do these steps in any design where the system communicates pageouts directly and promptly to the victim. > I think self-paging is almost unrelated to the channel, and should be > supported because of the benefits it gives certain types of > applications. (GC, caches,...) We have discussed some of these previously. The benefits attributed to this in early GC papers were later discovered not to exist. I am not aware of any benefits for caches. Can you expand on these? > > 2. Self-paging introduces complications for real-time systems where > > the "in memory" resources are shared. This is well known and well > > documented in the literature. > > It's also seems the only conceivable way to allow paging at all in > real-time systems - allow the application to get real-time guarantees > about the paging. No no. This a different thing entirely. In this case, what you need is for a mechanism that allows the process to volunteer to give up a page. That is an entirely separate issue from whether the system comes to the application and *asks* for it to give up a page. Having a mechanism that allows a process to advise the kernel that a page is no longer of interest is perfectly okay. I think this is a good idea, and I'll be happy to describe the EROS design for how to do this. But let's keep the two issues clearly separated. > > Each of these statements is a statement of fact based on either direct > > experience or well-established literature, or (in the last case) a > > direct consequence derived from the mathematical requirements for > > real-time scheduling. I have seen no contrary evidence or documentation > > presented in the discussion on this list concerning any of these points. > > > > Seems a bit strong.... Perhaps so, but I still haven't seen any contrary evidence. Perhaps you can refresh my memory. > > In addition, I have stated the following *opinions*: > > > > In the absence of a compelling justification for introducing > > self-paging in preference to other paging mechanisms that are known > > to have smaller (or no) channels, or (alternatively) a solution to the > > What mechanisms are known to have no channels? I find it hard to > imagine one. Of course, we can limit the bandwith I hope! The only way to completely eliminate channels is fully deterministic execution, which is definitely not a limitation that any of us would want to tolerate. The goal isn't to eliminate channels. It is to minimize their bandwidth. For Hurd, I don't really think that we should even pay a lot of attention to reducing channel bandwidth. I would simply like to avoid introducing mechanisms that are known to create problems for channel reduction without a really strong reason. I'ld also like to avoid introducing wide channels gratuitously. > > channel introduced by self-paging, self-paging should not be admitted > > into the design. > > I disagree, though of course half-way posistions are possible. (Advisories?) > Perhaps its just because I like GC, but dislike its typical > interaction with paging. I understand that you want strong support for GC, but you have not presented evidence that system-requested paging will help. You also have not presented evidence that voluntary advisories from the application to the system are insufficient. I am not saying that the channel argument should always win. In fact, I don't think that it should. I'm saying that if we are going to accept a known channel, we need a clear rationale. Are you really saying that we should abandon a security mechanism without any reason? > > What I have *failed* to do in my emails is repeat the rationale over and > > over again in each case. I have assumed that after a couple of rounds of > > "well, that design introduces a covert channel problem, is it really > > needed?" people would begin to understand that testing features against > > principles is a necessary part of the design process. I have failed to > > repeat myself obsessively for two reasons: > > Can we go back over the reasons that covert channels are undesirable. > In particular channels that require collaboration on both ends? Yes, but not right now. I'm in the middle of a tricky piece of code, and I don't have the spare mental bandwidth to do a good job on this right now. > Perhaps it all comes back to restricting the bandwidth. Covert > channels seem very very hard to eliminate entirely, particularly when > including the wider physical world. Yes. > > In the absence of clear and measurable benefit, I see no justification > > for overturning principle. > > The principle needs a clear and measurable benefit itself of course. Agreed. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
