NumWorks sort une calculatrice en 2017 révolutionnaire pour l'époque, sur différents aspects, que ce soit programmable en python, possédant une application probabilité avec une interface simplifiée, mais surtout, dans le contexte qui va nous intéresser, open-source et "libre" . Originellement, epsilon (le firmware "officiel" fourni via le site de numworks, et sur les calculatrices dès l'achat) était sous license Creative common BY-NC-ND, permettant à tout le monde de le modifier, de proposer des modifications, mais cependant, n'autorisant pas de firmware tiers.
Cependant, après une longue discussion, en 2018, Numworks décide d'autoriser les firmwares tiers, en passant sous Creative common BY-NC-SA. Ce changement de licence a permis l'apparition de firmware tiers et de logiciels, comme omega, ou khicas et autres logiciels.
critor t'a cependant annoncé que Numworks est revenu sur leur choix, en préférant limiter les possibilités de la calculatrice, afin de favoriser le développement à l'international. Dans ce poste, les changements, et les solutions techniques envisagés seront expliqués.
1) Le précédent fonctionnement
Go to topJusqu'à la version 16, epsilon (comme ses forks) était compilé sous la forme d'un seul gros binaire, contenant les drivers pour le matériel (le dossier Ion), les primitives graphiques (Kandinsky), de quoi faire des interfaces plus ordonnées (Escher), un moteur de calcul (Poincaré) et les logiciels utilisés par l'utilisateur lui même (Apps). Cette solution avait pour avantage d'être plutôt simple à concevoir (bien qu'elle aie nécessitée plusieurs années de développement), d'être simple à installer (un binaire à télécharger pour la n0100), et permettait à tout le monde de pouvoir créer son propre firmware. Cependant, elle ne garantissait en rien la conformité du mode examen, ce qui poussa Numworks à changer de solution.
Au boot, le microcontroleur lisait une table situé au début de la rom interne, contenant un pointeur vers le début du binaire à exécuter, qui était la crt0 (C runtime 0 = premier exécuté C), qui ne faisait rien d'autres qu'initier les drivers, puis commencer l'exécution réelle du firmware.
2) Le bootloader
Go to topÀ partir de la version 16 d'epsilon, le reset handler ne pointe plus vers un gros bloc de code, contenant tout ce qui était nécessaire, mais vers une partie nommée bootloader. Ce bout de code a pour rôle de vérifier si le kernel (qui est executé après) est valide (c'est à dire signé, et que sa signature est valide).
Il y a alors 2 situations possibles :
- Le kernel est signé, et sa signature est valide (ce qui se passe lorsque vous installez la beta) : le bootloader ne fait rien d'autre alors que de jump à l'entry point du kernel (= il lance le kernel).
- Le kernel n'est pas valide : le bootloader refuse alors de l'exécuter, et va se mettre en mode DFU (Device Firmware Update), afin de réécrire un kernel. En mode DFU, le bootloader ne peut réécrire que le kernel.
3) Le kernel
Go to topLe kernel est un bout de code bien séparé du bootloader (et du userland). Une fois executé, il va activer le MPU du microcontrolleur, et sera executé comme supervisor : c'est à dire qu'il aura accès à toute la mémoire, et pourra modifier à quelle zone de la mémoire le mode supervised pourra accéder. Il vérifie ensuite si le firmware est signé, et si sa signature est valide. Il y a donc deux cas de figure :
- L'userland est signé, et sa signature est valide (ce qui se passe lorsque vous installez la beta) : il mémorisera dans une zone de la RAM que le firmware est officiel, et permettra plus tard d'entrer en mode examen sans devoir recopier la copie du firmware officiel.
- L'userland n'est pas valide : il mémorisera aussi dans une zone de la RAM que le firmware n'est pas valide, empêchera au userland d'accéder à la LED et à chaque sortie de veille affichera une pop-up.
Il proposera au userland une "api" sous forme de syscalls (appelés par le SVC des ARM), et ne ferra rien d'autre lors de l'exécution après le bootloader que de faire la vérification du userland, et de jump à son entrypoint.
4) L'Userland
Go to topL'Userland est l'interface finale de l'utilisateur. C'est là où se situent Escher et les applications. Ce bloc de code est le plus limité (car c'est le seul qui puisse être modifié par tout le monde, avec le code qu'il veut) en accès de mémoire (il s'execute en supervised, et ne peut modifier qu'une partie de la ram, et une partie de la rom). Pour interragir avec l'utilisateur, il communique donc au kernel, grâce au SVC handler dans le kernel.
4) La signature
Go to topLe kernel et l'userland sont donc signés. Pour faire ça, le kernel calcule le hash (par SHA-256) du firmware, et vérifie avec un système de clé asymétrique s'il correspond à ce qui est précisé dans le header du userland. Je n'ai pas les connaissances pour tout expliquer malheureusement 😅.
4) Les applications
Go to topNumworks introduit cependant un système d'applications, qui pourront être exécutées depuis le firmware. Ces apps ont un fonctionnement qui est cependant très simpliste : l'userland jump à son entrypoint, et donc ces apps sont comprises comme un userland (aux yeux du kernel). Installer une app rend donc le firmware non "valide" (aux yeux de sa signature).
Ce système d'apps est donc loin d'être réellement utilisable (comme en parlait critor), et pour les améliorer dans le futur, il faudrait différentes choses :
- Avoir un réel système de fichier (en rom de préférence, peut être géré dans le kernel), afin que les apps puissent stocker des données
- Avoir des applications "signés" (et si possible des applications communautaires autorisées), qui ne seraient pas supprimés lors de l'entrée en mode examen ou reset (et même autorisés en examen pour certaines ?).
Pour conclure, Numworks pour convenir aux exams boards, et toujours autoriser les firmwares tiers, il a fallu bien limiter ces derniers, mais surtout créer un système sécurisé, en rajoutant une grande complexité. C'est bien regrettable que les applications ne soient pas pour l'instant utilisables, mais on peut espérer que Numworks comprendra vite que s'ils ne cherchent pas à les améliorer, ils perdront une grosse partie de leur communauté.
Petite modification : les apps externes ne sont pas censés recevoir cette pop-up à chaque démarrage, mais uniquement à l'installation (en guise d'information pour l'utilisateur, et non pour les examinateurs du coups). C'est encore loin d'être parfaitement utilisable pour un utilisateur français, mais l'installation d'apps ne devraient pas à terme perturber en permanence l'utilisateur 
J'ai après l'écriture de l'article quelques corrections à faire :
- le kernel ne vérifie pas la signature du userland : c'est le bootloader qui le fait (sûrement pour gagner de la rom)
- apparement, le bootloader ne peut plus être mis à jour (pour limiter des exploits)
- pour bien clarifier, l'userland s'exécute forcément en mode unprivilegied (pour limiter les surfaces d'attaques aussi)
