[Mono-devel-list] Limiting Memory Allocation

[Jim Purbrick]

Hi Sebastien,

(Apologies for any confusion, I'm rationalising the
private and public conversations I've ended up having
with Sebastien and the list)

> So my big return question is "what's kind of 
> environment will you be supporting ?". The more 
> accurate your answer is, the more accurate mine
> can be ;-)

OK. It at _least_ needs to support user authored LSL
[1] scripts which migrate between servers along with
the virtual objects they are associated with [2][3],
can make calls in to the C++ virtual world system and
be called by the C++ virtual world system.

[1] LSL (http://www.sluniverse.com/lsl.html) already
compiles to CIL.
[2] Planned via bytecode translation (with Cecil?) a
la PicoThreads
[3] I need a way to unload code and JIT output on
migration.

If we get to that point, we'll have the same
functionality as the current implementation, but with
300 times the performance thanks to the Mono VM.

Stage 2 is to open it up to any language that targets
the CLR and allow access to (safe) framework classes.

> > Is there anything that can be done in the
> meantime?
> 
> Taking this as a "yes|no" question I can assure you
> the answer is: YES ;-)

Good :-)

> > Put extra checks in the bytecode translator?
> 
> Yes, it's possible to pre-check assemblies to ensure
> they only use class/methods from within the script
or
> from a "white list".

This sounds like a good approach for stage 1, as all
of the IL opcodes will have to be scanned to add the
thread serialization code, so checking that all method
calls are within the script or from a single library
class, shouldn't be too much more work.

> However this approach limit extensibility,
> existing code reuse...
> 
> > Remove dangerous bits of the framework so they
> > can't be called?
> 
> I'm unsure for your project but, in general, I don't
> believe this is a good approach. First the balance 
> (functionality/security) is hard to keep and
> even when something gets completed you risk having a
> very crippled result (functionality-wise), a still 
> insecure subset or (most probably) both.

I can see that as desired functionality is increased
either the white list or framework trimming approaches
provide diminishing returns and require more and more
effort.
 
> My (probably not very partial ;-) opinion is that
> both options requires a lot of efforts and time (not

> just to get there but to continue supporting it
> later). The same efforts could be invested in
> defining your security model requirements (well you 
> would need that anyway) and helping to complete CAS
> to match them.

It seems to me that the best approach would be to use
a white list approach for stage 1, where we're only
considering the very limited LSL language and library
calls, then jump straight to CAS for stage 2 where we
allow more complex languages and frameworks. 

Hopefully this would avoid the nasty middle ground
where we're expending large amounts of effort trying
to grow the white list approach which we could be
spending helping to complete CAS.

This is also nice in that we don't try to bite off
everything in one go, but can get the minimal ammount
working on Mono and then move on to the more ambitious
goals.

> But at this stage it's hard to guess when the payoff

> would be...

This is another reason to go for a simple
implementation first. I'd rather have a subset working
while we worked on completing CAS than have everything
potentially delayed.

(Now I just really need to find a way to unload
assemblies and JIT output when I'm done with them)

Cheers,

Jim.


		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com