I'm curious - how are you going to prove that addresses for the MOVinstruction are safe, using just a static pre-execution scan of thecode? If you only allow things that you can prove are safe, theneither you'll have a very large and complex verifier, or you'll end updisallowing interesting and useful cases.

The other alternative is to do runtime verification of addressses,which is much more straightforward (and it's also much easier to proveit's secure). But it does mean that you can't run the code as-is.

> It needs a verification pass (because the code can come from untrusted > apps) so that we can copy, verify and trust it (so obviously it's not > _arbitrary_ x86 machine code - a safe subset of x86) - maybe with a sha1 > based cache for already-verified snippets (or a fast verifier).> > > x86 is quite unpleasant.> > Any machine code that is fast and compact is unpleasant almost by > definition: it's a rather non-obvious Huffman encoding embedded in an > instruction architecture.

From the point of view of having to emulate or translate x86 code (aswe would have to do on powerpc), it's not the compactness that'sunpleasant, it's things like not being able to tell whether thecondition codes set by an instruction are ever going to be used. Manyx86 instructions set the condition codes but for most instructions thecondition codes that are set are never used. So when emulating ortranslating, you either waste time computing condition code valuesthat are never used, or you have to do complex lifetime analysis towork out which instructions do need to compute the condition codes.