[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-smalltalk] Re: ObjectSpaces
From: |
Paolo Bonzini |
Subject: |
[Help-smalltalk] Re: ObjectSpaces |
Date: |
Thu, 21 Oct 2010 14:46:09 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100907 Fedora/3.1.3-1.fc13 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.3 |
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