Squeak-e

squeak-e@lists.squeakfoundation.org

54 discussions

'gotta get this done... =\
by Alan Grimes 15 Feb '04

15 Feb '04

om, Okay, attached is part of my current attempt at implementing my Sphere design. There's also a sketch of how I envision the system working. The yellow part is supposed to be the Sphere class itself. Unlike Environment, it doesn't directly support an instance of Smalltalk, instead its role is merely to provide the structure and support the core services as listed in the "SphereInterfaceBase" class. The reason for this design decision is that it will, hopefully/eventually be relatively language agnostic such that it will be possible to write language bindings such that you can write spheres in the language of your choice. -- hence the Intercal joke. -- heck, intercal 2 can't be any worse than its predecessor! ;) The "CPU" and "MEMORY" modules provide the interface between the Sphere system and whatever the heck is running the code for this sphere. The little purple spheres are nested spheres which are managed by the sphere system. -- By necessity, the entire Sphere framework must be in the same language. The "interface" and "outerface" are callbacks to the intercal 2/whatever code. (or to some code in a parent environment) One security issue with the interface and outerface is that they must be invulnerable to modification in any way yet still accessable to the varrious modules. Visability: The outerface must be visable to other spheres in the system and the parent environment. It must be callable in a fairly elegant fassion and be able to return session classes and objects in such a way that a call to a session object will be transmitted to the providing sphere in such a way that is exclusive to any other communication. The interface is inherited from the base class and may be extended by the sphere's code and _ONLY_ by the sphere's code. It automaticly becomes the base class for any sub-spheres... This may pose a problem because spheres should be dynamicly loadable, -- it should be possible to load a sphere within any sphere which has compatible interfaces. This means that the inheritance mechanism just mentioned must be agnostic to the actual name of the class being inherited!!! =P (If this were easy I would have done it myself. =( ) The top-level problem is that I'm only an intermediate level Squeak programer trying to design a meta-meta class. =P Come to think of it, my feeble and confused mind had a different idea about this long ago... The key to my older design was that the CPU needed to have enough features for the intercal/etc environment to basically run its own kernel.... I think this design will also work and, if done correctly, will redily lend itself towards the more ambitious nested-kernel design. =) -- I will post with increasing frequency untill something happens... I really _NEED_ this OS!!! =\ Object subclass: #Sphere instanceVariableNames: 'Name interfaces Outerfaces Memory Supervisor Subordinants tasks visitingTasks MyPriority allowRecursiveCalls ' classVariableNames: '' poolDictionaries: '' category: 'Sphere-Base'! !Sphere commentStamp: 'ATG 10/16/2003 17:00' prior: 0! This is the base class for a system oriented operating system called "sphere". For reasons of system durability, this class is to be used to manage the actual spheres and not directly linked to any Sphere software. This is neccessary to enhance compatibility across versions and through time. ! !Sphere methodsFor: 'accessing' stamp: 'ATG 10/17/2003 16:29'! changeNameTo: aNewName "om." Name _ aNewName. ! ! !Sphere methodsFor: 'accessing' stamp: 'ATG 10/19/2003 17:33'! interface: newInterface interfaces _ newInterface. ! ! !Sphere methodsFor: 'accessing' stamp: 'ATG 10/17/2003 16:51'! name ^Name.! ! !Sphere methodsFor: 'accessing' stamp: 'ATG 10/19/2003 17:35'! outerface: newOuterface Outerfaces _ newOuterface. ! ! !Sphere methodsFor: 'error handling' stamp: 'AFG 10/4/2002 14:14'! serverFailure "should a server this sphere depend on fail..." self die. ! ! !Sphere methodsFor: 'initialization' stamp: 'ATG 12/18/2003 19:02'! initialize super initialize. Name _ 'UNUSED'. " a generic sphere doesn't need an interface... " " interfaces _ SphereInterfaceBase new. Outerfaces _ SphereOuterfaceBase new. " Memory _ BogusMemory new. Subordinants _ Array new. tasks _ Heap new. visitingTasks _ Collection new. allowRecursiveCalls _ true.! ! !Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 17:01'! addSubordinant: aSubordinantSphere Subordinants add: aSubordinantSphere.! ! !Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 16:48'! assignMemory: aVirtualMemoryProvider Memory _ aVirtualMemoryProvider.! ! !Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 21:56'! doToAllChildren: aBlock Subordinants do: aBlock.! ! !Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 17:03'! extTryService: aMessage! ! !Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 17:04'! intTryService: aMessage! ! !Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 21:27'! memorySize ^ Memory size.! ! !Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 16:46'! parent ^ Supervisor.! ! !Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 16:47'! parent: aNewSupervisor Supervisor _ aNewSupervisor.! ! !Sphere methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 17:27'! removeSubordinant: aDerilictSubordinant ! ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! Sphere class instanceVariableNames: ''! !Sphere class methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 22:13'! createNewIn: aParentSphere | aNewSphere | aNewSphere _ self new. aNewSphere parent: aParentSphere. ^ aNewSphere. ! ! !Sphere class methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 16:50'! createNewIn: aParentSphere with: aMemory | aNewSphere | aNewSphere _ self new. aNewSphere parent: aParentSphere; assignMemory: aMemory. ^ aNewSphere. ! ! Object subclass: #SphereCallInterface instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Sphere-Base'! !SphereCallInterface commentStamp: 'ATG 10/17/2003 17:28' prior: 0! The syscall interface for Sphere. ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! SphereCallInterface class instanceVariableNames: ''! !SphereCallInterface class methodsFor: 'as yet unclassified' stamp: 'ATG 10/17/2003 16:58'! SystemCall: aMessage "Tries to find a sphere within or available to the current context which understands this message. This is a secure synchronous call from the sender's perspective. from the receiver's perspective it is an assynchronous event which executes one of the public interfaces." ! ! Object subclass: #SphereInterfaceBase instanceVariableNames: 'owner ' classVariableNames: '' poolDictionaries: '' category: 'Sphere-Base'! !SphereInterfaceBase commentStamp: 'ATG 10/16/2003 17:32' prior: 0! Base class for interface objects. Each Sphere is likley to have two children of this class, one exclusively for subspheres and one that is accessable publicly.! !SphereInterfaceBase methodsFor: 'thread navigation' stamp: 'ATG 10/17/2003 00:24'! enter: aSphere "switch the current thread's context to the new one." ! ! !SphereInterfaceBase methodsFor: 'thread navigation' stamp: 'ATG 10/17/2003 01:03'! home "return to home context"! ! !SphereInterfaceBase methodsFor: 'thread navigation' stamp: 'ATG 10/17/2003 01:03'! leave "leave current context" ! ! !SphereInterfaceBase methodsFor: 'security' stamp: 'ATG 10/17/2003 01:10'! giveAccess "Grant the thread's home access to this sphere." ! ! !SphereInterfaceBase methodsFor: 'security' stamp: 'ATG 10/17/2003 01:10'! requestAuthent: key "request security access to the parent context with provided key." ! ! !SphereInterfaceBase methodsFor: 'informational' stamp: 'ATG 10/17/2003 21:11'! HELP "!!!!!!!!" "return a help message for this context." ^ 'Welcome to the Sphere Operating System. This is an early prototype which is intended to demonstrate its basic concepts and perhaps even serve as the basis for a more capable version. You are in a context called a Sphere. The system calls available here are derived from the services provided by other Spheres which are also within this context as well as (possibly) spheres outside of this current context. Use the List function to learn what spheres may be here to explore. use menu function to learn what commands you can try.'! ! !SphereInterfaceBase methodsFor: 'informational' stamp: 'ATG 12/18/2003 19:03'! VMLook "return a virtual memory report for this and all subordinant contexts." ^ owner memorySize.! ! !SphereInterfaceBase methodsFor: 'informational' stamp: 'ATG 12/18/2003 19:03'! getCurrentContextName "returns the name of the current context." ^ owner name. ! ! !SphereInterfaceBase methodsFor: 'informational' stamp: 'ATG 10/17/2003 22:07'! list "returns a list of spheres within this context." | tempString | tempString _ String new. Owner doToAllChildren: [: x | tempString append: (x name). tempString append: ' ' ]. ^ tempString.! ! !SphereInterfaceBase methodsFor: 'informational' stamp: 'ATG 10/17/2003 00:23'! menu "I think this should return a list of methods of the interface class and all the commands available within the current context, including interfaces provided to parent contexts for both program and user interfaces." ! ! !SphereInterfaceBase methodsFor: 'graph managment...' stamp: 'ATG 10/17/2003 14:05'! disconnect "disconnect a client gracefully." ! ! !SphereInterfaceBase methodsFor: 'graph managment...' stamp: 'ATG 10/17/2003 14:06'! disconnect: serverSphere "disconnect a client or server ungracefully." ! ! !SphereInterfaceBase methodsFor: 'graph managment...' stamp: 'ATG 10/17/2003 00:22'! graph "Returns a dependancy graph that may be converted into any of a number of types of user reports." ! ! !SphereInterfaceBase methodsFor: 'graph managment...' stamp: 'ATG 10/17/2003 01:04'! recogClient "Recognise the home of the thread as a client." ! ! !SphereInterfaceBase methodsFor: 'Sphere Managment' stamp: 'ATG 12/18/2003 19:04'! create "Create a gnu sphere within the current context." | newSphere | newSphere _ Sphere createNewIn: owner. owner addSubordinant: newSphere. ^ newSphere. ! ! !SphereInterfaceBase methodsFor: 'Sphere Managment' stamp: 'ATG 10/17/2003 00:02'! interpret: someSpherewarez in: thisSphere ! ! !SphereInterfaceBase methodsFor: 'Sphere Managment' stamp: 'ATG 10/17/2003 22:21'! murder: theVictim "not much needs to be done for process cleanup in a GC'd environment... This will delink the sphere and run a GC..." ! ! !SphereInterfaceBase methodsFor: 'Sphere Managment' stamp: 'ATG 12/18/2003 19:04'! setHomeSphere: newOwner owner _ newOwner. ! ! !SphereInterfaceBase methodsFor: 'Sphere Managment' stamp: 'ATG 10/17/2003 22:22'! shutdown: aSphere "Attempt to run a Sphere's cleanup routines and shutdown gracefully." ! ! !SphereInterfaceBase methodsFor: 'Sphere Managment' stamp: 'ATG 10/17/2003 01:07'! transfer "give this sphere's responsibilities to the caller, used for On-the-mosquito upgrading." ! ! !SphereInterfaceBase methodsFor: 'interface managment' stamp: 'ATG 12/18/2003 19:04'! installInterface: newInterface owner interface: newInterface.! ! !SphereInterfaceBase methodsFor: 'interface managment' stamp: 'ATG 12/18/2003 19:04'! installOuterface: newOuterface owner outerface: newOuterface.! ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! SphereInterfaceBase class instanceVariableNames: ''! !SphereInterfaceBase class methodsFor: 'as yet unclassified' stamp: 'ATG 10/18/2003 11:25'! new: homeSphere "set up the interface to work with the provided sphere." ^ self new; setHomeSphere: homeSphere. ! ! Object subclass: #SphereOuterfaceBase instanceVariableNames: 'owner ' classVariableNames: '' poolDictionaries: '' category: 'Sphere-Base'! !SphereOuterfaceBase methodsFor: 'as yet unclassified' stamp: 'ATG 2/15/2004 01:11'! owner: nOwner owner ifNil: [ owner _ nOwner]. "this should be secure but we really want to hurt the idiot who thought he could take over someone else's outerface." ! ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! SphereOuterfaceBase class instanceVariableNames: ''! !SphereOuterfaceBase class methodsFor: 'as yet unclassified' stamp: 'ATG 2/15/2004 01:09'! newWithOwner: nOwner ^ self new; owner: nOwner.! ! Object subclass: #SphereSoftware instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Sphere-Base'! !SphereSoftware commentStamp: 'ATG 10/16/2003 16:57' prior: 0! Abstract class for all software written for Sphere including drivers and user software.!

1 0

[CSL Colloq] The Skynet Virus * 4:15PM, Wed Nov 12, 2003 in Gates B03
by allison＠stanford.edu 08 Nov '03

08 Nov '03

COMPUTER SYSTEMS LABORATORY COLLOQUIUM 4:15PM, Wednesday, Nov 12, 2003 NEC Auditorium, Gates Computer Science Building B03 http://ee380.stanford.edu[1] Topic: The Skynet Virus Why It Is Unstoppable, How To Stop It Speaker: Marc Stiegler Hewlett Packard About the talk: In Terminator 3, the SkyNet AI distributes itself globally, becoming invulnerable to destruction, by exploiting the fundamental failure of computer security. it then destroys the world when it gains control of America's nuclear missiles. While this is a considerably more serious disaster than any wrought so far by cyber-crackers, cyber-terrorists, or cyber-warriors, the flaws that make SkyNet unstoppable are the same flaws that make crackers, terrorists, and warriors possible. The same fix that eliminates crackers can terminate the Terminators. This presentation starts by examining in detail the fundamental flaw in computer security today--the ludicrously excessive authority granted to even silly programs like Barbie Fashion Designer. We go on to see how the Principle of Least Authority (also known as the Principle of Least Privilege), once ubiquitously applied, can end the madness while simultaneously making the user interface to security simpler than it is today. About the speaker: Mr. Stiegler is currently a Visiting Scholar at Hewlett-Packard. Previous to this appointment, as COO of Combex Inc., Mr. Stiegler led a DARPA research contract to build a working prototype of a capability secure desktop that is invulnerable to traditional computer viruses and trojan horses. Mr. Stiegler designed and implemented the application launch framework for the desktop, developing new forms of user interface/security integration that allow people to safely use even virus-ridden applications without having to work with even the normal litany of foolish security dialog boxes, passwords, and certificates. This desktop was later demonstrated in Mr. Stiegler's presentation, "Exploiting Virus-Laden Software", for the O'Reilly Emerging Technology Conference in 2002. Highlights of Stiegler's earlier works include serving as VP of Engineering for Autodesk, and winning the Software Publisher's Association Best New Business Software Award for DecideRight in 1996.His sf novel Earthweb depicts a future in which a mature Web, with advanced features such as bidirectional links and idea futures, becomes the underpinning fabric of global society. Contact information: Marc Stiegler Hewlett-Packard Palo Alto, Ca 928-279-6869 marcs(a)skyhunter.com[2] Embedded Links: [ 1 ] http://ee380.stanford.edu [ 2 ] marcs(a)skyhunter.com

1 0

Paradigm Regained: Abstraction Mechanisms for Access Control
by Mark S. Miller 23 Aug '03

23 Aug '03

At http://srl.cs.jhu.edu/pubs/SRL2003-03.pdf you will find the paper Shap and I just submitted for my invited talk at Asian'03 http://www.cse.psu.edu/asian03/ . We expect to hear back from referees on Sep 7, so we have one more round of revision to go before camera ready. Discussion would be most enjoyable and quite valuable. Thanks. I'm cross-posting this message to cap-talk, e-lang, squeak-e, mozart-oz, and web-calculus, but let's discuss non-platform specific issues on cap-talk. (Please don't reply-all.) Paradigm Regained: Abstraction Mechanisms for Access Control Mark S. Miller, Jonathan S. Shapiro Abstract Access control systems must be evaluated in part on how well they support the Principle of Least Authority (POLA), i.e., how well they enable the distribution of appropriate access rights needed for cooperation, while simultaneously limiting the inappropriate proliferation of access rights which would create vulnerabilities. POLA may be practiced by arrangement of permissions and by abstraction of access. To date, access control systems have been evaluated only by their effectiveness at POLA-by-arrangement. Working in the original capability model proposed by Dennis and van Horn, we show how actual systems have used abstraction to enforce revocation, confinement, and the *-properties--policies whose enforcement has been "proven" impossible by arrangement-only analysis. To account for these abilities, analysis must also examine the behavior of security-enforcing programs (which are usually simple) to see how they limit the authority of arbitrarily complex untrusted programs. The original capability model, analyzed in these terms, is shown to be stronger than is commonly supposed. ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

1 0

Islands up and running
by Lex Spoon 06 Jul '03

06 Jul '03

If anyone wants to play with Islands, it's much easier now. I've pulled out the VM changes so that they apply to a current 3.6 image, so you can load those changes and regenerate your VM from a standard image. The VM you thus get will work for both standard images and for Islands images. Also, thanks to a generous person from Disney, a pre-loaded image has been salvaged that you can play with. Download everything from: http://minnow.cc.gatech.edu/squeak/2074 There are no VM binaries on the page yet, but hopefully people can contribute them. "try this in Islands" Processor activeProcess setIsland: IsolatedIsland new during: [ x := Smalltalk ] "x will be nil, because the Smalltalk dynamic binding is not available on the island" Lex

1 0

first successful CapTP messaging trace
by Rob Withers 10 Jun '03

10 Jun '03

Here is the trace: http://minnow.cc.gatech.edu/squeak/3243 It is pipelining messages, but I don't have a proper event-loop, so it doesn't flush the connection buffers at the end of each vat turn - instead I flush every 10 ms. Also, the lack of an event loop results in no partial ordering guarantees. Proof of this is in the trace showing that the initiating side processes the second resolution before the first resolution (in the third chunk of messages). regards, robert

3 3

capabilities in Mozart-Oz
by Fred Spiessens 09 Jun '03

09 Jun '03

Hi All, For a research project at UCL Belgium I am investigating capabilities to enable secure programming in multi-paradigm languages. The Mozart implementation of the Oz language will be my main research tool. I have to decide now whether or not to build a rough emulation of the E-language mechanisms in Oz first and learn from that, or just go ahead in Oz, and concentrate on the differences with E. 1. Any advice from the subscribers on this mailinglist, regarding this decision? Any particular reasons why you'd choose for the one or the other, or why you think I should? 2. It is claimed that Promise-based concurrency is important in E for security. Do you think it's also important for capabilities in any way? Many thanks, Fred. (I posted this mail on both e-lang and squeak-e mailinglists) _______________________________________ Fred Spiessens Researcher software security UCL university Louvain-la-Neuve Belgium Email: fsp(a)info.ucl.ac.be URL: http://www.info.ucl.ac.be/people/fsp/fred.html

2 2

What happened to our Swiki?
by Mark S. Miller 16 May '03

16 May '03

The current state is blank and locked, and from the history it looks like we've been terribly scribbled on. It seems the last good home page was Version 31, accessible at http://swiki.squeakfoundation.org/squeak-e/1.version?id=31 . Until we figure out how to reconcile the openness of a Wiki with protection from this kind of vandalism, could someone who has the password at least restore the home page to its version 31 state, but leave it locked? Thanks. On the figuring-out front, any ideas for a solution based on the capability security principles Squeak-E stands for? Perhaps using Tyler's style of capabilities as unguessable https URLs? ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

5 5

Changes: Combex de-animates. MarkM moves E work to JHU and HP Labs
by Mark S. Miller 13 May '03

13 May '03

[cross posted to e-lang and squeak-e] First the bad news: Combex has run out of money, and has entered the corporate equivalent of cryonic suspension. MarcS is still looking for funds to re-animate it; so if you've got any leads, please contact him. Now the good news: Through the magic of open source, E has now survived three corporate sponsors. Jonathan Shapiro, a professor at Johns Hopkins University, talked me into enrolling there as a grad student, working towards a PhD, which I have done. My thesis will be E, and Shap is my thesis advisor. I will be making periodic trips to JHU, and I will be spending a semester out there at some point. But otherwise I remain in silicon valley, and am pursuing my degree by remote control. There seem to be many potential synergies between E and other research happening at JHU. Thanks to Alan Karp (thanks!!), I have now joined HP Labs as an Intern. This is a position designed for students, in which I'm expected to spend a good deal of my time working towards my degree -- in my case, working on E. My research will be directed by Alan Karp. I gather there are also many potential synergies between E and other research at HP Labs, but I'll know more soon. (But what are the other consequences of being interned at HP? If it's anything like being interned in Java or Lisp, my identity will soon become canonical. I will be all Mark Millers.) I will be travelling from now till 5/18. Monday 5/19 is my first day at HP. I expect to become active on our lists again starting then. ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

2 1

capabilities question...
by Michael van der Gulik 12 May '03

12 May '03

Hi all. I'm reading that rather interesting paper about capabilities (and the myths thereof) on erights.org. I'm playing around with Squeak and researching how it could be distributed using replication etc. See dpon.sourceforge.net if you're interested. I may switch to E, but I'm just nosing around at the moment, and reading a lot. Question: it seems quite possible to implement ACL's using capabilities. Would this be true? Say for example that you have a secure object called 'Secret'. Other objects access 'Secret' through proxy objects. These proxy objects simply pass all messages through to Secret, and can be turned on and off, to allow and disallow (revoke) access to Secret. Now, assuming that some management system was built around this schema, each proxy object is quite like an item in an Access Control List. If an authentication mechanism was also provided for subjects, which was enforced by the proxies, then would there be any difference between this and another implementation of an ACL system? Michael.

2 1

About dynamic scoping
by Brian T Rice 09 Apr '03

09 Apr '03

The following paper was posted to Lambda the Ultimate Weblog yesterday, describing a language construct for introducing implicit, dynamically-scoped parameters into type-safe Haskell. I thought that this might provide some useful information in trying to reconcile Squeak's exception-handling with E's security discipline. Implicit Parameters: Dynamic Scoping with Static Types http://www.cse.ogi.edu/~jlewis/implicit.ps.gz -- Brian T. Rice LOGOS Research and Development mailto:water@tunes.org http://tunes.org/~water/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Squeak-e