Quels sont les pièges potentiels avec un noyau minimal qui exécute du code managé?

Supposons que je veuille construire un système d'exploitation basé sur un très petit noyau inférieur natif qui agit comme un interpréteur / runtime de code managé et un noyau supérieur plus grand compilé dans un langage machine non natif (bytecode Java, CIL, etc.). Des exemples de systèmes d'exploitation similaires seraient Singularity et Cosmos .

Quels sont les pièges et les défis de développement liés à l'écriture d'un système d'exploitation avec ce type d'infrastructure contrairement à une solution purement native?

Selon la langue, il peut y avoir de nombreux défis de développement:

1. Pointeurs: si une langue n'a pas de pointeurs, il sera difficile d'effectuer des tâches relativement faciles. Par exemple, vous pouvez utiliser des pointeurs pour écrire dans la mémoire VGA pour l'impression à l'écran. Cependant, dans un langage managé, vous aurez besoin d'une sorte de "plug" (de C / C ++) pour faire de même.

2. Assemblage: un système d'exploitation a toujours besoin d'un assemblage. Les langages comme C #, Java, etc. ne fonctionnent pas aussi bien avec lui, contrairement à C / C ++. En C ou C ++, vous pouvez également avoir un assemblage en ligne qui est très, très utile pour de nombreuses tâches. Il y a BEAUCOUP de cas où cela est nécessaire (exemples en x86): chargement d'un GDT, chargement d'un IDT, activation de la pagination, configuration des IRQ, etc.

3. Contrôle: si vous utilisez quelque chose comme Cosmos, vous n'avez pas le contrôle total. Cosmos est un micro-noyau et essentiellement "bootstraps" votre "noyau". Vous pouvez implémenter quelque chose comme Cosmos à partir de zéro si vous le vouliez vraiment, cependant, cela peut prendre beaucoup de temps.

4. Surcharge: Avec les langages gérés, il y a BEAUCOUP de surcharge par rapport au C ou même au C ++. Des choses comme Cosmos doivent implémenter beaucoup de choses avant même qu'un noyau C # hello world puisse être exécuté. En C, vous êtes prêt à démarrer, aucune configuration réelle n'est nécessaire. En C ++, il y a juste quelques choses qui doivent être implémentées pour utiliser certaines fonctionnalités de C ++.

5. Structures: en C / C ++, il existe des structures que de nombreux langages gérés n'ont pas, et donc, vous devez implémenter un moyen d'avoir quelque chose comme une structure. Par exemple, si vous souhaitez charger une table IDT (Interrupt Descriptor Table), en C / C ++, vous pouvez créer une structure (avec un attribut compressé) et la charger à l'aide de l'instruction lidt x86 ASM . Dans une langue managée, c'est beaucoup plus difficile à faire ...

Les langages gérés, au niveau de la syntaxe, sont plus faciles, cependant, car de nombreuses choses liées au système d'exploitation ne sont souvent pas très bien adaptées. Cela ne signifie pas qu'ils ne peuvent pas être utilisés, cependant, quelque chose comme C / C ++ est souvent recommandé.

J'ai entendu dire (par un chercheur travaillant sur une technique de micro-noyau concurrente ) que l'on sait très peu de choses sur la façon d'évaluer la sécurité des systèmes extensibles via du code managé.

Le problème est que les types de bogues susceptibles de provoquer une faille de sécurité sont très différents de ceux auxquels les chercheurs en sécurité sont habitués. Dans un micro-noyau traditionnel, tous les pilotes et autres sous-parties du noyau sont isolés les uns des autres en les exécutant dans des espaces d'adressage différents. Dans un micro-noyau où l'isolement est mis en œuvre par le biais de la vérification du type de code managé, vous évitez les énormes frais généraux liés à la commutation des espaces d'adressage chaque fois que vous avez besoin d'utiliser un sous-service, mais le compromis est que l'évaluation du mécanisme d'isolement est désormais plus difficile.

Toute partie particulière du noyau (par exemple un pilote de périphérique) écrite dans le langage géré est sûre si et seulement si le vérificateur de type dit que le pilote est sûr et que le vérificateur de type n'a pas de bogues. Le vérificateur de type fait donc partie du noyau du noyau. En pratique, il semble que les vérificateurs de type soient considérablement plus volumineux et plus compliqués que les cœurs de micro-noyau traditionnels. Cela signifie que la surface d'attaque est potentiellement plus grande.

Je ne sais pas si les techniques d'isolement micro-noyau traditionnelles ou les techniques d'isolement basées sur du code managé sont vraiment plus ou moins fiables. Il y a un problème d'amorçage ici: tant que les techniques d'isolement de code managé ne seront pas largement utilisées, nous ne saurons pas à quelle fréquence elles sont non sécurisées. Mais sans savoir à quel point ils sont précaires, il est difficile de les déployer dans des situations critiques pour la sécurité.