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

[Brian Brunswick]

On 05/11/05, Jonathan S. Shapiro <address@hidden> wrote:
>   1. Self-paging introduces a known, surprisingly high-bandwidth
>      communication channel.
>
>      Actually, this is not correctly stated. There is no problem with
>      paging against your own pages and deciding which of your pages to
>      unbind when you do. The problem lies in any system where the system
>      asks you to alter your residency properties -- this is the source
>      of the communication channel.
>
>      So I have no objection to self paging, and in fact Norm Hardy and
>      I designed a very simple and beautiful low-level mechanism for
>      doing this in EROS long ago (never implemented). What I object to
>      is self-paging as the basis for global resource management.
>
>      In my defense: every self-paging design that I know about (other
>      than the one that Norm and I did) has been introduced for the
>      purpose of supporting global resource management, and people
>      almost universally seem to use the term "self-paging" as a
>      shorthand that includes by reference their ideas about a global
>      resource management scheme.
>
>      So: apologies for my imprecision, and I hope that the real
>      objection is now more clearly identified.

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.

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,...)

>
>   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.

>
>   5. Explicit management of residency is tricky in a persistent system.
Also in a non-persistent system :-)

> 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....

> Which of these facts would you like to dispute, and where is your
> evidence? [That is not intended to sound "heavy" -- email is terrible
> for this. I am truly interested to see evidence that would dispute these
> facts.]
>
>
> 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!

>   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.

>
> 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?
(Untrusted confined code access to private data? What are the
compelling reasons for allowing this? Hmm... I can imagine some...)
Covert channels that leak info about crypto are fairly obviously bad,
but that is a different situation, since the software handling the
crypto better be trusted.

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.

> 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.

That said, I myself support security as a good principle.

--
address@hidden