Re: [Vrs-development] VRS development language

[Eric Altendorf]

These are also good points.  However, I was not actually talking about safety 
in terms of isolation of processes from the rest of the system.  That 
isolation may or may not exist depending on the VM, the underlying operating 
system, etc.

I was talking about the safety of the language in terms of the language's 
restrictions to keep you from shooting yourself in the foot.  This includes 
type safety, memory allocation safety, pointer safety, etc.  For example, in 
Java, there are no pointers so you cannot access or modify arbitrary areas of 
memory.  You don't have to explicitly free memory, so memory leaks are rare.  
Buffer overrun bugs are virtually nonexistant.  The main point is that using 
a safe language like Java or C# leads to much fewer bugs, and faster and 
easier development.  This is the point I wanted to make.

However, I'm glad you brought up the issue of safety in terms of security.  
Most security problems are due to bugs in the software, and the fewer bugs 
the software has, the more secure it will likely be.  In particular, buffer 
overrun bugs, one of the most common security flaws, generally just can't 
happen in Java or C#.

I recently looked at the security book that has been assigned to virtually 
everyone at Microsoft in their recent 2-month frantic security push (I assume 
you've heard about that).  That book extols C# for making obsolete many of 
the kinds of bugs that resulted in security flaws in the past....

Interestingly, one of the big differences between C# and Java is that Java 
completely eliminates pointers.  In C#, you can still declare blocks of 
"unsafe code" which use pointers.  If you never declare such blocks, you're 
safe, but the option is always there.  This may be a good or bad thing 
depending on the kind of software you're writing.

Eric 
 
On Saturday 27 April 2002 06:04, Bill Lance wrote:
> Hi Eric,
>
> You raise some interesting points.  As the existing
> docs emphasize, security and privacy are prime
> objectives with the VRS design.  And, as you observe,
> the implementation language has an impact on this.
>
> I am not a language expert, so if anything that I say
> here is wronge, please tell me so.  Java and C# are
> considered to be 'safe' mostly because they are
> executed in a VM rather than on the iron (or silicon
> as the case may be).  They are considered safe since
> they do not have direct access to the host comupters
> resouces, or to other processes running on that host.
> However, that security is only as good as the security
> of the VM itself.  If that comes from a third party,
> then we have a basic security breach.  Which leads to
> principle one:
>
> The VRS must be self contained.
>
> The purpose of a VM language is a good one, however,
> to create a operational sandbox.  We intend to do
> this, but with a different approach.  The idea is to
> run the entire VRS code system in it's own root
> system, using mkroot or userlinux.  In effect, the
> sandbox is extablished by host system configuration
> methods rather than with an interpretor layer.
>
> Now within that system level sandbox, there no doubt
> will be a variety of implementation languages, since
> most of the Service Manager module will be existing
> programs, such as apache, Pnet, and whatever else is
> needed to support net services.
>
> The parts that we are creating for cluster management,
> the body of the LDS, could be in any language, or mix
> of languages, as long as they ended up in complatable
> binary. One possible variation here would be to use
> the PNet VM that's already loaded with the VRS system
> to execute some of  the LDS functions in addition to
> netservice functions.  One part already established is
> the middleware infrastructure of Goldwater that Chris
> Smith is working on.  Chris is working in C.
>

-- 
"First they ignore you.  Then they laugh at you.
 Then they fight you.  And then you win."             -Gandhi