Il y a deux raisons principales.
La première raison est que, bien que les processeurs x86 offrent quatre anneaux de protection de la mémoire, la granularité de la protection ainsi offerte n'est qu'au niveau par segment. Autrement dit, chaque segment peut être défini sur un anneau spécifique ("niveau de privilège") de 0 à 3, ainsi que d'autres protections telles que l'écriture désactivée. Mais il n'y a pas beaucoup de descripteurs de segments disponibles. La plupart des systèmes d'exploitation aimeraient avoir une granularité beaucoup plus fine de la protection de la mémoire. Comme ... pour des pages individuelles.
Entrez donc la protection basée sur les entrées de table de pages (PTE). La plupart, sinon tous les systèmes d'exploitation x86 modernes ignorent plus ou moins le mécanisme de segmentation (autant qu'ils le peuvent, de toute façon) et s'appuient sur une protection basée sur PTE. Ceci est spécifié par les bits de drapeau qui sont les 12 bits inférieurs de chaque PTE - plus le bit 63 sur les CPU qui prennent en charge la non-exécution. Il y a un PTE pour chaque page, qui est normalement 4K.
L'un de ces bits indicateurs est appelé le bit "privilégié". Ce bit contrôle si le processeur doit ou non être dans l'un des niveaux "privilégiés" pour accéder à la page. Les niveaux "privilégiés" sont PL 0, 1 et 2. Mais ce n'est qu'un bit, donc au niveau de la protection page par page, le nombre de "modes" disponibles en ce qui concerne la protection de la mémoire n'est que de deux: Une page peut être accessible en mode non privilégié ou non. D'où juste deux anneaux.
Pour avoir quatre sonneries possibles pour chaque page, ils devraient avoir deux bits de protection dans chaque entrée de table de pages, pour coder l'un des quatre numéros de sonnerie possibles (tout comme les descripteurs de segment). Ils ne le font pas.
La deuxième raison est l'objectif de la portabilité du système d'exploitation. Il ne s'agit pas seulement de x86; Unix nous a appris qu'un OS pouvait être relativement portable sur plusieurs architectures de processeur, et que c'était une bonne chose. Et certains processeurs ne prennent en charge que deux anneaux. En ne dépendant pas de plusieurs anneaux dans l'architecture, les implémenteurs de système d'exploitation ont rendu les systèmes d'exploitation plus portables.
Il existe une troisième raison spécifique au développement de Windows NT. Les concepteurs de NT (David Cutler et son équipe, que Microsoft a embauchés à l'extérieur des laboratoires DEC de la région ouest) avaient une vaste expérience antérieure sur VMS; en fait, Cutler et quelques-uns des autres faisaient partie des concepteurs originaux de VMS. Et le processeur VAX pour lequel VMS a été conçu (et vice versa) a quatre anneaux. VMS utilise quatre anneaux. (En fait, le VAX a quatre bits de protection dans le PTE, permettant des combinaisons comme "en lecture seule depuis le mode utilisateur, mais inscriptibles depuis l'anneau 2 et l'intérieur." Mais je m'éloigne du sujet.)
Mais les composants qui fonctionnaient dans les anneaux 1 et 2 de VMS (Record Management Services et CLI, respectivement) ont été exclus de la conception NT. Ring 2 dans VMS ne concernait pas vraiment la sécurité du système d'exploitation, mais plutôt la préservation de l'environnement CLI de l'utilisateur d'un programme à l'autre, et Windows NT n'avait tout simplement pas ce concept; la CLI s'exécute comme un processus ordinaire. Quant à l'anneau 1 de VMS, le code RMS de l'anneau 1 a dû appeler assez souvent dans l'anneau 0 et les transitions en anneau sont coûteuses. Il s'est avéré beaucoup plus efficace de simplement passer à l'anneau 0 et d'en finir avec cela plutôt que d'avoir beaucoup de transitions de l'anneau 0 dans le code de l'anneau 1. (Encore une fois - pas que NT ait quelque chose comme RMS de toute façon.)
Mais pourquoi sont-ils là, alors? Quant à savoir pourquoi x86 a implémenté quatre anneaux alors que les OS ne les utilisaient pas - vous parlez d'OS de conception beaucoup plus récente que x86. Un grand nombre des fonctionnalités de «programmation système» de x86 ont été conçues bien avant que les noyaux NT ou Unix-ish réels soient implémentés dessus, et ils ne savaient pas vraiment ce que les systèmes d'exploitation utiliseraient. (Ce n'est que lorsque nous avons obtenu la pagination sur x86 - qui n'apparaissait pas avant le 80386 - que nous avons pu implémenter de véritables noyaux Unix-ish ou VMS sans repenser la gestion de la mémoire à partir de zéro.)
Non seulement les systèmes d'exploitation x86 modernes ignorent largement la segmentation (ils configurent simplement les segments C, D et S avec l'adresse de base 0 et la taille de 4 Go; les segments F et G sont parfois utilisés pour pointer vers des structures de données de système d'exploitation clés), ils ont également ignorer en grande partie des choses comme les «segments d'état de tâche». Le mécanisme TSS a été clairement conçu pour le changement de contexte des threads mais il s'avère avoir trop d'effets secondaires, donc les OS x86 modernes le font "à la main". Le seul moment où x86 NT modifie des tâches matérielles, par exemple, est pour des conditions vraiment exceptionnelles, comme une exception de double panne.
Concernant x64, beaucoup de ces fonctionnalités désaffectées ont été omises. (À leur crédit, AMD a en fait parlé aux équipes du noyau du système d'exploitation et leur a demandé ce dont ils avaient besoin de x86, ce dont ils n'avaient pas besoin ou ne voulaient pas et ce qu'ils aimeraient ajouter.) Les segments sur x64 n'existent que dans ce qui pourrait être appelé forme résiduelle, le changement d'état des tâches n'existe pas, etc. Et les systèmes d'exploitation continuent à utiliser seulement deux anneaux.