2008/5/11 Russell Wallace <[EMAIL PROTECTED]>: > On Sun, May 11, 2008 at 7:45 AM, William Pearson <[EMAIL PROTECTED]> wrote: >> I'm starting to mod qemu (it is not a straightforward process) to add >> capabilities. > > So if I understand correctly, you're proposing to sandbox candidate > programs by running them in their own virtual PC, with their own > operating system instance? I assume this works recursively, so a > qemu-sandboxed program can itself run qemu?
Not quite what I meant. All the AI programs will run in the architecture I create, the fact that I am emulating it on qemu just means I can hopefully easily go to silicon one day. The architecture I create will be set up so that it is as near as it can be close to impossible for an unproven program to disrupt a proven one. I'll try and give an example of how I envisage the system working. A few bits of terminology first. Domain - A region of memory in which normal memory access can take place, . New domains can be created if the region of memory doesn't have a domain in, using a system call. Bank - Domains specialised in the storing and transferring of credit. System calls are used to create and destroy them. Read and write capabilities are never created for them Credit - a money like quantity. It is conserved and handed out to programs dependent upon the current performance of the system. Capabilities - Inter domain pointers, can be used to access memory . They can only be created by code within a domain, for regions of memory within that domain. Bidding - Periodically credit is used bid for system capabilities (special domain capabilities that allow them to be destroyed). If no bids are input the current controller stays the same. Bidding is also likely to be used for heavily contested non-system capabilities, like being able to put a process on a high priority scheduler. So let us get back to the problem a new process is being trialled. Whichever process is creating the new process, will set it up with its own domain, a bank and put some credit in it. Then pay some credit to register it with a low priority scheduler. The process itself will then have to interact with the rest of the system to try and earn some credit to pay for the place on the scheduler and keep up the domain (some of these values might be 0 if the system is below capacity). The setting up process will likely insert some code to the system so that when it gets given credit a portion is funnelled back to itself, so it makes a credit profit on the trial of the new program. A program that consistently makes trials that negatively impacts on the system as a whole will slowly lose credit and be unable to make new trials. If the program is truly malicious or badly coded any negative affect on the system it has will be of limited time duration until it runs out of credit. Any errors it causes will be limited to itself (it can't corrupt others memory). There is no equivalent of root to try and get access to, all programs have to be part of the economy. Will Pearson ------------------------------------------- agi Archives: http://www.listbox.com/member/archive/303/=now RSS Feed: http://www.listbox.com/member/archive/rss/303/ Modify Your Subscription: http://www.listbox.com/member/?member_id=8660244&id_secret=101455710-f059c4 Powered by Listbox: http://www.listbox.com
