Linux Running in a PDF

Original Article ↗ Hacker News Discussion ↗

Novelty and limitations of Linux-in-a-PDF

  • Commenters find the project amusing and impressive: Linux (and even vi) running inside a PDF via a RISC‑V virtual machine.
  • Many jokes about running Doom (and DOOM Emacs), recursive “Linux.js in a PDF in a browser in Linux…”, and tongue‑in‑cheek ideas like “proxmox.pdf” and “mobile Kubernetes cluster” on a USB stick.
  • Some note that, despite the headline, it’s effectively “Linux in a PDF in Chromium,” since the file only works in Chromium-based browsers and not in Adobe Reader, Firefox, Evince, Safari, or typical printer workflows.

Runtime environment: Chromium, JavaScript, and VMs

  • The implementation relies on JavaScript execution inside PDF, which is well-supported by Chromium’s PDF engine but not consistently elsewhere.
  • People connect this to earlier “code in PDF” exploits: Tetris, Doom, Z‑machine interpreters, and other PostScript-based hacks.
  • There’s discussion about Turing completeness: PostScript is Turing-complete, but PDF only includes a restricted subset; later, JavaScript was added, reintroducing full programmability.

Security concerns and attack surface

  • Several commenters highlight that PDFs are a long-standing malware vector, especially with complex interpreters (JS, PostScript) and large, vulnerable codebases like Acrobat and Ghostscript.
  • Some suggest turning off scripting in viewers (e.g., a specific Firefox setting) or converting PDFs through Ghostscript or to formats like DjVu or OpenXPS.
  • Others warn that Ghostscript itself is risky on untrusted input and should be sandboxed (e.g., containers, gVisor).
  • One person notes VirusTotal flags this PDF with a few detections, though the significance is unclear.
  • There’s speculation about future attacks as LLMs begin “ingesting” PDFs with embedded active content.

PDF viewers, UX frustration, and alternatives

  • Strong dislike for modern Adobe Reader: AI assistant overlays, cluttered UI, and perceived hostility to simple reading.
  • Users mention Sumatra (including portable builds), Okular, built-in browser viewers, Edge’s PDF support, MuPDF, and mobile readers.
  • On locked-down systems, executable viewers are often blocked while PDFs are allowed, making “PDF as app platform” oddly attractive.

“Because you can” vs. usefulness and accessibility

  • Debate over whether such stunts are a waste of time versus valuable curiosity-driven exploration and security education.
  • Some lament “dynamic PDFs” that are just shells for JS-loaded web content, calling them anti‑PDF: worse for accessibility, longevity, and screen readers, which often see only a “Please wait…” placeholder.