[Help-smalltalk] Re: ObjectSpaces

[Paolo Bonzini]

On 10/21/2010 01:49 PM, Gwenaël Casaccio wrote:
> Concerning the ObjectSpace model and its interaction with Smalltalk
> I was wondering if we could not be inspired by the microkernel:
>
>   - a service for process management
>   - a service for the classes
>   - a service for security
>   - a service for the filesystem
>   - ...

Hmm, security, process management and some kind of object system are the 
main three responsibilities of the microkernel.

> 1) sharing model:
>
> We can give to the OS a complete environment with the classes. There is
> a stupid problem with subclasses (Object subclasses should only give you
> your  subclasses) and also what happens if you change the class format or
> method dictionary.  May be kind of VirtualClasses are a nice model for that
> kind of work. Or maybe it is another way to manage classes
>
> And off course in a shared model it should be possible to create a fully
> sandboxed environment.

In a shared model it will be _very hard_ to have a sandbox though.  It's 
very easy to make things leak from the "outside world".

> 2) we don't share:
>
> If we don't share each OS has its own full environment for me the problem
> is what happens if we want to communicate, that means that we share at least
> the symbol without that any try to send a message to another space will fail.

Yes, some things should be shared, but it should be the bare minimum. 
Some classes in particular must be shared (SmallInteger, Float, Symbol, 
UndefinedObject, etc.) and also some objects (Processor, nil/true/false, 
the symbol table; Smalltalk can be always the first object in the object 
memory).  We should remove hard-coded references to _gst_xyz_class as 
much as possible.

Some primitives can simply be disabled when running untrusted.  In other 
cases, dangerous classes simply should not be shared.  This way, a safe 
FileStream can simply be a proxy to the "real" FileStream in the parent 
OS, with security checks interposed.  A lot of C code is removed from 
the attack surface this way.

IMO, it's up to the parent to decide whether to share.  It can go from 
"as little as possible" (sandboxed browser) to

> In term of security sharing classes or not change nothing

Security is not only about crashing the VM, it's also about exploiting 
the privileges of the parent OS (which is also more interesting if you 
actually want to do something to the host).  The attack surface is much 
larger when the parent OS is entirely visible to the child OS.

> These points are just ideas, I like the idea of virtual classes, in
> fact with the OS
> environment we don't really need them. There will be a service which stores some
> classes and when we build a new OS we will asks that service and it
> will copy the
> classes and link them with the kernel classes (which are R/O and should stay R/O
> for most of the users)

I think you're running too fast. :)  Looks like an excessive amount of 
abstraction.

You should make a list of possible uses for OSes, with their minimal 
required feature set (which communication model? what are the security 
implications? etc.), and try to define something that fits all of them. 
 It should also fit the VM by the way. :)

From the VM point of view, all I know right now is that there's a lot 
of work that can be done now to limit the VM's knowledge of the system. 
 This is a useful improvement anyway.

> For the sandbox mode we should be careful because this is not because we have no
> access to external ref that the system is safe:
>
>   - create bad formatted cmpMethod, classes

For CompiledMethods there is a verifier.

>   - thisContext become: nil
>   - thisContext parentContext: thisContext

Sending methods to thisContext should be forbidden in an untrusted 
environment.

Making more validity checks on contexts (when sends are made to 
thisContext) or #become: is a good thing anyway.  There's no reason why 
the VM should allow (some kinds of) cross-shape #become:, or #become: 
that may cause out of bounds instance variable accesses.  #become: in 
fact has the same power as #changeClassTo:, because it allows to run a 
method compiled for class A with a "self" compiled for class B.

Even with this, there are a lot of problems remaining.  For example we 
should add a recursion limit and make sure it handles stuff such as:

Eval [
    x := {#perform:withArguments:. nil}.
    x at: 2 put: x.
    nil perform: #perform:withArguments: withArguments: x
]

which creates no contexts but still overflows the C stack.

>   - finalization is dangerous too

Why?

>   - primitives should be restricted : ObjectMemory quit :D

Yes, untrusted contexts cannot access primitives in new methods, and the 
parent can control the primitive methods before starting the child.

>   - memory ressource

You mean CObject?  That's just primitives as well.

Paolo