- On considère généralement un fichier PDF comme un document statique, mais il inclut en réalité une prise en charge de Javascript
- La norme PDF dispose de sa propre bibliothèque standard Javascript
- Les navigateurs modernes comme Chromium et Firefox n’implémentent que des API extrêmement limitées pour des raisons de sécurité
- Seul Adobe Acrobat prenait en charge l’intégralité des spécifications Javascript dans les PDF, avec des fonctionnalités très étendues comme le rendu 3D, les requêtes HTTP ou la détection de tous les moniteurs de l’utilisateur
- Même avec les API limitées des navigateurs, il est possible d’exécuter la logique de calcul souhaitée, mais la partie E/S reste très restreinte
- Du code C peut être compilé en asm.js puis exécuté à l’intérieur d’un PDF
- Utilise une ancienne version d’Emscripten (comme la 1.39.20, qui prend en charge la cible asm.js)
- L’émulateur RISC-V TinyEMU a été modifié pour être compilé en asm.js, puis exécuté dans un PDF
- Le mode d’affichage et de saisie est identique à celui utilisé dans DoomPDF (faire tourner Doom dans un PDF)
- L’écran utilise un champ de texte par ligne, et l’état des pixels est représenté avec des caractères ASCII
- La saisie transmet les touches à la VM via un clavier virtuel et une zone de texte
- D’importants problèmes de performance apparaissent
- Exemple : le démarrage du noyau Linux prend environ 30 à 60 secondes, soit plus de 100 fois plus lent qu’une exécution normale
- Dans le moteur PDF de Chrome, le JIT de V8 est désactivé, ce qui dégrade fortement les performances
- Il est possible de choisir un système de fichiers racine pour 64 bits ou 32 bits
- Par défaut, le système Buildroot 32 bits est utilisé (repris de l’exemple d’origine de TinyEMU)
- Une version 64 bits d’Alpine Linux existe aussi, mais elle est environ deux fois plus lente et n’est donc généralement pas utilisée
4 commentaires
Une folie digne de Doom, Linux mdr
Est-ce du romantisme ou de la folie ? 😱
wow...
Wah......