Re: Facts vs. Opinions (was: Re: A comment about changing kernels)

[Jonathan S. Shapiro]

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