Lorito bytcode security vs jittability

Peter Lobsinger plobsing at gmail.com
Thu Mar 11 04:57:10 UTC 2010


As far as I understand Lorito, some of the desired outcomes are a high
degree of control over what actions can be taken (security by ops
validation) and ease of JIT (by using lower level operations). As I
see it, these somewhat run counter to each other. JIT wants simple
low-level ops; bytecode validation wants ops that represent behaviours
(that can then be declared safe or malicious). As operations become
lower level, it may become difficult to distinguish safe actions from
unsafe actions.

As an example of low level ops, say filehandle read is implemented
using a syscall op. There may be cases when we cannot tell at a Lorito
level that the syscall is always a read (as opposed to something more
invasive like unlink), even though the HLL or developper may be able
to guarrantee this.

As another example, say we want to restrict access in a sandbox to a
handfull of objects. If Lorito permits pointer arithmetic, it could
become very tricky to guess where things will wind up pointing.

Both of these examples leave us in a bad situation: either permit
possibly unsafe operations, or explain to users what hoops they have
to jump through to get their bytecode to validate as safe.

It would be great if we could somehow get low-level, easily jittable
ops and easily validatable ops at the same time. Striving for both, or
at least the right balance, is something we should probably be
thinking about when designing Lorito.


More information about the parrot-dev mailing list