[cap-talk] Security and Full Abstraction (was: Cap OS question)
Ben Kloosterman
bklooste at gmail.com
Sat Sep 5 00:02:17 PDT 2009
>
>Is there a strong reason to work with arbitrary JVML bytecode instead
>of Java source? If there is, perhaps you could consider an architecture
>that disassembles the JVML bytecode to Java source, verifies the source,
>and then recompiles the source to bytecode; this may have issues, but
>at least it bypasses the failures of full abstraction in JVML bytecode.
>From a single address space language based OS point of view it doesn't
really matter if a process crashes or even if it behaves strangely . The
only issue is ,if such an application can interact with other apps or the
kernel in an unsecure manner. Eg c type pointers to direct memory locations
overwriting code and data.
Basically once installed, the bytecode will be compiled to native (x86) and
compiled binaries will not be alterable ( except they can be removed by
de-installing the app) however any set of bytecodes or CIL (MSIL) is valid
and needs to be checked before compilation. The important thing is that the
generated x86 code cannot maliciously affect other apps or the kernel when
running in a single shared address space.
Regards,
Ben
More information about the cap-talk
mailing list