Émulateur SNES avec contrôle de permissions des plugins - Page 1

Bien le bonjour !

Dans le cadre de notre projet de fin d’études en informatique, nous sommes un groupe de 4 qui développons un émulateur Super NES avec un système de gestion des permissions pour les plugins. Ceux-ci s'exécuteront dans une VM en Rust, où des scripts Lua pourront interagir avec l’émulateur en respectant des droits d’accès stricts.

Chaque plugin pourra s’exécuter à des intervalles définis (par frame, par seconde, etc.) et sera répertorié sur un futur marketplace. L’utilisateur sera informé des accès demandés par chaque plugin via une pop-up.

L’objectif est de permettre à la communauté de créer et partager des plugins tout en garantissant un environnement sécurisé.

- Si vous pouviez développer un plugin pour un émulateur SNES, ce serait quoi ?
- D’un point de vue sécurité, quelles permissions devraient être essentielles ou interdites pour éviter les abus ?
- Et quelles fonctionnalités vous sembleraient indispensables pour améliorer votre expérience ?

On construit ce projet pour et avec la communauté, il s’étendra sur au moins 2ans et pourra être maintenu et amélioré à long terme, notamment grâce vous. Alors n’hésitez pas à nous contacter ici ou par mail : contact.rsnes@gmail.com

C'est quel genre de plugins que vous avez à l'esprit ?

Parce qu'autant ça peut avoir un intérêt pour (par exemple) un plugin qui permet de jouer en coop/versus avec quelqu'un en ligne, autant pour les fonctions de base (CPU, vidéo, son), ça paraît difficile : non seulement il y a un couplage fort entre eux, mais en plus il y a besoin de perfs, donc une VM n'est pas forcément un bon plan (en plus d'ajouter de la complexité).

Pourquoi également réécrire un émulateur from scratch, plutôt que de se baser sur l'un des nombreux qui existent déjà ? Je sais que c'est plus fun de le faire soi-même, mais la SNES est une console pas simple à émuler précisément (surtout en temps réel), vous risquez de passer beaucoup plus de temps que prévu rien que sur l'émulation elle-même.

Ça fait très académique comme projet ouais, mais ça doit être fun.

Dans l'ensemble je peux voir une utilité à des plugins qui ciblent une partie de l'émulation, oui. Le truc qui change tout, c'est de faire comme pour MasterBoy/Heig-Boy, c'est-à-dire que par défaut on ne touche pas au jeu (car effectivement dès que tu touches à n'importe quoi du hardware lui-même, ça a des effets domino). Le jeu est donc garanti de tourner parfaitement puisque rien ne change de son point de vue. Par contre on peut changer ce qu'on interprète du jeu en cours d'exécution : changer les instruments, changer le rendu des graphismes (comme dans mon cas où je rends en couleur les jeux Game Boy selon les instructions du script de colorization), la méthode d'entrée, enregistrer une vidéo, etc. et bien sûr on peut avoir des plugins qui touchent au jeu lui-même, comme par exemple les cheats (Game Genie), et là ça mérite une permission particulière.

La SNES effectivement je ne sais pas pourquoi vous avez choisi ça. C'est vraiment une console difficile à émuler, et ce que vous allez pouvoir en customiser risque d'être limité, mais ça doit quand-même être possible de faire des trucs fun

Merci pour vos retours !

Pour expliquer un peu mieux notre concept de plugin : il s'agirait de "simples" scripts en lua qui pourraient faire absolument tout et n'importe quoi. Lire / écrire à des adresses mémoire arbitraires, modifier les registres CPU, appuyer sur des boutons de la manette ou bien appliquer des filtres sur chaque frame entre le moment où le jeu a fini le rendu et l'affichage à l'écran. Au delà de ça, on voudrait même donner l'accès à des fonctionnalités de la machine hôte de l'émulateur : pouvoir manipuler des fichiers (créer, modifier, supprimer), lancer des requêtes sur internet pour récupérer des informations ou bien envoyer des données sur un serveur. Ce sont les idées qu'on a eues pour l'instant, ou pourra peut-être faire encore plus de choses à l'avenir (mais c'est déjà pas mal)

Le problème qui se pose avec tout ça, ce serait que des petits malins s'amusent à faire circuler des "plugins" qui suppriment la sauvegarde de l'utilisateur, ou bien pire, qui viennent lire des fichiers sur la machine hôte pour les envoyer sur internet et ensuite les supprimer de la machine par exemple. Ce serait vraiment pas cool de laisser passer ça. Notre solution serait que chaque plugin doit explicitement déclarer chaque permission qu'il demande, et l'utilisateur devra confirmer qu'il accepte de lancer le plugin après avoir lu les permissions demandées. On pourra bien sûr mettre des avertissements supplémentaires quand on remarque certaines combinaisons de permissions dangereuses (notamment fichiers + internet).
L'idée serait que le contrôle de permissions soit aussi granulaire que possible, pour permettre à un plugin par exemple qu'il veut seulement accéder à 1 fichier particulier, ou faire des requêtes internet à seulement certaines URL. On compte bien entendu faire la même chose pour les permissions "internes" (par rapport aux composants émulés) : Différencier les accès en écriture/lecture au CPU, à la RAM, aux inputs et aux outputs, et tout ce qui pourrait nous passer par la tête.

Et donc ensuite, pourquoi tout faire de zéro ? Comme vous le voyez, ça fait un gros bloc de fonctionnalités à ajouter que personne n'a encore fait sur le moindre émulateur ; et franchement, on a pas envie d'aller se plonger dans code source en C/C++ de tous les émulateurs existants qui sont assez vieux et pas forcément bien documentés techniquement. En plus, pour être sûrs de bien gérer nos permissions sur tout, on préfère avoir le contrôle sur toute la chaîne des composants, alors pourquoi ne pas tout faire nous-mêmes ? On pourrait aussi donner un coup de jeune en termes de technologies utilisées puisqu'on compte implémenter tout notre émulateur en Rust, un langage qui continue d'attirer de plus en plus de développeurs d'année en année et a une grosse communauté open source qui pourrait faire vivre notre projet longtemps après notre fin d'études.

Pour ce qui est des questions de performances quant à l'utilisation d'une VM, on parle bien ici d'une VM de langage de programmation et non pas d'une VM de système d'exploitation ; et donc au final, si on veut faire tourner des scripts en lua, il faut bien qu'il y ait une VM quelque part, donc de toute façon on a pas le choix.

Pour finir, par rapport au choix de la console, ce serait peut-être parmi les points qu'on peut changer si on se rend compte que c'est effectivement trop compliqué. Toutes nos fonctionnalités peuvent dans l'idée très bien s'intégrer pour d'autres consoles, et ce serait très intéressant de porter notre concept de contrôle de perms sur autant de consoles que possible.

Merci encore pour vos retours intéressants, on a hâte de pouvoir continuer à discuter avec vous

Ouais je vois, bon courage et tenez-nous au courant
Pour les consoles "faciles" mais avec quand-même plein de jeux cool il y a le Game Boy et la Master System. D'autres consoles comme La NES ça va mais difficile d'émuler une partie des jeux, qui se trouvent souvent être les plus intéressants (mappers, comptage de cycles fréquent).
Après une fois que l'on connaît le principe, la SNES n'est pas nécessairement SI différente et si difficile, du moment qu'on met de côté les chips spéciaux. C'est juste un angle d'attaque plus aigu.
Et si on met de côté le son (mais à mon avis c'est pareil pour la SNES), la Mega Drive est une console avec une architecture propre et facile à émuler, même si ça fait quand-même 2 CPUs différents (mais la majorité des jeux vont tourner sans le Z80, et les 2 CPUs sont très bien documentés donc top pour un projet académique, car vous pouvez par exemple leur faire exécuter une test suite faite pour les ordios de l'époque, plutôt que directement lancer les jeux et vous demander pourquoi ça plante).
Dans tous les cas c'est bien de choisir une console dont vous êtes passionnés, ça offre une grosse motivation, surtout quand vous allez devoir déboguer les jeux eux-mêmes et comprendre ce qu'ils font pour trouver pourquoi ils sont mal émulés. Si c'est des jeux que vous adorez, vous allez comprendre les décisions des développeurs, les limitations, et non seulement c'est passionnant, mais ça vous fera sûrement les aimer encore plus

Alors sans vouloir casser l'ambiance, autant c'est un projet intéressant sur le plan conceptuel, autant imaginer que l'utilisateur moyen d'un émulateur va se préoccuper des permissions (et comprendre leurs implications) me semble relever du doux rêve . Il suffit de voir ce qui se passe avec les applis mobiles...

L'autre souci lié, c'est que, que vous le vouliez ou non, vous serez en "concurrence" avec tous les autres émulateurs existants. Si on regarde objectivement, les critères habituels du choix d'un émulateur plutôt qu'un autre sont généralement :
1) les performances. Là-dessus, je doute que vous soyez meilleurs que les autres, parce que le système de permissions et d'extensibilité va forcément avoir un coût : non seulement ça prend du temps CPU, mais ça va aussi vous empêcher d'utiliser certaines optimisations.
2) la précision de l'émulation. Ça va être difficile de faire mieux que des émulateurs qui ont des années de décorticage des cas tordus derrière eux, et dont certains essaient même d'être cycle-accurate.
3) les fonctionnalités annexes. Vous partez de zéro, donc il y a tout à construire...

À noter que la sécurité est un critère qui n'est presque jamais pris en compte. On peut penser que c'est un tort, et j'aurais tendance à être d'accord avec ce point de vue, mais on ne peut pas forcer les gens à s'intéresser à quelque chose qui ne les intéresse pas. Donc si vous êtes meilleurs sur un critère considéré comme accessoire, mais moins bons sur les critères principaux, vous risquez de ne pas attirer grand-monde. Les esprits chagrins vous diraient que ça ne sert à rien de concevoir un système de permissions super-évolué si au final, personne à part vous n'écrit de plugins pour votre émulateur.

L'autre problème de vouloir permettre aux scripts de tout faire, c'est que ça va nécessiter des hooks absolument partout dans le code, et une liste de permissions interminable (surtout si vous voulez que ce soit granulaire, plutôt que d'avoir des catégories générales). Autrement dit, un gros risque de travail titanesque qui débouche sur une usine à gaz.

Maintenant que j'ai fini de vous casser le moral, quelques conseils quand même :

- ne mettez pas trop d'attentes dans ce que pourrait apporter la communauté, parce que même avec le meilleur projet du monde, c'est complètement imprévisible (et parfois/souvent cruel : indifférence, critiques négatives, personnes qui promettent des choses qu'elles ne feront jamais...). Faites d'abord le projet pour vous-mêmes.

- plutôt que d'essayer de "vendre" un concept abstrait, imaginez et implémentez une feature qui n'existe pas sur les autres émulateurs, et qui ait de l'intérêt pour les joueurs. Non seulement ça donne une raison de s'intéresser à votre projet, mais en l'implémentant, ça vous fera aussi découvrir des éventuels points faibles de la conception qui ne sont pas forcément apparents à priori.

- si vous pouvez avoir quelqu'un d'extérieur à l'équipe qui travaille sur son plug-in (peut-être un autre étudiant ?), c'est encore mieux : ça vous permettra de détecter ce qui est évident pour vous mais pas forcément pour les autres, de recueillir des cas d'utilisations/contraintes/suggestions auxquels vous n'aviez pas pensé, etc.

- n'hésitez pas à revoir à la baisse vos ambitions si vous vous rendez compte que vous allez vers une impasse (ou quelque chose de trop ambitieux compte-tenu de vos contraintes), ou simplement à dire "on fera ça plus tard". C'est toujours plus motivant d'avoir quelque chose qui tourne, même si c'est très incomplet, qu'un magnifique design qui reste sur papier parce que la motivation n'est plus là. Et on ne peut pas bêta-tester quelque chose qui ne tourne pas.

En tout cas, je suis certain que quelque soit le déroulement du projet, vous apprendrez beaucoup de choses -- y compris des choses que vous n'aviez pas prévu. Bon courage (et désolé pour le pavé de texte).