Comprendre les niveaux de l'informatique

Désolé, pour ma question confuse. Je cherche des pointeurs.

Jusqu'à présent, j'ai principalement travaillé avec Java et Python sur la couche application et je n'ai qu'une vague compréhension des systèmes d'exploitation et du matériel. Je veux en savoir beaucoup plus sur les niveaux inférieurs de l'informatique, mais cela devient vraiment écrasant d'une manière ou d'une autre. À l'université, j'ai suivi un cours sur la microprogrammation, c'est-à-dire comment les processeurs sont câblés pour implémenter les codes ASM. Jusqu'à présent, j'ai toujours pensé que je n'en ferais pas plus si j'en apprenais plus sur le "bas niveau".

Une question que je me pose est: comment est-il même possible que le matériel soit caché presque complètement au développeur? Est-il exact de dire que le système d'exploitation est une couche logicielle pour le matériel? Un petit exemple: en programmation, je n'ai jamais rencontré le besoin de comprendre ce qu'est le cache L2 ou L3. Pour l'environnement d'application d'entreprise typique, il n'est presque jamais nécessaire de comprendre l'assembleur et les niveaux inférieurs de l'informatique, car de nos jours il existe une pile technologique pour presque tout. Je suppose que l'intérêt de ces niveaux inférieurs est de fournir une interface vers des niveaux supérieurs. D'un autre côté, je me demande dans quelle mesure les niveaux inférieurs peuvent avoir une influence, par exemple toute cette histoire de calcul graphique.

Donc, d'autre part, il y a cette branche informatique théorique, qui travaille sur des modèles informatiques abstraits. Cependant, j'ai également rarement rencontré des situations, où j'ai trouvé utile de penser dans les catégories de modèles de complexité, de vérification de preuve, etc. un grand nombre de N. Ce qui me manque est une référence pour un cadre pour penser à ces choses. Il me semble qu'il y a toutes sortes de camps différents, qui interagissent rarement.

Ces dernières semaines, j'ai lu sur les problèmes de sécurité. Ici, en quelque sorte, la plupart des différentes couches se rejoignent. Les attaques et les exploits se produisent presque toujours au niveau inférieur, donc dans ce cas, il est nécessaire de se renseigner sur les détails des couches OSI, le fonctionnement interne d'un système d'exploitation, etc.

Le mot-clé pour penser à ces choses est l' abstraction .

L'abstraction signifie simplement d'ignorer délibérément les détails d'un système afin que vous puissiez le considérer comme un composant unique et indivisible lors de l'assemblage d'un système plus grand à partir de nombreux sous-systèmes. Il est d'une puissance inimaginable - écrire un programme d'application moderne tout en considérant les détails de l'allocation de mémoire et du déversement des registres et des temps d'exécution des transistors serait possible d'une manière idéalisée, mais il est incomparablement plus facile de ne pasd'y penser et d'utiliser à la place des opérations de haut niveau. Le paradigme informatique moderne repose essentiellement sur plusieurs niveaux d'abstraction: électronique à semi-conducteurs, microprogrammation, instructions machine, langages de programmation de haut niveau, OS et API de programmation Web, cadres et applications programmables par l'utilisateur. Pratiquement personne ne pouvait comprendre l'ensemble du système de nos jours, et il n'y a même pas de voie imaginable par laquelle nous pourrions jamais revenir à cet état de fait.

Le revers de l'abstraction est la perte de puissance. En laissant les décisions sur les détails à des niveaux inférieurs, nous acceptons souvent qu'elles puissent être prises avec une efficacité sous-optimale, car les niveaux inférieurs n'ont pas le `` Big Picture '' et peuvent optimiser leur fonctionnement uniquement par la connaissance locale, et ne sont pas aussi (potentiellement) intelligent en tant qu'être humain. (Habituellement. Par exemple, la compilation de HLL en code machine est de nos jours souvent mieux effectuée par les machines que par l'homme le plus compétent, car l'architecture du processeur est devenue si compliquée.)

La question de la sécurité est intéressante, car les failles et les «fuites» dans l'abstraction peuvent souvent être exploitées pour violer l'intégrité d'un système. Lorsqu'une API postule que vous pouvez appeler les méthodes A, B et C, mais uniquement si la condition X est remplie, il est facile d'oublier la condition et de ne pas être préparé aux retombées qui se produisent lorsque la condition est violée. Par exemple, le débordement de tampon classique exploite le fait que l'écriture dans des cellules de mémoire produit un comportement indéfini sauf si vous avez alloué vous-même ce bloc de mémoire particulier. L'API garantit seulement que quelque chosese produira en conséquence, mais dans la pratique, le résultat est défini par les détails du système au niveau inférieur suivant - que nous avons délibérément oublié! Tant que nous remplissons la condition, cela n'a aucune importance, mais sinon, un attaquant qui comprend intimement les deux niveaux peut généralement diriger le comportement de l'ensemble du système comme souhaité et provoquer de mauvaises choses.

Le cas des bogues d'allocation de mémoire est particulièrement mauvais car il s'est avéré très difficile de gérer la mémoire manuellement sans une seule erreur dans un grand système. Cela pourrait être considéré comme un cas d'abstraction raté: bien qu'il soit possible de faire tout ce dont vous avez besoin avec le CmallocAPI, c'est tout simplement trop facile à abuser. Certaines parties de la communauté de programmation pensent maintenant que ce n'était pas le bon endroit pour introduire une limite de niveau dans le système, et à la place promouvoir les langues avec la gestion automatique de la mémoire et la collecte des ordures, qui perd un peu de puissance, mais offre une protection contre la corruption de mémoire et un comportement indéfini . En fait, une raison majeure de continuer à utiliser C ++ de nos jours est précisément le fait qu'il vous permet de contrôler exactement quelles ressources sont acquises et libérées quand. De cette façon, le schisme majeur entre les langues gérées et non gérées aujourd'hui peut être vu comme un désaccord sur l'endroit où définir précisément une couche d'abstraction.

La même chose peut être dite pour de nombreux autres paradigmes alternatifs majeurs dans l'informatique - le problème surgit vraiment tout le temps où de grands systèmes doivent être construits, parce que nous sommes tout simplement incapables de concevoir des solutions à partir de zéro pour les exigences complexes courantes aujourd'hui. (Un point de vue commun en IA ces jours -ci est que le cerveau humain en fait fait le travail comme celui - comportement résultant par des boucles de rétroaction, les réseaux massivement interconnectés etc. au lieu de modules séparés et des couches avec de simples interfaces abstraites entre eux, et que c'est pourquoi nous ont si peu réussi à simuler notre propre intelligence.)