dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]SEE and interaction with vm's


From: Rhys Weatherley
Subject: Re: [DotGNU]SEE and interaction with vm's
Date: Wed, 03 Jul 2002 20:06:13 +1000

Gopal V wrote:
> 
> If memory serves me right, Gerard Toonstra wrote:
> > The plugin contained the vm entirely, linked statically, but starting it
> > up it already dumped core at the first initialisation method. gdb
> > revealed this was related to stack problems.
> 
> To put in the scenario in full perspective we got a coredump in the
> along the call to GC_Init().. and it seemed funny that way ..

The libgc library has some funny initialization requirements
when shared libraries are involved.  It will probably be
necessary to compile the entire stack, including libgc and
the engine, as .so.  Statically linking it into a .so will
probably not be sufficient.

I'll put shared library enablement on my TODO list.  I've
put it off because it can be a pain to execute the tools
when they haven't been "make install"'ed yet.  For example,
pnetlib can be built even if you haven't installed the
pnet distribution yet, by picking the binaries out of the
pnet build tree.

> The produces another question .... how sandboxable is pnet currently ...
> ie can we implement a secure VM using Portable.Net . This follows the
> concept of fork & exec which simplifies SEE to checking the sig/PKI
> and forking the appropriate VM ...

There two different levels of security: memory safety and
environment safety.

The first is managed vs unmanaged (or safe vs unsafe).  It is
possible to load an image (i.e. a program) with the flag
IL_LOADFLAG_INSECURE.  This will stop it from using unsafe
pointer operations, internalcalls, PInvoke, etc.  (Note: the
libraries like mscorlib can still use internalcall and PInvoke,
but the application itself can't).

The second is related to controlling access to operations on
files, sockets, etc.  This is where SEE access permissions
and ECMA-compatible CAS-based security are likely to come
into the picture.

The engine already implements the first (modulo bugs of
course), but not the second.  I have CAS on my TODO list,
and it should be easy to interface CAS to SEE once we
have it.

Cheers,

Rhys.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]