Squeak-e February 2003

squeak-e@lists.squeakfoundation.org

17 participants
29 discussions

RE: [Squeak-e] adding eventual sending to Croquet's ScriptProcess and ScriptScheduler
by Withers, Robert 18 Feb '03

18 Feb '03

Andreas, I said: > -----Original Message----- > From: Withers, Robert [mailto:rwithers@quallaby.com] > I am curious about your use the ivar #myQueue in the ScriptProcess. I > really like that your ScriptProcess will compute a value, and > that that > value is the 'result' of the process. That's a very standard view of > computations. Isn't it a functional view? A better approach > for supporting > eventual sending may be to have a subclass of ScriptProcess > which holds the > continuation to the invocation site. Actually, I am now thinking that a subclass may not be needed, since ScriptProcess already holds onto the invoking message (AsyncScriptMessageSend to be replaced by EventualScriptMessageSend for eventual sending) and the owner, which is the same object. There are also the ivars #myHandler and #myEventMap. In the following method, called when the Process returns from the last stack frame, there are three different mechanisms that we could hook into to activate the resolver. ScriptProcess>>#stopScriptProcess: result ... owner ifNotNil:[owner scriptStopped: self]. myHandler ifNotNil:[myHandler releaseTo: nil]. myEventMap ifNotNil:[self signal: #done with: resultObj]. - owner is the ScriptMessageSend, so an implementation of #scriptStopped: in the EventualScriptMessageSend, could activate the resolver. - myHandler is set when sending #observe: and it is an EventObserver. Currently this only looks to be used by the #waitUntil protocols and it blocks on a semaphore. I suppose that a special observer could be created that holds the resolver. - myEventMap holds event registrations. These can be set at a low-level with #on:notify: or at a higher level by startScript:when:. So after the EventualScriptMessageSend is converted to a ScriptProcess, a registration of the following could wake up the resolver proc on: #done notify: (#resolve: asAsyncScriptMessageIn: self resolver arguments: #()) What do you think would be the best way to activate the resolver? cheers, rob

3 12

eventual references and promises. What's an alternate compiler solution to deal with promise continuations?
by Robert Withers 16 Feb '03

16 Feb '03

Hi All, Does the rubber band nature of eventual message sending, especially now that #immediateRef is working, help provide an interesting interface for users? I don't know if people are aware of the way I adopted Mark's E eventual sending. This is especially true since I really haven't written any documentation on it. :( Here's an attempt at an introduction to them: From reading ( http://www.erights.org/elib/concurrency/msg-passing.html ), I got very excited. In E, with specialized syntax, an expression like "person <- computeCreditRating()" would eventually send the message and immediately return a promise for the result. This promise will 'become' the result of the eventual send. This requires a promise continuation to be sent with the message, so that the evaluation will resolve the promise. Before that happens, your subsequent code can send messages to the promise or the original eventual reference. There are special messages that you can send to synchronize with the result. There is a way to write code that waits until a set of promises are resolved, before doing further work. This allows you to synchronize the results. To try this I decided that building a trampoline that you could send messages to as a surrogate to the real object would allow us to trigger eventual sending just by slightly changing the sending context. This sending context was scoped to that object reference that built the context for you, when you sent #eventualRef to the object reference that will be your receiver. This way, we don't need special syntax to invoke eventual messages. The machinery of ScriptScheduler and ScriptProcess, allows an implementation of #immediateRef to work. This is the first step toward adding the synchronization features. The next step would be to synchronize multiple promises, but I don't have a solution in mind, yet. Anyone have an idea? [Context implementation] I also want to discuss how to improve my contexts. Maybe it is possible to have a perfectly contained reference to an object and use #dnu and a special class for promises. I demonstrated that with changes to the bytecodePrimitiveClass and bytecodePrimitiveEquivalence methods, that double-dispatch equivalence and class as a message send allow surrogates to really stand in for eventual objects. Is there a way to do this without changes to the vm? For efficiency, I had also thought that with the above description of promises and their continuations, on Erights, these references could be defined precisely enough to put into the vm. If you look at my vm-redirectors changeset, you can see that I came up with a pretty clean approach to intercepting message lookup. I use the compactClassIndex to register the Messageredirector class and be able to quickly determine this in the vm. Using the same strategy, we could have special eventual send references, and promise references, that the vm could detect, then the vm could execute different lookup strategies and manage all special reference creation and resolver activation. We still need a way to implement far references and their promises so that the captp and vatp machinery can be interfaced. Are these references in the vm? Yes, but only to redirect the message send like I do in Referencecontext. See #redirectMessage: for the entry point from the vm redirector (or the MessageRedirectionProxy>>#doesNotUnderstand:). I am bothered fundamentally by having to use #immediateCallSelectors and #eventualControlSelectors to choose how to send the message. I thought that Anthony's work or Traits or MethodWrappers would be some alternatives to replacing this mess. see ( http://swiki.squeakfoundation.org/squeak-e/3 ) for SqueakElib, Scripting and the bridge code to see how #immediateRef behaves. cheers, rob

1 0

adding eventual sending to Croquet's ScriptProcess and ScriptSche duler
by Withers, Robert 14 Feb '03

14 Feb '03

Andreas, I should have sent out a quick note thanking you, 2 days ago. So..thanks for the explaination of the Script interface, and the discussion around how it works. Things got very busy at work so I didn't have an opportunity to look deeper until last night. I should have the two linked this weekend. I am currently writing an EventualScriptMessageSend, that holds and activates a resolver, when the computation is completed. This is the return continuation. I am curious about your use the ivar #myQueue in the ScriptProcess. I really like that your ScriptProcess will compute a value, and that that value is the 'result' of the process. That's a very standard view of computations. Isn't it a functional view? A better approach for supporting eventual sending may be to have a subclass of ScriptProcess which holds the continuation to the invocation site. > From: Andreas Raab [mailto:andreas.raab@gmx.de] > [TeaProcessScheduler] > > I am not sure, but I am thinking that this interruptability > > breaks the event-loop model. > > Yes, most likely so. This is a (continuous) time-driven > framework not a > (discrete) event-driven one. It still must execute activations in a sequential manner, so I wonder if it wouldn't be possible to provide 'uninterruptibility', or whatever is needed to ensure an event-loop, yet still have 'real-time' scheduling. No system-level changes, yet. :) cheers, rob

1 0

Draft Consensus Plan
by Mark S. Miller 14 Feb '03

14 Feb '03

Between the replies by Dean, Cees, Joshua, Andreas, and Rob, I see a lot of agreement and convergent thinking. Before replying to the individual posts, I thought I'd first try drafting a set of high level points, plans, and milestones that we could refine into something we're all in general agreement with. Oh, plus a bit of a twist at the end. Please fire away. * Squeak-E and Squeak are to be two similar but different languages -- both in terms of core language and standard libraries. Neither one is upwards compatible from the other, but we expect and hope that they'll be similar enough that much ordinary vanilla non-meta code may be able to be ported in either direction with little manual effort. * Squeak will be unchanged in its security status: All Squeak code in an image is assumed to be able to wield all of their user's authority. All the user's interests are fully vulnerable to -- at the mercy of -- all their Squeak code. (In the jargon, all code written in Squeak is part of the user's "Trusted Computing Base", or TCB.) * The CapTP effort ('A Functioning Interim Vat') to build a library for speaking a cryptographic capability protocol brings the power of inter-image capabilities both to Squeak and Squeak-E. It adds value to Squeak whether or not Squeak-E ever happens, and is tremendously synergistic with Squeak-E if it does happen. This is analogous to CapTP/ELib being quite usable (and used!) from Java, though CapTP is strongly integrated only with the E language. The CapTP effort is therefore an excellent early milestone with few dependencies. * Squeak and Squeak-E will run alongside each other in the one image, and be able to directly point at and call each other's objects. Squeak-E code will only be able to access a tamed subset of the methods defined on a Squeak object -- those in accord with capability discipline. (Note: I like Andreas' selector renaming approach better than my 2-method-dictionaries approach, about which more later.) * Although we don't yet know for certain what we may want to change in the existing Squeak system to better support the Squeak-E effort, we can be confident that all these changes will be upwards compatible to essentially all Squeak code, including browsers, debuggers, and various meta tools as applied to Squeak objects. * Squeak-E is to be designed for security ambition level 4: able to support unprivileged security abstractions. (As another inadequacy of my initial draft taxonomy, these levels don't say anything about self-debuggability or self-malleability.) * We wish to eventually get back to something like Smalltalk's extraordinary self-debuggability or self-malleability in a self-sufficient way, where these tools are themselves written in Squeak-E and therefore subject to capability discipline. I think this can be done eventually (as in the Safra/Shapiro virtualization layers), but it's hard, and if it's included in the first bite, that first bite will be too big to chew. (Note that E is at level 4, but without yet any self debuggability or self-malleability.) * People are understandably attached to their access to Smalltalk's extraordinary self-debuggability or self-malleability, as embodied in the browsers, debuggers, etc. My initially proposed direction of starting Spartan and then building back up to a well supported programming environment would have lost our audience. The Twist * What if, as a bootstrapping strategy, Squeak-E starts out not self-debuggable and self-malleable, but rather debuggable-by-Squeak-code and malleable-by-Squeak-code? In other words, the browsers and debuggers that we use to manipulate Squeak-E computation would be written in Squeak, not Squeak-E, would be simple adaptations of the browsers and debuggers already written in Squeak, and can therefore use the conventional non-capability-oriented meta-level power already accessible to them in Squeak. For example, by taming (eg, by Andreas' renaming) Squeak-E code would not be able to send the real #instVarAt: message to any objects. However, Squeak code can, and the existing inspectors do. Let's say further that, to Squeak code, Squeak-E objects seem to be normal Squeak objects. (Perhaps they are, but we can postpone that.) Let's say that all Squeak-E objects make their instance variables available to Squeak, but not to themselves or each other, through #instVarAt:. Then the normal Squeak-written inspectors can be used to inspect Squeak-E objects without much further work. (The further work is that doit/printit/inspectit in an inspector on a Squeak-E object should probably evaluate the selection by default as a Squeak-E expression rather than a Squeak expression.) * As Dean says, the user already own the image he's running, so if these meta-level Squeak-written tools are in fact trustworthy -- are in fact acting in accord with the user's intentions -- then it violates no actually security for these tools to be able to violate the encapsulation of the objects within the user's image. You'd be losing only the ability to run meta-level tools you don't fully trust, a basis for remote debugging in images you don't control I often run E under a Java debugger, which is logically exactly analogous, but much less pleasant. We are also making slow progress on an E-to-JVM bytecode compiler that would let us apply Java debuggers to E computation in a more pleasant fashion that would actually be analogous. I also have various debugging tools written in Java for helping to debug E code. These are effectively part of the E implementation. Likewise, from Squeak-E's point of view, all tools written in Squeak that can be applied to Squeak-E are effectively part of the Squeak-E implementation. * This direction would let the Squeak-E language shoot for level-4-with-no-meta-levels first, which is where E is currently at, before taking on something like the virtualization layers notion. And unlike E, Squeak-E could do this without sacrificing the Smalltalk-quality tool support, by just using (and slightly adapting) the existing tools. * While doing this, we should all continue discussing these fancier virtualization notions. I'd like to eventually move E in that direction as well. Do these points sound at all plausible? Does the twist sound like a good way to proceed? ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

5 4

RE: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Mark S. Miller 14 Feb '03

14 Feb '03

Rob, I admit I'm a bit confused by your message. Earlier, you wrote: At 07:49 PM 1/30/2003 Thursday, Robert Withers wrote: >Well, it has that burn the diskpacks feel to it, and that's a plus, i believe. which I applaud. In this message you write: At 12:30 PM 2/7/2003 Friday, Withers, Robert wrote: >we should only extend squeak to start supporting security, and keep it >backwards compatible. which is the opposite. In any case, for the kind of security we've been talking about, this isn't possible. (For another kind, see "A Coherent Retreat" below.) Security leverages both abilities and inabilities. Both must be carefully designed. Without the right inabilities, you don't have security at all. Once you have the right inabilities (as in my proposal that we should specify a capability secure subset of ANSI Smalltalk), then you may have security, but you don't yet have a useful system. As you add abilities back to such a system, but in a way that preserves the crucial inabilities, you make the system more usable without losing its security. I think that, by doing this, we can eventually build back up to something close to the level of functionality of current Squeak. But the result will not be compatible. You cannot add inabilities to a system the way you add a new package. New inabilities means that some old code must break. This process -- removing everything that doesn't follow capability discipline, followed by adding back in new APIs that provide similar functionality in a capability-compatible way -- is a kind of refactoring, though a much more violent case then we normally encounter. A great example is Lex's ObjectInspector in the Island's work. It moves the reflective messages from the objects themselves, where any client of the object could invoke them, and puts them instead on ObjectInspector, which can be given only to those that should indeed be authorized to break the encapsulation of these objects. (The Brand system explained earlier enables the issue of "which objects" to be dealt with in a finer-grained fashion, but that's not relevant to the points I make here.) If you think you can get to capability security in an upwards compatible way, what are you going to do about #instVarAt:? Or the APIs for opening and writing any of the user's files? Do you really want any Squeaklet to be able to do that? A Coherent Retreat There is another kind of capability security you can achieve with full upwards compatibility. It is indeed quite useful, it is the one you've already made wonderful progress on, it is where E started and stayed for years, it is the way E's largest customer is using it, and it is also the kind of security supported by Waterken Software http://www.waterken.com . If indeed the Squeak community is not willing to take the steps needed to design and build a Squeak-like capability secure *language*, then this may indeed be a good place to retreat to. In any case, it's something you need to build anyway, it's something you are building anyway, and it may be a good place to start. This alternative is to just implement a cryptographic capability protocol for communication between images. (eg, CapTP on VatTP or WOMP on VatTP or HTTPS.) (Note: even in this scenario you may wish to support multiple vats per image, but this serves no further security function. The security is as-if you were just using capabilities between images.) This kind of security is the addition of a crypto protocol library, and can indeed be added to an existing system as a package, just as you'd add any other package to the system. It contributes no inabilities to an image. All of an image is in the user's TCB, and the user's interests are therefore vulnerable to all the code he's running in his own image. What it does do is allow users to take their own authority, subdivide it into fine grained pieces or derive new authority from by abstraction, and share these derived authorities with others in order to bring about cooperation without vulnerability. One can also bring up servers acting as trusted intermediaries, as in the "mint" in the Ode. Indeed, eChat and everything in the Ode is perfectly viable at this level of security. What you give up is language-based security. Nothing above leverages the almost-capability nature of Smalltalk. You wouldn't be achieving anything that couldn't be achieved equally well by C++ programmers using a CapTP library written in C++. You'd have no ability to locally run code you don't trust, and therefore no ability to make Squeaklets happen. So if this is indeed done as a retreat, it would sadden me. I think that a Squeak-E *language* would be a wonderful thing. But better retreat than total surrender. >> "Mark S. Miller" <markm(a)caplet.com> wrote: >> > (The above argument is also bit of a preview of my upcoming >> "What's Wrong >> > with Dynamic Scoping?") >> From: Anthony Hannan [mailto:ajh18@cornell.edu] >> I agree dynamic scoping is bad (my "smart" capabilities would have >> relied on it). The only tricky thing is how to handle exceptions. At 12:30 PM 2/7/2003 Friday, Withers, Robert wrote: >Guys, I don't agree that dynamic scoping is bad, it just may not be secure >in it's current form. Colin's recent comments drives this point home. If >the environment isn't open from top to bottom to our investigation and >modification, then it isn't going to be Smalltalk. This is a critical >feature to retain. In the kind of massive refactoring we'd need to get language-based security, not only can't we be upwards compatible, we can't necessarily retain all the features we'd like. Our likes evolved without constraint of security. Some things we like may be incompatible with security. Or it may be years before we invent the reconciliation that allows us to revive some form of a feature we like without breaking security (as in my explanation of the Safra/Shapiro virtually nested virtual machines notion). In the meantime, we have to break the feature, not security. If we proceed the other way around, we'll never be secure. This means it'll go though a phase where it may be Smalltalk-like to many eyes, but where the cognoscenti may indeed judge that "it isn't going to be Smalltalk". If you're not willing to go through such a phase, don't bite off language-based security. >Traits, continuations and my eventual sending redirectors are other examples >where either dynamic scoping or system openness are crucial to allow us the >facility. Traits looks very cool, but I don't really understand them yet. Allow me to correct myself. Traits looks *very* cool! How do any of these require dynamic scoping or the existing kind of system openness (as opposed to the kind shown in Lex's Islands work)? > The reason I include both dynamic scoping and system openness, is >that the openness of Squeak _currently_ depends on dynamic scoping. In what way? ParcPlace Smalltalk 2.5 and all ancestors I'm aware of going back to Smalltalk-76 (but not Smalltalk-72), had extreme system openness without any dynamic scoping. > We >shouldn't lose this as we shift towards more security; in fact we should >only extend squeak to start supporting security, and keep it backwards >compatible. Commented on above. >We can start this process by looking at providing more vm support for >evental sending, finishing CapTP, and by migrating Lex's Islands work to >3.5. Lex's Islands work defines a new language and core libraries that is in no way upwards compatible with existing Squeak. And it cannot, given his goals, and what I've been assuming are our goals. >Thus I think the short-term (couple of months) goal should be >supporting security level 2 of Mark's original proposal. I sent out that taxonomy in order to get a sense of how far the group was willing to go and at what price. The answer seemed to be, all the way (level 4). Since then, I've been posting on the assumption that that's what we're going for. Perhaps, now that the costs are clearer, a different level of ambition is desired. Well, that's one of the purposes of having a taxonomy. But all the levels in my earlier taxonomy require language-based security. (I failed to include the above "retreat" proposal in my earlier taxonomy.) Not even level 1 (Java applet-like: does no harm, but is mostly useless) can be achieved upwards compatibly, as Java does not: Applets effectively see a different library API than do Java applications. You cannot generally run Java applications as applets. If you could, there'd be no security. > > Your right, I'm giving too much authority to Kernel creators. >> So instead >> I propose that once a creator "releases" his class he can no longer >> change it. If he wants to make revisions he has to create a new >> subclass. Others may decide to use his new subclass or not. They may >> migrate existing instances to the new class and/or use the >> new class for >> new instances. > >I don't like this restriction. Classes and code should be able to evolve. >Now if an 'Island' has classes bound into it, those classes shouldn't >change, unless the right capabilities to change them are held. And what are the right capabilities? >I think the argument Mark is making is that there isn't a central authority. >In fact, there is no third party security sever or third party interface >respository. I do think that we could specify the protocols for a base >library, but that's really what the ANSI spec is about. There may be some >library specification additions for supporting security/eventual sends. Well, I am making that point. But in the context of Anthony's design -- a distributed shared heap, in which all replicas of an object are considered to be the "same" object -- then, for replicas for which there's no one party that everyone else is willing to take as authoritative, such objects must be immutable. If you don't like the immutability, then some other assumption must give, which is plausible, but leads to a different design. >> MarkM wrote: > >> > Same problem then. I think these can't be automatically >> replicated, because >> > there is no one authority everyone would mutually trust. At >> least I hope there >> > won't be. A world in which there's some one authority >> everyone is willing to >> > make themselves fully vulnerable to is a world ripe for >> dictatorship. >> >> Yes, like above I will change this so no one has authority once the >> pool is "released". However, I will still allow the creator >> to add new >> classes to a pool. This is where he could add his new >> subclass versions. >> Adding to a pool is benign. > >Again, I think that with the right capability, these things could be changed >'locally'. The issue is that there isn't a global authority. You're "locally" implies a change of assumptions that probably could be made to work, but breaks the uniformity of the distributed heap notion Anthony is trying for. It would lead to a different design. >I am encouraged that although this list is turning out to be on the quiet >side, there is much interest in what we are considering. The fact that we >are doing so in a thoughtful way is to our advantage. I've been curious about the sudden quietness myself. >I will be a little more active this weekend, now that the work week is >winding down. I want to implement RemoteHandlers (virtual circuits with >remote objects) and the objectMap. > >The other dimension, that I have been doing a little work with this past >week, is cleaning up the EventualReferences. I am hanging out on the IRC >channel #squeak-e and will be available there to guide anyone wanting to >dive into this very intriguing mechanism. Look at ReferenceContext (the >eventual reference), and RedirectionManager (the underlying redirection >mechanism). If you build a redirection vm, make sure you doit to >'RedirectionManager enable'. I will update the SqueakElib package this >evening. Cool, looking forward to it! ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

7 8

Re: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Robert Withers 12 Feb '03

12 Feb '03

Andreas, I'll just cc the list in response, since this may be interesting and related to our writing a squeake processor. All'y'all, I looked into Croquet and there are in fact two schedulers. Of course, Andreas, is the man with the answers. In a SqueakE vat, I can imagine that there could be multiple stacks pending for some event to occur. Is being uninterruptible the important property of an event-loop? On Wednesday, February 12, 2003, at 06:22 AM, Andreas Raab wrote: >> The real-time scheduling of future messages is the concurrency >> mechanism of choice, I would think. Your scripts make it an >> event-loop, although I suspect that the TeaProcessScheduler >> is also an event-loop. The crucial thing about an event loop >> is... what? Could it be that they are uninterruptible? > > True for the script scheduler (within scripts), not true for the Tea > scheduler. scripts do not interrupt each other, they have "stepping > semantics". The tea scheduler has earliest deadline first policy which > means > it _can_ interrupt another process if work with an earlier deadline is > being > scheduled. I am not sure, but I am thinking that this interruptability breaks the event-loop model. > >> TeaProcessScheduler has several structures of processes. There is a >> heap for timeouts (pending), a heap ordered for deadline (to occur), >> and for lookup, but only by TeaTime, not symbols. How does it deal >> with symbols and pattern-matching? .. oh, the times are inserted by >> the MessageSend, so it does have pattern-matching through sending. >> How does it support an event system? Well, the appropriate >> MessageSend >> could occur. > > Like I was saying, much of this is still in flux. We are not quite > certain > yet, how the earliest deadline first scheduling interacts with the > scripts. > Part of this is the model of time which David develops. IOW, each > process > runs "in time", and accesses state "as of" a particular time. If that > time > hasn't come yet it will block (or alternatively perform an eventual > computation which may later be aborted due to changes at "some earlier > point > in time"). Much of this hasn't been implemented yet. The scheduler (as > of > now) only garuantuees strict earliest deadline first scheduling. > >> ScriptProcessor, creates chained handlers and then suspends >> the process (but not always). The handlers are looked up by >> pattern matching whenever events occur. So you added yet another >> event system! ;-) > > For the scripts, the policy is really simple: Scripts either run to > completion or until they wait for something to happen (this might be an > event or a time out or a semaphore signal). Which is exactly what step > methods do (in a generalized sense). What you see in some places (the > "but > not always" part of the above) is mostly implementation detail which > ensures > that certain critical notions are preserved. Such as (for example) > that when > we enter a critical section *and* the process entering it can aquire > the > lock immediately that it will not be suspended. This turned out to be > critical for a number of places. > >> I like the semantics of it. #signal sounds like it is a more >> fundamental mechanism than dependencies or the multicast events; >> like exceptions, but without all of the stack manipulation. >> that would mean that it is an exception capability secure design. >> :) In fact it uses a pattern-matching mechanism, much Linda-like, >> to reschedule scripts for execution. So how does it deal with time >> and time events? Ahh, a tick list. > > No, this is only a little optimization to get some stuff more easily > out of > it. Conceptually, this tick list doesn't matter - it's simply a > convenient > way of allowing scripts to happen on each "world tick" (simulation > cycle, > vat turn, you name it). What are the entry points you use for suspending a script until an event occurs (#waitUntil:), creating and running a new script (#runScript:), triggering an event (#signalEvent:)? I tried following the senders until it got to something that looked like public protocol, but I keep running out of senders. :) Certainly the pattern of creating a new ProcessScheduler and defining the Processes that use it as non-preemptable and uninterruptable, *at least among each other*, may allow this minimal Squeake engine to be built. My DispatchSecretary is slow and needs replacing. Could we just use the ScriptProcessor for our squeake event-loop or should we roll our own? cheers! rob

3 2

Presentation on CapTP for the OMG
by Mark S. Miller 11 Feb '03

11 Feb '03

[cross-posted to e-lang and squeak-e] Last January 27, Marc Stiegler and I did a presentation on CapTP for the OMG. The presentation is available from the OMG website at http://www.omg.org/cgi-bin/doc?mars/2003-01-13 or from erights.org at http://www.erights.org/talks/captp4omg/index.html . Most of talk was spent trying to explain why distributed cryptographic capabilities are the right way to do secure distributed objects. I'd say this part went rather well. We even got some enthusiastic discussion of how the OMG might consider a Corba with cryptographic capabilities *instead* of Corba's current security. I was surprised at how plausible it seemed that this might really happen, but I have no idea what the actual politics might be. Unfortunately, but not surprisingly, we spent the entire time on the security aspects of CapTP and none on the concurrency control. In preparing the talk, I was quite happy when I drew http://www.erights.org/talks/captp4omg/captp4omg/sld019.htm to explain the concurrency control, though I never got that far in the talk. It's nicely complementary to the earlier slide http://www.erights.org/talks/captp4omg/captp4omg/sld012.htm , from the Ode, which I used to explain CapTP's security. So here's an attempt at a compact explanation of the distributed event loop part of E's concurrency control using this one slide. It doesn't say anything I haven't said elsewhere, but I do think it makes the picture as a whole clearer. This shows each vat as having an L-shaped data structure recording what remaining computations still need doing in that vat. The green blocks are stack frames, and the vertical tower of green blocks is the stack. As is traditional, the stack is shown upside down, with the top-of-stack at the bottom. The purple blocks are pending deliveries -- a record of the need to deliver a given message to a given receiver. The horizontal row of purple blocks is the pending delivery queue, ie, the event queue. Computation in each vat proceeds only at its current top-of-stack. An immediate call (".") pushes a new green block to the top of stack. Since "." can only be performed on a NEAR (intra-vat) reference, the green block gets added to the stack of the calling vat. An eventual send ("<-") enqueues a new purple block to the back of the event queue of the vat hosting the receiver. We see that Alice is currently executing in VatA, since VatA's top-of-stack points at her as receiver. In step (1), Alice executes "bob <- foo(carol)". In step (2) we see the result -- a record of the need to deliver "foo(carol)" to Bob is enqueued on VatB's queue, since Bob resides in VatB. Unshown is step (3), when computation in VatB advances till this record is at the front of the queue, whereupon it becomes the initial stack frame of a new stack, at which point Bob actually receives the message. The remaining major concepts of E's concurrency control are promises and pipelining, for which I use the graphic y'all have already seen http://www.erights.org/talks/captp4omg/captp4omg/sld020.htm (thanks Darius!). And the whole when/catch, __whenMoreResolved thing, which currently has no pictures but needs them. ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

1 0

Re: [Squeak-e] Draft Consensus Plan
by Anthony Hannan 10 Feb '03

10 Feb '03

"Mark S. Miller" <markm(a)caplet.com> wrote: > Do these points sound at all plausible? Does the twist sound like a good way > to proceed? Yes to both. I like it. Cheers, Anthony

1 0

Fwd: RE: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Mark S. Miller 10 Feb '03

10 Feb '03

I just realized that Dean's message may not have been accepted by the mailing list. Apologies if you see this twice. >X-Sender: agorics(a)postoffice.pacbell.net >X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 >Date: Sat, 08 Feb 2003 13:19:06 -0800 >To: "Mark S. Miller" <markm(a)caplet.com> >From: Dean Tribble <tribble(a)e-dean.com> >Subject: RE: [Squeak-e] Comments on Anthony's "...Shared Smalltalk" >Cc: Squeak-E - a capability-secure Squeak <squeak-e(a)lists.squeakfoundation.org> > > >This is a response to some comments about the importance of openness to >Smalltalk. > >One of the reasons I have not spent more time working on squeak and porting >older Smalltalk libraries and tools to Squeak is a confusion about openness >and malleability. > >Openness: > >One of the most wonderful things about a Smalltalk environment is that it is >open to inspection, modification, and extension by the developer. This >might be the single most important thing about Smalltalk. > >But it is *not* at odds with security. What is at odds with security is >confounding open-to-the-developer and >open-to-any-program-that-happens-to-be-nearby. I would like a Smalltalk >system that is open to *me* when it is running on my machine, but in which >the programs are not exposed to *each other*. (Indeed systems that try to >prevent me from seeing or manipulating things on *my* machine make me very >angry! :-) > >As MarkM says, getting back to the sense of *the developer* being able to >change anything while still preserving capability security could be >challenging. But it's a lot easier to get to a place where programs must >follow rules with each other, but development tools can get the access they >need easily. The general pattern is to replace primitives for getting >inappropriate access (e.g., instVarAt) with "closely-held" capabilities: >capabilities that are available only to a few programs, which ensure that >their use does not violate capability discipline or system integrity. > >Let's look at instVarAt: for example. It is primarily there to support >meta-level tools like inspecting and debugging. These are almost always >tools for developers, not programs. Replace instVarAt primitives with a >primitive capability that is closely held by the development tools. The >developer's tools then use that capability to look inside any object. >Normal programs don't have access to the capability, and so they cannot >violate arbitrary object encapsulation. The developer can decide to make a >new service that has that capability (e.g., an object serializer for >rewriting the Smalltalk image in a different format), but again that doesn't >mean the authority is available to the Web server. > >Malleability: > >Another important facet of Smalltalk's openness is malleability, the fact >that a programmer can change anything in the environment. Too often, people >confuse this with increasing flexibility in arbitrary dimensions, and >removing all barriers and modularity. As a result, it often seems at odds >with security. First, I'll give some examples of what I consider bogus >malleability in Smalltalk; the basic theme is that Juntas are a symptom, >not a solution. > >- When I'm refactoring the Browser, I don't want the browser I'm currently >using to break. I want to create a new version of the Browser, then try it. > >- I might want to (and have!) develop an entirely new user-interface >framework, possibly starting from the current one, without breaking my >development environment as I go. > >- At a non-gui level, I've changed the way that numbers decide on coercions, >without breaking the system. > >Doing that as Juntas just seems pointless and silly; I should be able to >produce a new system without breaking the old version. I want complete >control, without having my entire environment feel like it is made of mud >because it keeps changing out from under me (and yes, I'm exaggerating a >little for effect). > >I guess my point here is that one can have a system that is entirely >malleable to the developer, with the ability to add structured hooks >(closely held) to apply that malleability to new tools or techniques, >without having arbitrary malleability be a common element in the programming >environment. > >So the final claim is that Squeak-E could have the familiarity with >Smalltalk, with the differences only showing up for people that "open up the >hood", but those people will just open the hood in a slightly different but >still easy to understand place, and have all the power they could want. >This seems like a useful intermediate target (in the spectrum of security >targets) that would also be comfortable to the Smalltalk community. > >Comments? > > > > ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

1 0

RE: [Squeak-e] [goodie] SqueakElib released to squeak map
by Brent Vukmer 10 Feb '03

10 Feb '03

Rob -- You ought to edit the SqueakMap entry; right now it lists the URL for the asn1-encoding-dsa code as http://swiki.squeakfoundation.org/squeak-e/uploads/3/asn1-encoding-dsa.s ar instead of http://swiki.squeakfoundation.org/squeak-e/uploads/3/asn1-encoding-dsa.c s. Thanks for posting your work! Brent -----Original Message----- From: Robert Withers [mailto:rwithers12@attbi.com] Sent: Monday, February 03, 2003 5:07 AM To: Squeak-E - a capability-secure Squeak Subject: Re: [Squeak-e] [goodie] SqueakElib released to squeak map Ok, a few more tips. Once you have build the encrypted VatTP connection, you will have an inspector open on the VatTPCombinedProtocol. Go to that inspector and doit to self sendEMsg: 'hello world' in the transcript this should print out. That's it! ;-) It did get encrypted and send of course. For the CapTP there are no messages you can send but looking at the #session ivar is a good place to start exploring the structure. cheers, rob On Monday, February 3, 2003, at 04:35 AM, Robert Withers wrote: > http://swiki.squeakfoundation.org/squeak-e/3 > > sorry, no docs. > > enjoy! > > ps. you have to have the asn-encoding-dsa.cs changeset, loaded > > _______________________________________________ > Squeak-e mailing list > Squeak-e(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeak-e > _______________________________________________ Squeak-e mailing list Squeak-e(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeak-e

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Squeak-e February 2003