Gestion mémoire sous Windows NT ^[CUST93]

Structure de Windows NT

Sous-systèmes protégés

    Certains de ces sous-systèmes, appelés sous-systèmes d'environnement, offrent des interfaces d'utilisation et de programmation (langage de commande et APIs) caractéristiques des systèmes d'exploitation (Windows, Unix, etc.), et fournissent un environnement d'exécution aux applications. Le plus utilisé est Win32, mais Windows NT en supporte d'autres parmi lesquels OS/2, POSIX, MS-DOS, Win16.

    D'autres serveurs, appelés sous-systèmes intégraux, gèrent certaines fonctionnalités du système d'exploitation. Le plus connu, le sous-système de sécurité, gère une base de données contenant des informations sur les comptes utilisateurs (noms, mots de passe, groupes d'utilisateurs, etc.), surveille les accès aux ressources du système, génère des messages de surveillance, gère les informations d'ouverture de session (logon).

L'exécutif NT

    L'exécutif est constitué de plusieurs modules :

    Chaque module, ou élément, implémente deux sortes de fonctions : les services système, qui peuvent être appelés aussi bien par les sous-systèmes protégés que par les autres éléments, et les fonctions internes, qui ne sont appelables que par les composants situés dans l'exécutif. Le gestionnaire de mémoire virtuelle (Virtual Memory manager ou simplement VM) implémente la mémoire virtuelle de chaque processus en mémoire physique ^[1], en protège l'accès, ou au contraire en permet le partage partiel, sauvegarde sur disque et restaure son contenu lorsque c'est nécessaire.

Mémoire virtuelle

Espace d'adressage

Pages virtuelles, pages physiques

    En particulier, on notera qu'une partie, appelée réserve non paginée ^[3], n'est jamais paginée et contient des structures de données et certains objets importants utilisés par Windows NT.

    La mémoire physique est elle aussi découpée en pages physiques ^[4], dans lesquelles sont "mappées" les pages virtuelles par l'intermédiaire du système de mémoire virtuelle (dont une partie peut être matérielle, voir gestion mémoire de l'iAPX 386). Lorsqu'une page virtuelle est directement accessible dans une page physique, elle est dite page valide. Si elle n'est pas chargée, si elle n'est pas accessible ou si son contenu est altéré, elle est dite page invalide (voir les notions de page propre et page sale).

Processus et mémoire virtuelle

    A chaque processus correspond un objet-processus géré par l'exécutif NT, qui comporte différentes données membres (appelées attributs) et fonctions membres (appelées services) concernant la mémoire :

les données membres :

• les limites de quotas : le nombre maximal de pages mémoire système paginée ou non, la taille utilisable dans le fichier de pagination,
• un compteur d'opérations de VM : le nombre et le type des opérations de mémoire virtuelle effectuées par les threads du processus.

les fonctions membres :

• allouer et libérer de la mémoire virtuelle,
• lire ou écrire la mémoire virtuelle,
• protéger la mémoire virtuelle,
• bloquer ou débloquer la mémoire virtuelle,
• demander la mémoire virtuelle,
• vider la mémoire virtuelle.

Services de VM

• allocation de la mémoire en deux étapes,
• lecture/écriture de la mémoire virtuelle,
• blocage de pages virtuelles en mémoire physique,
• obtention d'informations sur des pages virtuelles,
• protection des pages virtuelles,
• déplacement des pages virtuelles sur un disque.

Allocation de la mémoire par VM

    Le gestionnaire VM alloue de la mémoire en deux étapes : la réservation et l'engagement ^[5]. La mémoire réservée est un ensemble d'adresses virtuelles que VM a réservées pour un processus. La mémoire engagée est de la mémoire pour laquelle VM a gardé de la place dans son fichier d'échange, ce qui signifie que, lorsqu'une page virtuelle aura été chargée en mémoire physique, elle pourra toujours être recopiée sur le disque si c'est nécessaire. La mémoire virtuelle doit donc toujours être engagée avant d'être utilisée. Un processus, ou un thread, peut réserver un grand espace de mémoire virtuelle, ce qui est une opération rapide, et ne l'engager que petit à petit, au fur et à mesure de leurs besoins. L'intérêt de la réservation est de garantir au thread qu'aucun autre thread du même processus n'occupera cet espace virtuel, et qu'il pourra donc disposer d'un espace mémoire virtuel contigu, par exemple pour y placer une structure de données de taille variable (une pile par exemple) sans pour autant geler un espace disque maximal peut-être pas nécessaire. Les opérations de réservation et d'engagement peuvent être simultanées ou séparées dans le temps, suivant les besoins du thread.

Quotas

    Le gestionnaire d'objets de l'exécutif NT fournit un service central de comptabilisation des ressources parmi lesquelles figure la mémoire. A chaque utilisateur est associée une limite de quotas sur la quantité totale de la mémoire système que ses processus peuvent utiliser. Le gestionnaire VM peut connaître la quantité de mémoire engagée par un processus à partir de la taille de fichier d'échange pour ce processus. En revanche, la mémoire réservée n'est pas comptabilisée. Le fichier d'échange ne contient que des copies de pages physiques, donc de mémoire réellement utilisée. Lorsqu'un thread n'utilise plus une plage d'adresses, il peut désengager les pages correspondantes, libérant ainsi de l'espace dans le fichier d'échange.

Verrouillage de pages en mémoire physique

    Le gestionnaire VM offre un service permettant à un sous-système ou n'importe quel autre processus disposant de certains privilèges de verrouiller certaines pages virtuelles en mémoire. Cette possibilité est particulièrement intéressante pour des applications dont le temps est un paramètre critique, ou qui nécessitent l'utilisation très fréquente de certaines données, par exemple la racine d'un B-arbre dans une base de données.

Accès à la mémoire privée d'un autre processus

    En principe, l'espace d'adressage d'un processus est totalement privé, et n'est accessible à aucun autre processus (sauf en cas de mémoire partagée, bien sûr), grâce au mécanisme de mapping : à la même adresse virtuelle de deux processus, le gestionnaire VM fait correspondre deux pages physiques différentes. Cependant, le gestionnaire VM peut fournir à un processus un service lui permettant d'accéder à sa propre mémoire ou à celle d'un autre processus, de l'allouer, de la libérer, d'y lire ou d'y écrire. Ces possibilités sont utilisées par les sous-systèmes protégés, qui émulent un système d'exploitation, et à ce titre créent des processus et gèrent leur mémoire virtuelle. C'est aussi le cas des débogueurs. Rappelons que ces deux types de processus tournent cependant en mode utilisateur.

Protection des pages

    Le gestionnaire VM peut, pour chaque page, positionner un ensemble d'indicateurs qui permettent une protection des pages virtuelles, en s'appuyant ou non sur des mécanismes matériels (mais Windows NT doit être indépendant du matériel sur lequel il tourne). Les indicateurs sont les suivants :
• lecture seule,
• lecture/écriture,
• exécution seule (execute-only),
• page de garde (guard-page),
• pas d'accès (no-access),
• copie à l'écriture (copy-on-write).

    Nous verrons dans les paragraphes suivants l'utilité de ces indicateurs.

Exécution seule

    Si le matériel le permet, une page contenant du code exécutable peut être verrouillée par le gestionnaire VM en exécution seule : un thread ne peut ni modifier le code, ni même le lire, mais seulement se brancher à une adresse de cette page et l'exécuter. Cette possibilité est très intéressante pour des raisons de sécurité : il est impossible par exemple de désassembler un programme, de le déboguer ou de l'analyser. Malheureusement, peu de processeurs offrent cette possibilité (ni les processeurs Intel, ni les processeurs alpha de Dec par exemple).

Contrôle de déroulement

Il est possible de déclarer une page virtuelle comme page de garde, et cela est utile lorsque cette page est placée immédiatement après une zone mémoire contenant une structure de données dynamique, ou une pile par exemple. En cas de débordement de la structure et de copie dans la page de garde, l'application reçoit une exception, mais l'opération est validée par le gestionnaire VM. Cet avertissement permet à l'application d'étendre la structure de données en mémoire virtuelle.

    De même le gestionnaire VM donne l'attribut pas d'accès aux pages virtuelles non allouées, ou aux pages allouées mais non encore engagées.

Partage de mémoire

    Lorsqu'une application est exécutée plusieurs fois simultanément, chaque processus peut avoir sa propre mémoire virtuelle, mais le gestionnaire VM peut mapper les pages virtuelles contenant le code des différentes instances dans les mêmes pages physiques. Il suffit que les pages virtuelles contenant les données privées soient mappées dans des pages physiques différentes. C'est ainsi qu'est implémentée la réentrance. Le gestionnaire VM garantit l'intégrité du code aux différents processus en verrouillant les pages virtuelles en lecture seule (ou exécution seule).

    Lorsque deux processus doivent partager des données, celles-ci peuvent être à des adresses virtuelles différentes, mais il suffit que le gestionnaire VM les mappe dans les mêmes pages physiques pour qu'elles soient communes aux deux processus. Si au moins l'un des deux threads doit modifier ces données, les pages virtuelles doivent être marquées en lecture-écriture. Il est alors nécessaire d'utiliser des mécanismes de protection.

    Une page virtuelle peut recevoir l'attribut copie-en-écriture. C'est le cas lorsqu'elle appartient à plusieurs processus sans pour autant avoir été déclarée comme mémoire partagée (technique mise en œuvre par exemple par Unix lors de l'appel de la fonction fork(), et utilisée par le sous-système POSIX). Tant que la page est accédée seulement en lecture par les différents processus, elle n'est pas dupliquée. En revanche, dès qu'un processus veut écrire dans cette page, la page physique est dupliquée, la page virtuelle correspondante de ce processus est mappée sur cette nouvelle page physique, dont l'indicateur est positionné à lecture/écriture.

Mémoire système

Structures utilisées et mécanismes de pagination

Structures utilisées

    Les processeurs modernes (Intel en particulier) possèdent une unité qui traduit les adresses mémoire générées par le processus en adresses physiques. Ils possèdent une table de mémoire associative, appelée tampon des pages récemment utilisées, noté TLB, d'accès et de temps de réponse extrêmement rapide. Ce tampon peut être vu comme un vecteur dont tous les éléments sont accessibles simultanément, et dont chacun contient un numéro de page virtuelle, le numéro de la page physique dans laquelle elle est stockée et des indicateurs complémentaires concernant par exemple l'état de la page physique. Lorsque le gestionnaire VM supprime de la mémoire physique une page virtuelle qui est enregistrée dans la TLB (par exemple après l'avoir copiée dans le fichier de swap), il la marque "invalide" dans la TLB. Lorsque l'unité de traduction du processeur trouve dans la TLB une page invalide, il génère un défaut de page qui a pour effet de relancer le gestionnaire de page (pager) du gestionnaire VM. Si l'unité de traduction du processeur ne trouve pas la page virtuelle dans la TLB, cela ne signifie pas pour autant qu'elle n'est pas présente en mémoire physique. Il faut alors consulter, cette fois de façon logicielle, les tables de pages qui se trouvent elles-mêmes en mémoire. Sous Windows NT, toutes les pages virtuelles de chaque processus sont décrites dans une rubrique (ou entrée, ou élément) de la table des pages de ce processus (notée PTE : Page Table Entry). Il y a donc autant de tables de pages que de processus. La taille des pages dépend des processeurs, elle est par exemple de 4 Ko pour le MIPS R4000, 64 Ko pour le processeur alpha de Dec, et 4 Ko ou 4 Mo (fixé par programme) pour le processeur Pentium. Pour une pagination de 4 Ko par exemple, une seule table de pages possède 2²⁰ entrées (soit 1 048 576). Si une entrée occupe elle-même 4 octets (c'est le cas sous Windows NT), il faut 1024 pages physiques pour stocker une seule table de pages, pour un seul processus. Les tables de pages sont donc elles-mêmes paginées, gérées par VM, et stockées éventuellement sur disque. Lors de la recherche d'une page virtuelle, il peut donc arriver qu'une partie de la table des pages ne soit plus présente en  mémoire physique, et que son accès provoque à son tour un défaut de page.

    Dans un PTE de 32 bits correspondant à une page valide, c'est-à-dire chargée en mémoire physique et directement utilisable, il n'est pas nécessaire de stocker l'adresse complète de la page physique, mais seulement son numéro de page, qui ne nécessite que 20 bits au maximum, pour une taille de page de 4 Ko au minimum. L'adresse de début de la page physique, nécessaire au processeur, est simplement obtenue par un décalage à gauche de 12 bits. Il reste donc 12 bits disponibles pour stocker d'autres informations. En particulier, lorsqu'une page virtuelle est invalide, mais qu'une image de cette page est sur disque, l'adresse disque peut être stockée dans le TPE, permettant un rechargement rapide. C'est notamment le cas des pages de code exécutable ou  de constantes d'un programmes, toutes deux stockées dans le fichier exécutable, ou des pages recopiées sur la zone de swap du disque.

    Lorsqu'une page physique est partagée par plusieurs processus, elle devrait être référencée dans les tables de pages virtuelles de chacun d'eux. Le déplacement de cette page physique (recopie sur le fichier de sauvegarde et restauration dans une autre page physique) devrait être répercuté dans chacune des tables de pages. Pour simplifier ce traitement, Windows NT remplace l'élément correspondant de la page des tables (le PTE) de chaque processus par l'adresse (elle aussi de 4 octets) d'une structure appelée rubrique de table des prototype de pages (PTE prototype) qui contient elle-même le numéro de la page physique. Cette nouvelle indirection dans l'accès de la mémoire physique permet au gestionnaire VM de mettre à jour les correspondances des tables de pages de tous les processus concernés (qui partagent cette page physique) en une seule opération.

    D'autre part, le gestionnaire VM mémorise l'ensemble des pages physiques qu'utilise chaque processus. Cet ensemble est appelé jeu des pages de travail du processus ^[6] et est organisé en file (FIFO : First In, First Out).

    Si chaque processus peut connaître la position de ses pages virtuelles dans la mémoire physique grâce à sa table des pages, le gestionnaire VM doit lui aussi disposer d'informations concernant les pages physiques. Pour cela il gère une table des pages physiques, appelée base de données des pages physiques^[7]. Le numéro de la page physique stocké dans un PTE sert aussi d'indice pour accéder directement à l'élément correspondant de cette base de données, dont chaque élément contient plusieurs informations parmi lesquelles :

• l'état de la page physique. Une page physique peut prendre plusieurs états :
• Valide : la page physique est utilisée par un processus et apparaît dans un des éléments PTE de sa table des pages,
• A zéro : la page physique est libre et initialisée à zéro. Le département de la défense américain (DoD) impose, au niveau de sécurité C2 que, lorsqu'un processus en mode utilisateur reçoit des pages physiques libres, celles-ci soient préalablement initialisées à zéro, à moins qu'elles ne soient chargées à partir de fichiers disque (l'image de l'exécutable lors du démarrage de l'application, ou la restauration d'une page lui appartenant, en provenance du fichier de swap). Cette précaution empêche un processus utilisateur de récupérer des données ou du code ayant appartenu à un autre processus. Le numéro de la page est stocké dans une liste de pages à zéro,
• Libre : la page physique est libre et non initialisée. Son numéro est stocké dans une liste de pages libres,
• En attente : la page physique appartenait à un processus, elle lui a été retirée, et elle est marquée "invalide" et "transition" dans sa table des pages. Son numéro est stocké dans une liste de pages en attente. Attention, le TPE de la page virtuelle correspondante, bien que marqué "invalide", contient toujours le numéro de la page physique. Il pourra en effet être de nouveau utile .(voir plus loin : Stratégie de placement)
• Modifiée : la page est en attente, mais son contenu a été modifié depuis son chargement. Son numéro est stocké dans une liste de pages modifiées en attente,
• Mauvais : l'utilisation de la page a généré une erreur matérielle et ne doit plus être utilisée. Son numéro est stocké dans une liste de pages mauvaises.
• un pointeur en retour vers la table des pages du processus qui possède cette page, si elle est  occupée et si elle est privée, ou vers le PTE prototype correspondant si elle est partagée.

Pagination sur demande

Stratégie de remplacement

    Lors d'un défaut de page, si la liste des pages libres (ou à zéro) n'est pas vide, la première page est prélevée et attribuée au processus en demande de page. Dans ce cas, le nombre total de pages physiques allouées à un seul processus peut dépasser le nombre maximal de pages physiques par processus autorisé : il n'y a aucune raison de pénaliser un processus si la machine est sous-utilisée.

    Si la liste des pages physiques libres est vide, l'allocateur de pages de Windows NT  utilise un algorithme de remplacement local : il prélève une page physique de l'ensemble de travail du processus en défaut de page. Il ne prélève pas la plus anciennement utilisée (LRU : Least Recently Used), contrairement à Unix, mais utilise la file dans laquelle est stocké le jeu de pages de travail, la page prélevée étant la plus anciennement chargée.

Stratégie de placement

• il peut arriver que la page virtuelle soit encore dans une page physique non altérée. C'est le cas par exemple lorsque, dans un souci de régulation, VM a réduit la taille du jeu de pages du processus (voir mécanisme de régulation). La solution la plus rapide consiste alors à récupérer cette page et à l'attribuer de nouveau au processus. Il est facile de le savoir puisque le PTE correspondant contient les indicateurs "invalide" et "transitoire".
• s'il requiert une page initialisée, il la retire de la liste de pages à zéro si elle n'est pas vide, ou sinon de la liste des pages libres, et il l'initialise à 0,
• s'il ne requiert pas une page initialisée, il la retire de la liste des pages libres si elle n'est pas vide, ou sinon de la liste de pages à zéro.

Mécanisme de régulation

    La taille de l'ensemble des pages de travail évolue dans le temps en fonction du comportement du processus et des disponibilités globales des pages physiques : lorsque VM constate qu'un processus provoque de nombreux défauts de pages, il essaie d'augmenter la taille de son  ensemble de travail, dans la limite de ses possibilités. Si au contraire il constate que le processus ne provoque pas de défauts de page, il suppose qu'aucun thread ne s'exécute, ou qu'il dispose de trop d'espace. Il réduit donc cet espace progressivement jusqu'à ce que des défauts de pages apparaissent.

    Les pages physiques ainsi retirées à un processus sont placées soit dans la liste d'attente si leur contenu n'a pas été modifié depuis leur chargement, soit dans la liste d'attente de pages modifiées dans le cas contraire. Tant que leur contenu n'est pas altéré, elles restent des pages propres. Parallèlement, le gestionnaire VM positionne l'indicateur "transition" dans le PTE correspondant du processus.

    D'autres mécanismes de régulation sont aussi disponibles : dès que le nombre de pages des trois listes - pages libre, pages initialisées à zéro et pages en attente – passe au-dessous d'un seuil critique minimal, un thread, appelé unité d'écriture des pages modifiées ^[10] , est activé. Il recopie les pages modifiées de la liste des pages modifiées et les place dans la liste des pages en attente. Il faut noter qu'elles sont toujours disponibles pour être immédiatement récupérées si nécessaire.

    Enfin, lorsque le nombre d'éléments de la liste des pages modifiées passe au-dessous d'un seuil minimal, est mis en œuvre le mécanisme de réduction automatique des jeux de travail, décrit ci-dessus.

Win32 ^[MSC++97]

    Parmi l'ensemble des fonctions de manipulation de la mémoire, de l'API Win32, la fonction GetSystemInfo() retourne une structure _SYSTEM_INFO contenant des informations concernant le système :
 

typedef struct _SYSTEM_INFO {     union     {         DWORD  dwOemId;         struct         {             WORD wProcessorArchitecture;             WORD wReserved;         };     };     DWORD  dwPageSize;     LPVOID lpMinimumApplicationAddress;     LPVOID lpMaximumApplicationAddress;     DWORD  dwActiveProcessorMask;     DWORD  dwNumberOfProcessors;     DWORD  dwProcessorType;     DWORD  dwAllocationGranularity;     WORD  wProcessorLevel;     WORD  wProcessorRevision; } SYSTEM_INFO;

    Deux fonctions qui permettent de modifier les protections d'accès des pages engagées (commited) par le processus appelant (VirtualProtect()) ou par n'importe quel autre processus (VirtualProtectEx()). Les flags autorisés, donc les identificateurs sont suffisamment explicites, sont :

PAGE_READONLY, PAGE_READWRITE, PAGE_WRITECOPY, PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, PAGE_EXECUTE_WRITECOPY, PAGE_GUARD, PAGE_NOACCESS, PAGE_NOCACHE.

    La fonction VirtualAlloc() permet de réserver ou d'engager une région de pages virtuelles pour le processus appelant, en lui attribuant les mêmes flags que ci-dessus. Elle peut réserver des pages libres, engager des pages libres ou réservées. La mémoire ainsi allouée est automatiquement initialisée à 0.

    La fonction VirtualQuery() permet quant à elle d'obtenir des informations sur une région de pages virtuelles.

    Pour finir, citons un ensemble de 14 fonctions de débogage, parmi lesquelles ReadProcessMemory() et WriteProcessMemory(), qui permettent de lire et d'écrire dans la mémoire virtuelle d'un processus. Cela permet par exemple de placer un point d'arrêt dans un programme.