Deterministic Fully-Static Whole-Binary Translation without Heuristics
arxiv.org
We present Elevator, the first binary translator that statically translates entire x86-64 executables to AArch64 without debug information, source code, or assumptions about code layout. Unlike existing systems, which rely on heuristics or runtime fallbacks to handle code-versus-data decoding errors, Elevator considers all possible interpretations of every byte and produces a separate translation for each feasible one ahead of time. Any byte may be interpreted as data, an opcode, or an opcode argument; we generate separate control flow paths for all interpretations, pruning only those leading to abnormal termination. Translations are built by composing code "tiles" automatically derived from a high-level description of the source ISA, yielding a nimble translation framework. The approach is deterministic and produces complete, self-contained binaries with no runtime component in the trusted code base. The principal cost is substantial code size expansion. The key benefit is that the output is the actual code that will run, enabling testing, validation, certification, and cryptographic signing prior to deployment, reducing risk compared to emulators or JIT compilers. We evaluate Elevator on a diverse corpus of real-world binaries, including the entire SPECint 2006 suite, demonstrating that static full-program binary translation can be both reliable and practical. Elevator achieves performance on par with or better than QEMU's user-mode JIT emulation.
  • kibiz0r@midwest.socialEnglish
    22 days

    Elevator achieves performance on par with or better than QEMU’s user-mode JIT emulation.

    QEMU is a weird pick here. Why not FEX?

  • HaraldvonBlauzahn@feddit.org
    21 days

    I think there will be cases that do not work. For example, default memory access semantics of multi-threaded code are different for x86 compared to ARM - the code likely contains assumptions that are not valid on ARM.

  • ExperimentalGuy@programming.dev
    22 days

    What’s the point of this when you can compile between ISAs using a build tool and source? When would you need to cross compile a binary after building?

    • jdr@lemmy.ml
      22 days

      Because you don’t have the source or because you can’t configure the cross-compiler

        • qaz@lemmy.worldEnglish
          21 days

          E.g. when you have a proprietary program that is only available on x86, but you want to run it on ARM.

        • dev_null@lemmy.ml
          21 days

          Most software most people run is closed source and doesn’t have an arm version. Isn’t this the usual situation? Aunt Flo isn’t recompiling her tax filing software for arm. She just runs it, and it works because the arm laptop she has came with this built in.

        • HaraldvonBlauzahn@feddit.org
          20 days

          Easy to explain: The idiot project manager skipped to set up source control, and the sources have been lost.

        • jdr@lemmy.ml
          21 days

          I’m not talking about closed source software (heaven forfend!) but maybe you don’t have network access, or you don’t know what version you have or something. Sometimes even the best of us end up with binaries of unknown provenance that still must run.