> >ALL Linux 2.0 does is recognise class files and run the java
> >interpreter on them. This is a tiny bit of code, and it basically
> >means Java has the equivalent of the
> >#!interpreter
> This is the only intelligent way of supporting Java in the kernel.
>Actually, that's far from "the only intelligent way of supporting Java
>in the kernel". Having a safe interpreter for Java directly in the
>kernel would be very useful in itself. Currently, things like IP
>routing, user-defined file systems, and file system namespace
>manipulation are supported by a lot of special purpose code in the
>kernel. If you could load executable code without having to worry
>about safety and security, those things could be both more efficient
>and more flexible.
provide a reasonably virtualised machine. Linux ptrace(2) already
allows you to trap at each syscall entry and exit and the tracer can
then disallow unsafe syscalls. Opening files, network connections and
so on can be redirected by libc (or a library further up the preload
path than libc) and communicate with a manager process down an
already-open file descriptor. If it decides to let you open the file,
it sends the new file descriptor down the socket to you. So even
without additional kernel support, you can get a system in which you
can run any potentially-* binary that you like (whether that's
Java or not) and trap attempts to break out (and even go a long way
to avoiding some denial of service attacks). With the additional
kernel support of a per-process syscall mask you can do even better
(since ptrace mucks around with the process hierarchy a bit).
--Malcolm
--
Oxford University Computing Services
"Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee