Redox

La création d'un nouveau système d'exploitation à partir de zéro est une tâche ardue, comme en témoigne la lenteur de la progression de GNU Hurd, par exemple.

 Mais il serait difficile de faire valoir que les systèmes existants sont la fin et la fin de tout notre façon d'interagir avec le matériel informatique.

 Au moins certaines des lacunes dans les offres d'aujourd'hui peuvent sans doute être attribuées au langage utilisé pour les mettre en œuvre; C, pour toute sa puissance, a des défauts assez sérieux qui conduisent à des bugs et des failles de sécurité de toutes sortes.

 Il est donc intéressant de voir un nouvel entrant qui utilise le langage Rust, qui est axé sur la sécurité de la mémoire.

 Le résultat est Redox, qui est encore loin d'être prêt pour un usage quotidien, mais peut constituer un contrepoint intéressant pour Linux, les BSD, OS X, Windows et autres.Comme cela a été exposé dans le livre Redox (qui est aussi un travail en cours), Rust a été choisi pour sa mémoire et sa sécurité. Certaines de ces fonctionnalités ont été décrites dans un article de LWN en 2013. 

Les développeurs Redox considèrent ces fonctions de sécurité comme un élément essentiel d'un système d'exploitation moderne, même s'il est basé sur le modèle Unix, beaucoup plus ancien:Cependant, nous avons un avantage: la mémoire forcée et la sécurité du type.

 C'est le côté fort de Rust, un grand nombre de "bugs inattendus" (par exemple, un comportement indéfini) sont éliminés.La conception de Linux et BSD est sécurisée.

 La mise en œuvre ne l'est pas.L'objectif est donc d'éliminer des classes entières de problèmes qui affectent les programmes C, mais l'accent mis sur la sécurité ne s'arrête pas là.  


Contrairement à Linux, Redox a un design de micro-noyau, où une grande partie du code qui réside dans un noyau monolithique comme Linux est déplacé vers l'espace utilisateur.

 Un micro-noyau fournit simplement la gestion des ressources, la communication interprocessus (IPC), la gestion et la planification des processus / threads, les appels système et peu d'autres choses.

 Le résultat est un noyau beaucoup plus petit (16 000 lignes de code pour Redox et prévoit de le réduire davantage) avec une réduction concomitante de la surface d'attaque, ainsi qu'une quantité beaucoup plus faible de code noyau critique à auditer.En Redox, comme dans MINIX, les conducteurs vivent dans l'espace utilisateur, ce qui leur permet de faire beaucoup moins de dégâts en cas de panne.

 Dans les noyaux monolithiques, un pilote incorrect peut planter tout le système car il s'exécute dans l'espace d'adressage du noyau et avec son niveau de privilège.

 Ainsi, pour Redox, les systèmes de fichiers, les pilotes de périphériques, les réseaux, etc. sont tous implémentés dans l'espace utilisateur.Au-delà de cela, Redox a adopté la philosophie «tout est un fichier» d'Unix (qui a été élargie par le Plan 9) et a fait un pas de plus. Dans Redox, tout est une URL (ou, en réalité, un URI), ce qui signifie que l'API est basée sur l'utilisation d'URL pour accéder aux ressources locales et distantes: 

fichiers, protocoles et sites de réseaux, périphériques, etc.La partie "schéma" d'un URI (par exemple "http:" dans une URL Web) est utilisée pour identifier le type de la ressource à laquelle on accède.

 Ceux-ci sont implémentés en tant que schémas Redox, qui peuvent être implémentés dans l'espace utilisateur ou le noyau, bien que l'espace utilisateur soit préféré.

 Les schémas sont en fait des systèmes de fichiers virtuels avec un ensemble d'opérations disponibles qui sont appropriées au type. Comme le note le livre: 

"'Tout est un schéma, identifié par une URL' est plus précis, mais pas très accrocheur."

 Le wiki Redox explique un peu plus en détail comment les URL et les schémas sont utilisés.  
Par exemple, tcp: //10.11.12.13: 80 serait utilisé pour une connexion TCP distante, tandis que le fichier: /apps/terminal/example.txt fait référence à un fichier local.
 Dans la page wiki de mise en réseau, il est fait mention de l'utilisation d'une URL comme tcp: /// 80 pour un serveur web ou ethernet: // 12: 34: 56: 78: 9A: BC / 800 pour recevoir ou envoyer IPv4 (type 800 ) des paquets pour l'adresse MAC spécifiée.Au-dessous des schémas se trouvent des ressources, qui se présentent sous deux formes: de type fichier (c'est-à-dire bloquant et tamponné) et de type socket (c'est-à-dire non bloquant et semblable à un flux).  
Les ressources sont étroitement liées aux systèmes, comme le note le livre:Les ressources sont des schémas ouverts.
 Vous pouvez les considérer comme une connexion établie entre le fournisseur du schéma et le client.Les ressources sont étroitement liées aux systèmes et parfois liées à des systèmes.

 La différence entre eux est subtile, mais cruciale.Bien que le noyau soit l'objet principal du projet actuellement, il y a aussi quelques projets secondaires d'intérêt.
 Pour commencer, ZFS est conçu comme le système de fichiers de choix pour Redox, ce qui signifie écrire une implémentation compatible dans Rust ou adapter la version open-source existante (OpenZFS).
 Il y a un serveur graphique minimal, orbital, basé sur le protocole Wayland. Il y a aussi un éditeur de type vi (Sodium), des jeux, et plus encore.Le code est disponible sur GitHub et a été publié sous licence MIT.
 L'explication du choix de la licence MIT a été quelque peu controversée chez certains partisans de la GPL, mais les développeurs veulent clairement que Redox se propage loin et large-propriétaires des fourchettes et des extensions sont explicitement tolérés. 
 Des images ISO pour différentes cibles sont disponibles, bien qu'il s'agisse d'un autre travail en cours. Le livre a aussi quelques instructions (commençant ici) pour ceux qui veulent construire Redox pour eux-mêmes.
 Un forum de discussion est prévu pour discuter de Redox et de son développement.

 Il y a des lignes directrices et des idées sur les contributions, une page sur les pratiques exemplaires et la liste des problèmes inévitables.

 Les personnes intéressées peuvent suivre le projet en consultant les bulletins d'information «This Week in Redox», bien qu'ils soient plus sporadiques que le nom ne le laisse supposer.

 Le code de conduite est assez vaste et montre clairement l'intention de favoriser une communauté inclusive.

 En bref, il y a beaucoup d'informations disponibles sur Redox, bien qu'il soit quelque peu dispersé. 
Une question que beaucoup poseront est "pourquoi un nouveau système d'exploitation?" 

 Les développeurs Redox ont une réponse qui se résume à l'insatisfaction avec Linux, les BSD, et même MINIX (qui est «le plus en phase avec la philosophie de Redox»).
 Il y a un sentiment «Non inventé ici» admis dans le projet. Mais une chose qui n'est explicitement pas un objectif pour le projet est de remplacer Linux. Une réponse d'un mot ("Non") au "Redox va-t-il remplacer Linux?" question est contenue dans le livre.

C'est probablement une bonne chose pour un certain nombre de raisons. D'une part, le support matériel est une tâche énorme qui risque de ne pas être surmontée sans un énorme effort de la part de nombreuses entreprises, ce que la licence du MIT pourrait rendre difficile. 

 Qu'on le veuille ou non, la nature réciproque de la GPL semble certainement être une force motrice pour l'implication des entreprises dans Linux. C'est également un domaine dans lequel des alternatives plus permissives (les BSD et MINIX) se sont échouées dans une certaine mesure.

Mais il y a aussi d'autres obstacles. Redox a délibérément choisi d'implémenter un sous-ensemble minimal des appels système Linux (et POSIX).  

Cela rendra plus difficile le portage des applications existantes vers Redox. Cela est en partie dû au fait qu'un écosystème d'espace utilisateur basé sur Rust est envisagé, mais le grand nombre d'applications existantes sous licence libre, qui peuvent être difficiles à mettre en communication, pourrait constituer un obstacle majeur à l'adoption de Redox.  

Des problèmes de longue date avec les performances des micro-noyaux (qui nécessitent beaucoup plus de changements de contexte que les noyaux monolithiques) peuvent également faire de Redox une vente difficile pour le segment des serveurs plus lucratif - même si les gains de sécurité sont importants. substantiel.

C'est clairement un projet ambitieux, peut-être même trop ambitieux; Seul le temps nous le dira. Cependant, il vaut la peine de regarder comme une expérience dans plusieurs dimensions.  

La conception du micro-noyau et la mise en œuvre basée sur Rust fourniront des réponses (ou au moins des preuves dans un sens ou dans un autre) à certaines questions qui circulent depuis un certain temps.  

Nous n'avons évidemment pas toutes les réponses du système d'exploitation pour l'avenir, donc plus de données sont nécessaires. Redox pourrait simplement fournir certaines de ces données.