Namespaces, Serialization, Protected and/or Robust Execution Environments [was Re: Do we need OS?]

"Lex Spoon" <[hidden email]> wrote in message
news:[hidden email]...
Hi Lex,

I'm not really sure whereof you speak. The recent versions of VW all support
parcels, namespaces, and serialization facilities.

QKS Smalltalk has had namespaces, packages, and fully automatic
serialization with automatic schema-management for over seven years.

I can't speak for VW, but QKS Smalltalk implementations were pretty immune
to user mistakes or coding errors. The implementations have supported native
exception handling, thread respawning, and generally recovered from most
errors gracefully or shutdown gracefully in such occurrences. That recover
and keep running capability includes things like GPF's. The source
repository almost always was able to recover all work/resources in any kind
of situation (even full machine crashes caused by other applications).

Your item #2 is pretty well covered on a "real-os" with protected processes
where the goal is to protect against developer (user) errors. It does not
provide support for protection against malicious behavior. For that you
either need a trusted code model, or provide sandboxing facilities in the
form of execution/application domains.

I have not yet seen a Smalltalk VM that provided sandboxing facilities in
its execution architecture or its MOP. To provide that feature is a
significant technical effort and requires specific design features within
the package loader and the dynamic binding facilities of the VM
architecture.

However, if one uses the Microsoft.NET platform as the runtime target for a
SmallScript (Smalltalk) component (application) then you do get complete
security and sandboxing services. As you probably know, SmallScript is the
new language I've been developing since 1998 which includes a superset of
classic Smalltalk. The implementation of SmallScript (and thus Smalltalk)
for the Microsoft.NET Platform is the result of my ongoing (dynamic language
facilities) collaboration with Microsoft since 1999.

If you use Bistro (or possibly Mission Software's) Smalltalk for Java, then
you can gain whatever security model Java provides for those Smalltalk
cross-compilation systems. Bistro also has namespaces and presumably
supports enough reflection services to enable creation of a generic
serialization architecture.

SUMMARY:

a) Most everything you put in your list is in VW today. And has been in QKS
Smalltalk for close to seven years. I'm not knowledgeable enough about the
other dialects to make definitive statements as to their robustness (#2) or
their capabilities for generalized serialization w/schema migration support
(#3). But I do know that most of the other dialects do not have a complete
namespace system (#1) -- however facilities like Envy do provide nearly the
same functionality for VA and Dolphin.

b) Everything you put in your list is probably in Bistro (possibly also in
Mission Software's) Smalltalk for Java cross-compilers.

c) Everything you put in your list will be part of the SmallScript
solution/deployment facilities.

-- Dave S. [www.smallscript.net]

>
>
> Lex
>

"David Simmons" <[hidden email]> writes:
VW has #1.  It doesn't seem to have the others, in the form that I
mean.  And I don't know enough to say if VW's namespaces would work
well in the backbone of a Smalltalk OS.


On #2, processes below the Smalltalk level are not enough.  The point
is to have Smalltalk be your OS.  Thus, other processes should be
Smalltalk objects accessible from arbitrary processes.  Most
Smalltalks already have internal processes.  If these don't seem good
enough (I don't think they are), then it's worth thinking about how to
beef them up.


Sandboxes are completely doable, especially if you start from scratch.
Python has very nice sandboxes, for example.  The key observations are
that, first, you are building an interpreter and can enforce rules
strongly, and second, objects map very nicely to capabilities.



On #3, just *having* serialization is only the beginning.  I want to
be able to do things like "homeDirectory at: 'thesis' put: (Document new)"
and "(homeDirectory at: 'thesis') edit". I want some mechanism for dealing
with the compexity of large amounts of documents, and the technical problem
that the data will be much larger than physical RAM.  In short, I want
a filesystem of objects.



Overall, there are a lot of little problems to be solved.  I don't
think you can seriously point to any existing Smalltalk and say
"that's it.  Add drivers, and you have a usable OS."



-Lex Spoon

[hidden email] (Lex Spoon) wrote (abridged):
> Sandboxes are completely doable, especially if you start from scratch.
> Python has very nice sandboxes, for example.  The key observations are
> that, first, you are building an interpreter and can enforce rules
> strongly, and second, objects map very nicely to capabilities.

How is mutability dealt with? Does the trusted code have to make copies,
or something?

A classic Java scenario is when a String filename is passed (1) to a
security manager for vetting, then (2) to the low-level file open call.
It's crucial that the filename not be changed between (1) and (2). For
this were Strings made immutable and final.

In Smalltalk we could always pass our own subclass instead of a String,
so we could swizzle its content at almost any time. I imagine a sandbox
which protected the file system would have to copy the filename into its
own, trusted, class.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      [hidden email]      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

[hidden email] (Dave Harris) writes:


In short, yes, why not, it can just make copies or something.  :)  In
more detail....

I imagine that the "pore" classes which are at the boundary between
sandbox and the rest of the system, would have access to privilaged
functions such as "what class are you, really?".  A common idiom in my
prototype was to send #asInteger and then check the result with this
method:

        foobar: inputInteger
           | safeInteger |
           safeInteger := inputInteger asInteger.
           (!ObjectInspector classOf: safeInteger) == !SmallInteger
                ifFalse: [ ^self error: 'bad argument' ].


The #asInteger is optional, but it seems friendly.  #classOf: will
never lie, unlike #class, which can have been overriden!.  The $!
indicates a true global variable, we want the real SmallInteger and
ObjectInspector, and not whatever the local sandbox has in its private
SmallInteger variable.  (globals are a main difficulty in existing
languages, by the way!)


For string arguments, the easiest thing is probably to send
#asReadOnlyString and then check the result, just as above.  You want
to have ReadOnlyString around, anyway, so that string literals are
read-only.  Even if you want a mutable string, it's simplest to
convert to an immutable string, pass it across the boundary, and then
convert it back on the other side; operations right at the boundary
are tricky!


I've got a writeup of all this somewhere, and could probably dig it up
for anyone interested.  Heck, I could probably even dig up the
prototype, for anyone who wants to play with a system in such a rough
state.  To return to the point, though, this is possible in existing
Smalltalk implementations without any fancy theory; it should be much
easier in a new language or even a new implementation.

-Lex