[Squeak-e] Draft Consensus Plan

Andreas Raab andreas.raab at gmx.de
Mon Feb 10 10:51:32 CET 2003


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 at lists.squeakfoundation.org 
> [mailto:squeak-e-bounces at 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 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeak-e
> 



More information about the Squeak-e mailing list