Hello, In this post I will cover a number of issues relating to my efforts to get squeak running in linear framebuffer mode.

1. Major setback: it seems that linux is horribly lacking in support for actual hardware. =(((( This is not a squeak issue so I will ignore it in all future postings with the working assumption that the problem is already resolved...

2. Being a novice VM h4x0r, I rely heavily on the masters. Unfortunately, the primary developer of the unix branch of squeak has been MIA for nearly a month now. =( I would urge the maintainers to give someone else responsibility for the port for the forseeable futrue. [I would do it but I lack the skill, at present...]

3. In studying the framebuffer and looking at software that uses it, I have found a very interesting library which seems to do alot of the low-level work a framebuffer driver would need to do. (see link in subject line). It would also seem that this system could be used on many of the ports, even bringing BeOS up to date. Notably, it seems to provide some measure of a thread library which would be very useful in my interest in paralellizing the interpriter. Oppinions?

Thanx...

om

I have gone ahead and cancled the yahoo groups I created a few days ago in response to all the requests to that effect...

Since you asked for it, here is a brief sumary of the Sphere Operating System, "System Orientation", Sphere's security model, a partial contrast with "capabilities" systems, and finally how it might be implemented on squeak.

###

Sphere has, to this point, been my life's work.

My apparent lack of progress is either reflexive of my lazyness, demonstrative of what happens when someone experiences more than his share of depression, or merely that the task is immensely challenging.

I have two published papers on the subject on my website. One of them is at http://users.rcn.com/alangrimes/cyber/aisphere.txt which is focused on sphere as a development platform for AI and hence is probably the best text for understanding its security features. In it I make some comments about Squeak which may not be entirely accurate and hence open to revision... In the first paragraph of the introduction of that text you will find a link to the other. Both texts are in need of revision so be forewarned...

The project which lead to the Sphere design as it is presented began late in 1994 out of my dissatisfaction with the direction Microsoft was taking the industry. I was only half-way through highschool at the time. I was grossly underinformed about a lot of things and only slightly less so at present. My early readings about assembly language and operating system design combined with a very crude approximation of an understanding of object orientation lead to the design as it is. As I mention in the older of the two texts, I had stumbled uppon a _System Oriented_ design which is akin to some systems that were available in the late 70's and early 80's.

System Orientation migt be a bit confusing to someone who is too familiar with Object Oriented design as the human brain tends to confuse very similar subjects. One way to think about a system or Sphere is as a very heavy-weight object. The closest thing in squeak to a Sphere is the entire running immage. I think the "immage segments" thread may have been attempting to re-invent this same idea yet again but unfortunately I havn't paid that thread the attention it seems to have been due.. =\

One of the principle motovations in creating the Sphere abstraction was the same as that behind object orientation, compartimentalization and information hiding. Its goal was to divide up the functionality of a complex operating system such as DOS (yes I'm dumb enough to think of _DOS_ as complex. ;) and divy it up into neatly interchangable components.

If there is anything orrigional about my Sphere design and any previous design it is that Sphere is _RECURSIVE_. That is it doesn't just consist of a population of objects or systems but that it is, itself a system which may have an arbitrary number of subsystems which in turn may have an arbitrary number of subsystems and so on untill things get pretty darn silly.

I hope that you will ask me many questions about this after you have reviewed my published writings.

Sphere's security model is based on a fairly unique property of its design. In Uniix you start a process which may contain a number of threads which exist within that process and protection domain for the duration of their execution. In sphere, threads can (in theory) directly call functions across protection domains.

A thread in Sphere, therefore, has several properties: Its origin (which dictates its permissions), its location (which dictates its current execution environment, and whatever code it happens to be running.

By a careful design of the interfaces available to a thread, this can be a powerful security mechanism.

Lets say we start with a system, SPHERE, and sub-systems FOO which contains BAR, and a second subsystem BAZ which contains BAT.

We don't care wheather SPHERE is the top-level system or a subsystem of something else. Regardless of its logical designation everything (including ourselves) end up being subsystems of the universe... =P

We reach in and start a thread in FOO. Its environment are whatever services are available within FOO ( in this case, objects and methods). This environment also includes objects and meathods inherited from SPHERE as well as objects and methods _PUBLISHED_ by BAR and BAZ. FOO has no direct access to anything in BAT.

One service available from SPHERE (or another sphere such as BAZ within SPHERE) is "ENTER". With this The Thread From FOO can walk into the BAR. ;)

The thread in FOO can access private services within BAR. It can do so in two ways. First it can call the services of BAR directly (the equivalent of a CALL or JUMP type instruction) which gives control directly to the code in BAR with FOO permissions. The code from BAR could then exit BAR and do horrible nasty things to other systems which might be in FOO. Alternatively FOO could run services from BAR with a FORK-like function call at which point a new thread with BAR privlages would be created which would have no access to its peers.

Lets say BAZ was a filesystem of some kind and one of its functions was "reformat the drive". Since nobody in his right mind would make this a public function it would be within BAZ and not callable by any thread that doesn't have the ability to enter BAZ. BAT is completely inaccessable to anything which cannot enter BAZ either.

Any thread with FOO permissions _CANNOT_, under any circumstances, exit FOO and do anything with SPHERE permissions (which includes the ability to enter and control BAZ.)

BAZ may publish a service "Read A File". This is accessable from FOO. When it is called it has BAR permissions (but it must use trusted BAR code) It can then take its parameters and do its job and return control to FOO code.

A thread with BAR permissions can call BAZ's published functions just as FOO can. HOWEVER: Foo can spoof BAR's interface and either block or redirect calls hence implementing an arbitrary security policy on BAR.

I have not yet studied the capabilities based system yet. It would seem to solve the security problem but do so only by adding a layer of complexity. Sphere's main function is to solve the complexity problem and, happily enough, it seems to clobber security too on the backswing...

Where as capabilities seem to be about painting symbols on an object, Sphere is about its fundamental structure.

It is not clear wheather capabilities have anything to add to SPHERE but it is not at all unforseeable that someone could create a FOO that provides to all the little BARs within it a capabilities driven environment.

Many months ago I toyed with the idea of prototyping Sphere with Squeak. I started to put togeather a Sphere class... I didn't get very far. As my knowlege of Squeak has matured I have begun to see how Sphere could be fully implemented on Squeak.

I still don't have much code but as I make progress on it, the finished class will contain refferances to a refactored SystemDictionary and ProcessScheduler. These two form the basis of the sphere concept. Above that there will be a number of container classes for managing inter-sphere connections and exception handling. (such as system failures so that a failure in one sphere will properly cascade to the spheres which directly interact with it and hopefully be recovered rather than bringing the whole system down! =P)

SystemDictionary seems to be a really cool class. I need all of its class variables to be instance variables (reflexive of the fact that sphere is composed of many systems rather than just one). Unfortunately simply moving the Class variables into the Instance variables crashes the immage because it screws up the instance of System Dictionary on which the entire immage runs!

There was another thread that I didn't pay nearly enough attention to on refactoring System Dictionary, I need some help with this....