bytecode.texi

   1 @node Bytecode
   2 @section Bytecode
   3
   4 What is the most commonly used bytecode language in the world? Java
   5 (JVM Bytecode)? .NET (CLI)? Flash (AVM1/AVM2)? Nope. There’s a few that
   6 you use every day, simply by turning on your computer, or tablet, or
   7 even phone. You don’t even have to start an application or visit a
   8 webpage.
   9
  10 @strong{ACPI}
  11
  12 The most obvious is the large, gargantuan specification known as
  13 “ACPI”. The “Advanced Configuration and Power Interface” specification
  14 lives up to its name, with the most recent specification being a
  15 mammoth document that weighs in at almost 1000 pages. And yes,
  16 operating systems are expected to implement this. The entire thing. The
  17 bytecode part is hidden deep, but it’s seen in chapter 20, under “ACPI
  18 Machine Language”, describing a semi-register VM with all the usuals:
  19 Add, Subtract, Multiply, Divide, standard inequalities and equalities,
  20 but then throws in other fun things like ToHexString and Mid
  21 (substring). Look even further and you’ll see a full object model,
  22 system properties, as well as an asynchronous signal mechanism so that
  23 devices are notified about when those system properties change.
  24
  25 Most devices, of course, have a requirement of nothing less than a full
  26 implementation of ACPI, so of course all this code is implemented in
  27 your kernel, running at early boot. It parallels the complexity of a
  28 full JavaScript environment with its type system and system bindings,
  29 with the program code supplied directly over the wire from any device
  30 you plug in. Because the specification is so complex, an OS-independent
  31 reference implementation was created by Intel, and this is the
  32 implementation that’s used in the Linux kernel, the BSDs (including Mac
  33 OS X), and the fun toy ReactOS, HaikuOS kernels. I don’t know if it’s
  34 used by Windows or not. Since the specification’s got Microsoft’s name
  35 on it, I assume their implementation was created long before ACPICA.
  36
  37 @strong{Fonts}
  38
  39 After that, want to have a graphical boot loader? Simply rendering an
  40 OpenType font (well, only OpenType fonts with CFF glyphs, but the
  41 complexities of the OpenType font format is a subject for another day)
  42 requires parsing the Type 2 Glyph Format, which indeed involves a
  43 custom bytecode format to establish glyphs. This one’s even more
  44 interesting: it’s a real stack-based interpreter, and it even has a
  45 “random” opcode to make random glyphs at runtime. I can’t imagine this
  46 ever be useful, but it’s there, and it’s implemented by FreeType, so I
  47 can only assume it’s used by some fonts from in the real world. This
  48 bytecode interpreter also contained at one time a stack overflow
  49 vulnerability which was what jailbroke the iPhone in JailbreakMe.com
  50 v2.0, with the OTF file being loaded by Apple’s custom PDF viewer.
  51
  52 This glyph language is based on and is a stripped down version of
  53 PostScript. Actual PostScript involves a full turing-complete
  54 register/stack-based hybrid virtual machine based on Forth. The
  55 drawbacks of this system (looping forever, interpreting the entire
  56 script to draw a specific page because of complex state) were the major
  57 motivations for the PDF format -- while based on PostScript, it doesn’t
  58 have much shared document state, and doesn’t allow any arbitrary flow
  59 control operations. In this model, someone (even an automated program)
  60 could easily verify that a graphic was encapsulated, not doing
  61 different things depending on input, and that it terminated at some
  62 point.
  63
  64 And, of course, since fonts are complicated, and OpenType is
  65 complicated, OpenType also includes all of TrueType, which includes a
  66 bytecode-based hinting model to ensure that your fonts look correct at
  67 all resolutions. I won’t ramble on about it, but here’s the FreeType
  68 implementation. I don’t know of anything interesting happening to this.
  69 Seems there was a CVE for it at one time.
  70
  71 To get this article to display on screen, it’s very likely that
  72 thousands of these tiny little microprograms ran, once for each glyph
  73 shape in each font.
  74
  75 @strong{Packet filtering}
  76
  77 Further on, if you want to capture a network packet with tcpdump or
  78 libpcap (or one of its users like Wireshark), it’s being filtered
  79 through the Berkeley Packet Filter, a custom register-based bytecode.
  80 The performance impact of this at one time was too large for people
  81 debugging network issues, so a simple JIT compiler was put into the
  82 kernel, under an experimental sysctl flag.
  83
  84 As a piece of historical interest, an earlier version of the BPF code
  85 was part of the code claimed to be infringing part of the SCO lawsuits
  86 (page 15), but was actually part of BSD4.3 code that was copied to the
  87 Linux kernel. The original BSD code was eventually replaced with the
  88 current architecture, known as the Linux Socket Filter, in Linux 2.2
  89 (which I can’t easily link to, as there’s no public repository of the
  90 Linux kernel code with pre-git history, as far as I know).
  91
  92 @strong{What about it?}
  93
  94 The popularity of bytecode as a general and flexible solution to
  95 problems is alluring, but it’s not without its complexities and faults,
  96 with such major security implications (an entire iPhone jailbreak from
  97 incorrect stack overflow checking!) and insane implementation
  98 requirements (so much that we only have one major implementation of
  99 ACPI used across all OSes that we can check).
 100
 101 The four examples also bring out something interesting: the wildly
 102 different approaches that can be taken to a bytecode language. In the
 103 case of ACPI, it’s an interesting take on what I can only imagine is
 104 scope creep on an originally declarative table specification, bringing
 105 it to the mess today. The Type 1 Glyph and TrueType Hinting languages
 106 are basic stack-based interpreters, showing their PostScript heritage.
 107 And BPF is a register-based interpreter, which ends up with a
 108 relatively odd register-based language that can really only do simple
 109 operations.
 110
 111 Note, though, that all of these implementations above have had security
 112 issues in their implementations, with numerous CVEs for each one,
 113 because bytecode interpreter implementations are hard to get right. So,
 114 to other hackers: do you know of any other low-level, esoteric custom
 115 bytecode specifications like these? And to spec writers: did you really
 116 need that flexibility?
 117
 118 @url{http://blog.mecheye.net/2012/12/bytecode/}