[Top][All Lists]

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

Re: Virtual Machine in the abstract (was Re: [DotGNU]What languages sho

From: Rhys Weatherley
Subject: Re: Virtual Machine in the abstract (was Re: [DotGNU]What languages should DotGNU support?)
Date: Mon, 02 Dec 2002 20:39:43 +1000

Fergus Henderson wrote:

> Not necessarily.  I believe there are error-checking C interpreters
> around, that can provide safe execution of C code.  It's just that
> pnetC isn't one of them, AFAIK, and nor are any of the other C
> implementations that generate .NET IL.

I've played around a bit with making a sandboxed C VM in the past.
Long-time #dotgnu meeting attendees know it as the Jindalee probject.

The basic idea is to create a big chunk of memory (e.g. 8 Mb), and
hand it to the C program and say "this is your heap".  Pointer ops
are constrained so that the program can only read/write this chunk,
and nowhere else.  It can mess up the chunk any way it likes, but
it is shot in the head if it steps outside.

The managed GC heap and critical data structures that affect I/O
or platform security are not stored in this chunk, and so are
protected from program mischief.  It's kind of like the partition
between user space and kernel space in a Unix-like OS.

Some clever assembly hacks using segment selectors under i386 can
make this just as fast as regular memory operations, although
other CPU's do incur some additional overhead.

It may be possible to retrofit the Jindalee C sandbox into an IL
engine.  The trick is finding every place where a pointer may be
used by the program, the engine, or the support internalcalls,
and then redirecting it through the range-enforcing code.

I've thought about doing this for a while, but it is definitely
a post-0.5.0 thing.  It's not as easy as it looks.  But I think
it will be possible to build a "secure pnetC" that can run
arbitrary pointer-using code completely safely.



reply via email to

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