[{"data":1,"prerenderedAt":48},["ShallowReactive",2],{"publications-liblisa-oopsla24":3,"papers-liblisa-oopsla24-07-discussion":32},{"id":4,"title":5,"authors":6,"awards":7,"bibtex":8,"body":9,"date":20,"description":15,"extension":21,"link":22,"meta":23,"navigation":24,"path":25,"pdf":26,"seo":27,"slug":28,"stem":29,"venue":30,"__hash__":31},"publications\u002Fpublications\u002Fliblisa-oopsla24.md","libLISA: Instruction Discovery and Analysis on x86-64","Jos Craaijo, Freek Verbeek, Binoy Ravindran",null,"@article{craaijo2024liblisa,\n  author = {Craaijo, Jos and Verbeek, Freek and Ravindran, Binoy},\n  title = {libLISA: Instruction Discovery and Analysis on x86-64},\n  year = {2024},\n  issue_date = {October 2024},\n  publisher = {Association for Computing Machinery},\n  address = {New York, NY, USA},\n  volume = {8},\n  number = {OOPSLA2},\n  url = {https:\u002F\u002Fdoi.org\u002F10.1145\u002F3689723},\n  doi = {10.1145\u002F3689723},\n  journal = {Proc. ACM Program. Lang.},\n  month = oct,\n  articleno = {283},\n  numpages = {29},\n  keywords = {instruction semantics, instruction enumeration, synthesis}\n}\n",{"type":10,"value":11,"toc":16},"minimark",[12],[13,14,15],"p",{},"Even though heavily researched, a full formal model of the x86-64 instruction set is still not available. We present libLISA, a tool for automated discovery and analysis of the ISA of a CPU. This produces the most extensive formal x86-64 model to date, with over 118000 different instruction groups. The process requires as little human specification as possible: specifically, we do not rely on a human-written (dis)assembler to dictate which instructions are executable on a given CPU, or what their in- and outputs are. The generated model is CPU-specific: behavior that is “undefined” is synthesized for the current machine. Producing models for five different x86-64 machines, we mutually compare them, discover undocumented instructions, and generate instruction sequences that are CPU-specific. Experimental evaluation shows that we enumerate virtually all instructions within scope, that the instructions’ semantics are correct w.r.t. existing work, and that we improve existing work by exposing bugs in their handwritten models.",{"title":17,"searchDepth":18,"depth":18,"links":19},"",2,[],"2024-10-20","md","https:\u002F\u002F2024.splashcon.org\u002Ftrack\u002Fsplash-2024-oopsla#event-overview",{},true,"\u002Fpublications\u002Fliblisa-oopsla24","\u002Ffiles\u002Fliblisa2024.pdf",{"title":5,"description":15},"liblisa-oopsla24","publications\u002Fliblisa-oopsla24","OOPSLA'24","d-2xqRiGEx9J763VU4sUFN1PvG_NX8MmqYk4AdsbW9Y",{"id":33,"title":34,"body":7,"date":7,"description":7,"extension":35,"html":36,"meta":37,"navigation":24,"next":38,"path":41,"previous":42,"seo":45,"slug":7,"stem":46,"__hash__":47},"papers\u002Fpublications\u002Fliblisa-oopsla24\u002F07-discussion.html","Discussion","html","\u003Cstyle>\u002F* Alignment *\u002F\nmtable.right-align mtd,\nmtable mtd.right-align,\nmtable.left-align mtd.right-align,\nmtable.aligned mtd:nth-child(odd) {\n  justify-items: end;\n  text-align: right;\n}\nmtable.cases mtd,\nmtable.left-align mtd,\nmtable mtd.left-align,\nmtable.aligned mtd:nth-child(even),\nmath:is(:not([display])) > mtable.multiline-equation mtd {\n  justify-items: start;\n  text-align: left;\n}\nmtable.cases mtd,\nmtable.aligned mtd,\nmtable mtd.flushed,\nmtable mtd.left-flush {\n  padding-left: 0;\n}\nmtable.cases mtd,\nmtable.aligned mtd,\nmtable mtd.flushed,\nmtable mtd.right-flush {\n  padding-right: 0;\n}\n\n\u002F* Tables *\u002F\nmtable {\n  math-style: inherit;\n}\nmtd {\n  math-depth: auto-add;\n  math-style: compact;\n  math-shift: compact;\n}\n\n\u002F* Equations *\u002F\nmtable.multiline-equation mtd {\n  math-depth: inherit;\n  math-style: inherit;\n  math-shift: inherit;\n  padding: 0;\n}\nmath > mtable.multiline-equation mtr:not(:last-child) mtd {\n  padding-bottom: 0.5em;\n}\n\n\u002F* Fractions *\u002F\nmfrac {\n  padding-inline: 0;\n  margin-inline: 0.1em;\n}\n\n\u002F* Accents *\u002F\nmover[accent=\"true\" i] > :first-child {\n  font-feature-settings: \"dtls\";\n}\nmover.dotted[accent=\"true\" i] > :first-child {\n  font-feature-settings: \"dtls\" 0;\n}\n\n\u002F* Other rules for scriptlevel, displaystyle and math-shift *\u002F\nmunder > :nth-child(2),\nmunderover > :nth-child(2) {\n  math-shift: compact\n}\nmunder[accentunder=\"true\" i] > :not(:first-child),\nmover[accent=\"true\" i] > :not(:first-child) {\n  math-depth: inherit;\n  math-style: inherit;\n  math-shift: inherit;\n}\u003C\u002Fstyle>\u003Cdiv id=\"previous-page\" style=\"display: none\">\u003Ca href=\"05-results#loc-1\">Results\u003C\u002Fa>\u003C\u002Fdiv>\u003Cdiv id=\"next-page\" style=\"display: none\">\u003Ca href=\"08-bibliography#loc-1\">Acknowledgements, Data-availabilty and References\u003C\u002Fa>\u003C\u002Fdiv>\u003Ch2 id=\"loc-1\">6 Discussion\u003C\u002Fh2>\u003Cp>We presented \u003Cspan style=\"font-variant-caps: small-caps\">libLISA\u003C\u002Fspan>, a tool for automated discovery of instructions executable on a given CPU, as well as synthesis of their semantics. At its core, \u003Cspan style=\"font-variant-caps: small-caps\">libLISA\u003C\u002Fspan> is based on fuzzing, which means that synthesis may produce incorrect semantics for an instruction. We evaluate that this happens for about three to seven instruction variants per run. This could be reduced by increasing the amount of random inputs that are generated, or by changing the distribution of the random numbers that are generated such that the rare cases are more observable. However, it is difficult to do this in a way that generalizes to any instruction. We argue that this is inherent to bottom-up derivation of instruction sets and their semantics. Without access to an oracle that provides a trustworthy and formal semantics of the entire instruction set of a CPU, \u003Cspan style=\"font-variant-caps: small-caps\">libLISA\u003C\u002Fspan> provides the most extensive and trustworthy formalization of the x86-64 ISAs to date.\u003C\u002Fp>\u003Cp>Trustworthy semantics are the base of any binary-level effort. For example, BAP \u003Cspan id=\"loc-2\">[\u003C\u002Fspan>\u003Ca href=\"08-bibliography#loc-29\" role=\"doc-biblioref\">28\u003C\u002Fa>] (Binary Analysis Platform) has – for the x86 architecture – a manually written translation from instructions into an intermediate language. They test their semantics against a CPU. It would be interesting to combine \u003Cspan style=\"font-variant-caps: small-caps\">libLISA\u003C\u002Fspan>’s semantics with BAP, reducing the trusted code base.\u003C\u002Fp>\u003Cp>We believe \u003Cspan style=\"font-variant-caps: small-caps\">libLISA\u003C\u002Fspan>’s approach would work on other modern general-purpose CPU architectures. Only the CPU observer is architecture-specific, and would have to be implemented from scratch for a new architecture. Architectures such as ARM or RISC-V would be suitable candidates. With these architectures, a bit in an instruction often also serves a single purpose.\u003C\u002Fp>\u003Cp>We ran our analysis on an Intel i9-13900 CPU, which was affected by the Reptar bug.\u003Csup id=\"loc-3\" role=\"doc-noteref\">\u003Ca href=\"#loc-4\">1\u003C\u002Fa>\u003C\u002Fsup> Unfortunately, the REP prefix is part of the instruction prefixes we consider out of scope (see Section \u003Ca href=\"02-overview#loc-7\">Section 2.2.1\u003C\u002Fa>). We argue that \u003Cspan style=\"font-variant-caps: small-caps\">libLISA\u003C\u002Fspan> would have discovered this bug if the REP prefix was considered in-scope. The main characteristic of this bug is that it causes non-deterministic output. This would be picked up upon during dataflow analysis, where the entire CPU state would be considered input. Such instructions (e.g., RDTSC or RDRAND) are flagged automatically because synthesis is known to fail.\u003C\u002Fp>\u003Cp>In \u003Ca href=\"05-results#loc-9\">Table 7\u003C\u002Fa>, there are around ten fewer disagreements with Dasgupta et al. on Intel CPUs than on AMD CPUs. This is because of the incorrect specification of undefined behavior in the RCLB\u002FRCRB variants. The behavior specified by Dasgupta et al. matches Intel’s implementation of this undefined behavior, not AMD’s. This highlights the importance of verifying specifications on multiple CPUs.\u003C\u002Fp>\u003Cp>We only discover and analyze userspace instructions. The primary reason for this is that the CPU observer needs to execute instructions in ring 3 (userspace) for sandboxing. It would be possible to analyze privileged instructions by implementing a CPU observer as hypervisor. Whether automatic analysis would be effective for privileged instructions is unclear. In userspace, we can reasonably assume that an instruction, for example, does not change CPU configuration, modify the page table base register PTBR or unmap memory. Our analysis depends on these assumptions. Significant, non-trivial modifications are needed to analyze privileged instructions.\u003C\u002Fp>\u003Csection role=\"doc-endnotes\">\u003Col style=\"list-style-type: none\">\u003Cli id=\"loc-4\">\u003Csup role=\"doc-backlink\">\u003Ca href=\"#loc-3\">1\u003C\u002Fa>\u003C\u002Fsup>\u003Ca href=\"https:\u002F\u002Flock.cmpxchg8b.com\u002Freptar.html\">https:\u002F\u002Flock.cmpxchg8b.com\u002Freptar.html\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fsection>",{},{"url":39,"title":40},"08-bibliography","Acknowledgements, Data-availabilty and References","\u002Fpublications\u002Fliblisa-oopsla24\u002F07-discussion",{"url":43,"title":44},"05-results","Results",{"title":34},"publications\u002Fliblisa-oopsla24\u002F07-discussion","h4Lb081VUZa6EqWvXShr6ogkNTWeAihGP-TueZR3olY",1787004871381]