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. _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
