[ft-devel] endless loops in bytecode

[Werner LEMBERG]

Folks,


do you have any ideas how to discover endless loops in bytecode that
don't change the nesting level?  This would be very helpful for broken
or malicious fonts that can make bytecode interpretation very slow.

There are three instructions which can cause such loops.

  JMPR  (jump relative)
  JROT  (jump relative on true)
  JROF  (jump relative on false)

All three opcodes allow negative offsets; it's not documented in the
specification, but the MS interpreter disallows jumps to other
functions, and so does FreeType.  Here's the simplest possible endless
loop.

  PUSHW[1]
    -3
  JMPR

The PUSHW instruction pushes one word onto the stack (value -3), which
is the offset JMPR is using to jump back to the PUSHW position.

Currently, FreeType aborts bytecode interpretation after executing one
million instructions (this can be changed at compile time) – this
limit holds per glyph.  I wonder whether there are any suggestions how
to catch those three sneaky instructions earlier.

My only idea up to date is to count JMPR, JROT, and JROF separately,
using a threshold of, say, 10000.  Those instructions are very rare in
normal bytecode, and having so much jumps within a single function is
extremely unlikely.


    Werner