You are still sand-boxed even if you convert to native code. A naive
conversion to native code such as done by the TYA Java JIT-compiler
achieves significant speed improvements over interpretation.
An alternative if you want even better performance is to look into
Proof-Carrying-Code which means that instead of having a JIT in the
kernel, you have a proof-verifier. Instead of byte code you use
native code with an accompanying proof. The proof shows that the code
has no side-effects beyond the defined ones. This has been used to
implement packets-filters in (research) kernels.
> What I was thinking of is something like the packet filtering used by
> CheckPoint FireWall-1 (not available for Linux AFAIK); this involves a
> kernel module which implements arbitrarily complex (limited by memory
> assigned for bytecode and table storage) stateful packet filters. It runs
> bytecode. (For those who've seen FW-1, the things you can do with their GUI
> filter editor are a subset of its full capability; you have to write
> low-level INSPECT code to use its full power. INSPECT is *not* a simple
> language to work with, though, which is why I was thinking of more normal
> languages such as Java or Icon.)
>
> BPF doesn't appear to be capable of supporting all of the capabilities of
> this kind of filter, even ignoring the "stateful" part.
>
US citizens might want to look into their "byte-code-in-the-kernel"-patent.
astor
-- Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway http://www.guardian.no/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html