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
On Sunday, February 9, 2003, at 09:45 PM, Mark S. Miller wrote:
Do these points sound at all plausible? Does the twist sound like a good way to proceed?
Certainly! I also like it. We'll create a backyard garage in which we can tinker with the Squeak-E engine.
cheers, rob
Mark S. Miller squeak-e@lists.squeakfoundation.org said:
Do these points sound at all plausible? Does the twist sound like a good way to proceed?
Well, apart from disagreeing that there's a 'twist' at all (I think it's the most logical and plausible thing to do), I agree 100%.
I was going to run off to the Swiki and put your mail on it as 'this is what we are going to do', but Rob beat me to it :)
Mark,
Do these points sound at all plausible? Does the twist sound like a good way to proceed?
I think that's an excellent way to proceed. It acknowledges the community factors and allows Squeak-E to evolve even in the absence of "full builtin tool support". I think that an important factor is that many people who may want to use Squeak-E will not care the least bit about whether the debugger is in Squeak or in Squeak-E. What I think they will be interested in is essentially whether a) their "runtime" is secure (which we will assume for the Squeak-E kernel) b) whether they can make use of the existing base in some form (which they can provided the interfaces have been exposed - and this will hopefully encourage people to work in this area) and c) whether it is possible to "use a Squeak-E app" from the regular Squeak base. Given all of this, Squeak-E provides an excellent "middle ground" between Squeak's fully reflective (and highly unsafe) environment and a less open yet secure environment. Defining Squeak to be part of the TCB seems exactly right to me - the relation between Squeak-E and Squeak can (for the time being) be very similar to that between Squeak and the VM itself. In both cases, the less secure operations are expressed on the level beyound; it is, for example, the VM that does array bounds checking, and which hides the notion of "pointers" from Squeak and similarly Squeak could have the notion of using "instVarAt:" or similar operations whereas Squeak-E may not (or not easily).
Cheers, - Andreas
-----Original Message----- From: squeak-e-bounces@lists.squeakfoundation.org [mailto:squeak-e-bounces@lists.squeakfoundation.org] On Behalf Of Mark S. Miller Sent: Monday, February 10, 2003 3:45 AM To: Squeak-E Subject: [Squeak-e] Draft Consensus Plan
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
Squeak-e mailing list Squeak-e@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeak-e
"Mark S. Miller" markm@caplet.com wrote:
- 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.
Yeah, this certainly sounds like the way to go. I did so with Islands, and if I understand correctly you have done so with E. I developed everything in regular Squeak, but could create little sub-Squeaks within the main one that were restricted. The main point was that final code would run securely; it's not so important that you can develop that code in the secure environment.
Incidentally, I still got rid of all the powerful methods in Object by moving them to ObjectInspector, which is a global in the SystemIsland. This is what Dean described. I am suspicious of having multiple name spaces, etc, because now you have different methods being invokable by different parties. This sounds ACL-ish, and at any rate seems complicated. It is a nice simplification, if we can manage it, to let people invoke any method at all on an object they have a reference to. I'm not sure we need to give this up in order to embed a safe-Squeak inside Squeak. For example, I didn't for Islands.
-Lex
squeak-e@lists.squeakfoundation.org
-
Andreas Raab -
cg＠cdegroot.com -
Lex Spoon -
Mark S. Miller -
Robert Withers