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

[Gopal V]

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 ..

> It was opened using dlopen() and we think this may be at the "core" of
> the problem. 

It is ... I eventually tried a small program that linked in the .so into
an executable rather than dlopen'ing ..

> Eventually myrddian entered the channel and confronted us
> why even running a plugin vm is a bad idea and that it should actually
> IPC with the SEE instead. (a vm dumping core for other reasons would
> also dump the SEE, which brings down all the runtimes together).

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 ...

It's the EASY WAY OUT (TM) 

> One of the methods immediately proposed was shared memory. If someone
> reads this and is convinced this is a really bad idea, please share your
> thoughts.

Well we do have to port SEE to various platforms ... like some OS like
systems sold by a particular software company ....

> Another method I am proposing and start to favour more is CORBA. Reason
> is mainly that it allows remote connectivity and the IDL is basically
> the contract of interactivity between SEE and vm, plus dev.time
> shouldn't take very long at all (no protocol implementations, just
> compile the IDL and implement 'what' it should do).

Which ORB ? .... and how portable would that be ? ... more importantly
how tough is CORBA in C ... My CORBA experiences have be ranged mildly
from disaster to catastrophe ...

Putting CORBA into a runtime VM really slows it down to unusable levels
or so it seems to me .. if every file access is checked via CORBA , I 
personally won't prefer such a system :-)

> 10. Only for future so far: remote accessibility of SEE.

Why is SEE a daemon ... (and only a daemon) ?

Shouldn't SEE be just the policy source for the VM ? (however that works) 

So like a double edged approach ... SEE *the daemon* accepts requests
and verifes the PKI or whatever and fork exec's the SEE enabled VM ..

SEE *the library* fetches the policy files and generates a permission 
profile for the current instance of the VM ... every VM has a linked 
in native security manager ... which is an abstraction of whatever 
the security level is ..stuff like

int SEE_CheckFileAccess(SEE_Profile *prof,char *path,char** error);

Which is embedded in a libSEE.a and when pnet is compiled as 
./configure --with-see=/tmp/dotgnu-see/see
(or ./configure --with-profile=see)

Or maybe libSEE dlopen's the plugins ... just like the Linux PAM does.
The libSEE does not need to worry about threading as it is just yet 
another function call in the runtime ... All the stuff it deals with
are non-GC'd , non-threaded (mutex'd) calls from the runtime ...

(the security layer may even be implemented in C# , but that would
 not be portable if DotGNU goes on to have more VM's)

IMO this is a middle path of the two approaches involved ... we've
been thinking the wrong way all the time ... ie integrating the runtime
into the SEE . Time we turned around and attacked from the other side.

This approach removes complicated IPC/CORBA ... and still protects SEE
the daemon from a SEGFAULT in the VM ....

The real issue is why we need a daemon now ? ie just ./ilrun_see will 
provide the permission side of life .. and ./ilrun is the ordinary VM.
(some more #ifdef's ;-)

So we have two VMs in one -- the regular ilrun and the ilrun_see
which are like the Java idea of  "java" and "appletviewer" ...

Obviously the DAEMON is only needed when we proceed to the DEE stage
of the DotGNU "experience" ....

Eventhough this is presented from the myopic angle of Portable.Net ,
I think that is the only VM DotGNU has CVS commit access to .. ;-)

Gopal

PS: if this doesn't make any sense to you , you're just about as confused
    as I am ...
-- 
The difference between insanity and genius is measured by success