Re: Another use for Guile/Scheme/Lisp

[Jim Blandy <jimb@red-bean.com>]

> > People periodically propose operating systems based on safe languages;
> > Java is the latest craze.  The best objection (in my opinion) is the
> > one you raise here --- that users will often be able to leverage bugs
> > in the compiler or runtime into security holes.  The compiler, at
> > least, is a very complex piece of code, so it's quite plausible that
> > it would have bugs.
> 
> The way you write this misleadingly suggests that Java security
> depends on the compiler.  It doesn't.  It depends on the *verifier*,
> which does an analysis of the bytecode, normally when a class is loaded.

Well, Java systems that want both the portability of bytecode and
performance involve two compilers: first, the source->Java VM
compiler, which is not trusted, as you say.  Second, the Java
VM->native code compiler.  The second one is certainly trusted, and
bugs in that compiler could certainly open security holes.

Some people (not you, Per) seem to assume that bytecode->native code
is somehow a simpler process than source->native code; it's not, at
all.  All serious optimization occurs in that step, which is where
bugs are often introduced.  Even the front end isn't simpler: the
verification process is easily as complicated as any source code
compiler's typechecking phase.