squeak as a capability system
rwithers12 at attbi.com
Sun Jan 26 15:14:00 UTC 2003
Mark, you seem to be saying that we wouldn't have to change the vm, in
order to 'host' a capability language, and write an E-interpreter.
While that would be very interesting, my intension has been to
transform squeak itself into a capability language. This would
require some VM changes, to create opaque references, and MOP changes,
to handle the fact that Inspectors won't be able to look inside an
My motivation in suggesting separate segments (vats), was that squeak
should be able to host concurrent users. A vat, to my way of thinking,
was an authenticated space, in addition to having the concurrency and
persistent properties. A user with certain amount of authority could
create a vat, and be able to run with other vats in one image. Squeak
would then have a running system mode segment that could issue machine
resource capabilities to the hosted users. If a vat is attached to a
process and is this unit of persistence and concurrency, then it is
also the unit of exception handling and authentication. I may be
confusing TCB level security (secure communications platform - Trusted
Computer Base), with user authentication and security.
If we look at every reference as a capability, then taming squeak will
first involve taming each reference. If my implementation of your
eventual sending mechanism is to have any chance of becoming a more
broadly used feature, even if the implementation changes, then it looks
like there are really two library issues. First, get the rest of the
squeak library to handle asynchronous objects, and second, to make
sure the library is tamed for capabilities.
How should debugging in a secure environment proceed? Certainly I
don't want you looking inside of my objects, unless I give you that
capability. I would want to look inside of my objects and since I own
them, I should have acquired the MOP capability to look inside them.
I am rereading the ode
On Sunday, January 26, 2003, at 02:20 AM, Mark S. Miller wrote:
> What we did do is build a new language and virtual machine (Kernel-E)
> on top
> of Java. For this, Java's similarity to a capability system was
> For example, we have made a start on rebuilding the Kernel-E virtual
> in C++ and it has the same structure. Needless to say, Smalltalk would
> fine here. I see no further relevant differences at the virtual
> machine level.
More information about the Squeak-dev