Re: self-paging

[Bas Wijnen]

On Tue, Nov 29, 2005 at 08:29:27PM +0100, ness wrote:
> I have not thought very much about the algorithm you propose in detail, 
> but I want to mention sth. else:
> What you propose is not self-paging in a narrower sense. Self-paging 
> means, on memory pressure the application is informed and requested to 
> free a page.

Hm, we have a slightly different definition then.  What I call self-paging is
that the application itself determines which page will be discarded or swapped
out on memory pressure.  Informing the application is one way to do that, but
it can be done differently (as in my proposal, the application just builds a
prioritized list of pages, and the swapping out and discarding happens without
notification).  What is essential to self-paging in my view is that the
decision which page to swap out is made locally, not that that is done at the
moment there is pressure (that is, in my proposal the decision is prepared
beforehand and used by the system when needed).

> This opens a covert channel. You want to close this channel by making the
> page-out invisible to the application (that's at least how I interpret "an
> other page of itself will be paged out").

Correct.  For the application this means that its quota doesn't increase (or
decrease) in large steps, but only slowly.  I think in order to keep the
system functional the delay shouldn't be more than a few seconds (from
starting up until it gets a reasonable quota).

> And only the last thing (invisibility of resource revokation) is interesting
> for closing the covert channel. In fact, every visible resource revokation
> seems to be a covert channel, regardless to the benefits (could one list
> those, please?).

I think so, indeed.  However, at least some, possibly many, resource changes
aren't high-bandwidth channels.  Also, you usually need to fill the resource
to the limit if you want to create the channel.  Suppose you have a server
which keeps your network traffic at 100%.  When the user notices that, she
will kill it and install an alternative.  So I think exploiting the channels
in practice isn't so easy.

> *But* I think we have to balance the benefits of visible resource 
> revokation against the disadvantages of this kind of covert channel. 

Good point.  First of all: if the decay is set extremely high, this system is
simply the same as instantly notifying the applications.  It may cost some
performance though, so if that is the usual setting, then it probably isn't
the right system to use.

Now what is the benefit of visible resource revocation?  Maybe, but only
maybe, the applications can make slightly better decisions about how much
cache to maintain.  However, I'd be surprised if it's noticably better than
when they recalculate on noticing that some cache has been lost.  In other
words, I don't think there is any real advantage to the _visible_ revocation.

There is or course a down side to my proposal, and it's what Mike wrote about
as well: If a process has a huge quota, other processes will need some time
(the decaying time) before they can really start.  As I said, I think this
should be at most a few seconds.  However, this problem can be mostly
eliminated the following way:

When there are changes in the quota (for example, a process starts up and asks
for very much memory), not all memory is given out initially.  Only when there
is no change for some time, is the last part provided to the process which
needs it.  That way, the delay only happens after the system was single
tasking for a long time (or at least not changing tasks), so for example the
next morning when a simulation has been running over night.

> With such a covert channel we cannot enforce confinement in a narrower 
> sense, but I am not sure how applications could efficiently exploit such 
> a channel (can one tell an example, please?).

Assume a bug in a web server.  I am a remote cracker who exploits that and
takes control of the web server.  I do that masterfully, and the web server
continues to serve requests, so nobody notices that it has been cracked.

You, as the owner of the computer running the web server, want to try out this
cool plugin for your browser, which shows the files in colours when you browse
them.  Because we have a secure system, this should not be a problem.  The
browser asks the user agent for the file names and passes them to the plugin.
The plugin is confined, so it can only talk to the browser, which will display
the names in colours... or so you think.

In fact, this plugin was created by me with the intention of knowing what
files you have on your machine.  If the plugin can talk to the web server
(which cooperates, because I control it), all the file names it gets from the
user agent can be sent over the net (because the web server must have a
capability to the network).

Similarly, the contents of files can be compromised as well, of course.  The
problem in general is that we want to allow potentially hostile applications
to handle sensitive data.  Via a covert channel, they can leak that data to
the world.  This is something which we want to avoid.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature