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
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
