Jc/md/lp-01/05Gestion mémoire : présentation1 Gestion mémoire Présentation

jc/md/lp-01/05 Gestion mémoire : présentation 1

Gestion mémoire

Présentation


Objectif du chapitre

• Organisation de la mémoire• Découpage en slots• Rôle du slot 0• Passage d’adresses entre le slot 0 et le slot de

l’application


Architecture mémoire (1)

• Espace virtuel de 4 GB• Séparation de la mémoire en deux espaces

– De 0 à 2GB user mode (process)– De 2GB à 4GB kernel mode (system)

• Mémoire user mode– 33 slots de 32MB

32 slots pour les process (numéros 1 à 32) 1 slot pour le process en cours (numéro 0)

– le reste (1GB moins 32MB) est partagé entre tous les processus


Architecture mémoire (2)

• Quand un process est créé le système lui attribue un slot disponible (« ouvert ») parmi les slots 1 à 32

• Maximum de 32 processus ouverts

• Quand un process s’exécute, il est cloné dans le slot 0


Adressage d’un process en mémoire


Gestion mémoire

• Mémoire gérée par pages de 4KB ou 1KB suivant les microprocesseurs

• Gestion par le mécanisme de page à la demande, mais on a aussi la possibilité de charger une application complète en mémoire

• Possibilité de réserver des régions• Possibilité d’accéder à de vastes espaces

mémoires dans une partie gérée comme des fichiers en RAM


Mémoire locale du process (1)

0 à 32 MB• 64 KB réservés• Code• Données ROM• Données RAM• Tas• Pile• Espace allouable• Dll « dynamiques »



• Code et données RAM ou ROM suivant le programme

• Heap (tas) jusqu’à 192KB avec une granularité de 4 ou 8 bytes suivant les processeurs (LocalAlloc(), LocalFree(), etc.

• Possibilité de créer de nouveaux Heap si nécessaire (HeapCreate(), HeapAlloc(),…)

• Stack (pile), paramètre de l’édition de liens (link), 64KB par défaut



32 à 64 MB

• Extension CE 4.x par rapport à CE 3.0

• Dll systèmes

• Dll « statiques » en ROM avec les problèmes posés par l’interdiction du recouvrement des dll



• Extension d’allocation à la demande avec les fonctions VirtualAlloc, VirtualFree

• Sur des frontières de 64KB• Allocation suivant la taille

– Dans l’espace virtuel du process ou dans l’espace partagé si la taille atteint ou dépasse deux MB

– Problèmes de protection d’accès à prendre en considération


Mémoire externe au process

• 1 Go moins l’espace du slot 32 (32 Mo)• Dans l’espace entre 1GB (+32MB) et 2GB• Allocation à la demande de zones privées ou

partageables– VirtualAlloc(), VirtualFree(),…– Fonctions fichiers


Passage de pointeurs

• Il peut être intéressant pour une application de passer à un driver des pointeurs créés dynamiquement

• Les adresses de ces pointeurs sont créées en slot 0, pendant l’exécution et par conséquent l’application ne connaît que l’adresse locale

• Le driver doit donc établir la correspondance entre cette adresse en slot 0 et son image dans l’espace virtuel de l’application pour pouvoir les réutiliser


Correspondance des pointeurs

• Le système propose deux fonctions pour résoudre le problème technique

• Le driver récupère le handle du process appelant par :

GetCallerProcess(void)• Puis le driver demande au système d’établir,

grâce à ce handle, la correspondance pour le même pointeur vu dans l’autre slot par :

MapPtrToProcess( LPVOID lpv, HANDLE hProc)


GetCallerProcess(void)

HANDLE GetCallerProcess(void);

Parameters

None.

Return Values

A handle to the caller process indicates success.


MapPtrToProcess

LPVOID MapPtrToProcess( LPVOID lpv, HANDLE hProc );

Parameterslpv

[in] Long pointer to be mapped. hProc

[in] Handle to the process into which the lpv pointer is to be mapped.

Return ValuesIf successful, returns a mapped version of the lpv pointer;

otherwise, the return value is NULL.


Driver à réaliser

• Écrire un driver qui recevra dans un IOCTL, non pas un buffer avec des données, mais un buffer contenant deux adresses, l’une d’un buffer de texte unicode pour les entrées, l’autre d’un buffer de texte unicode pour les sorties (WCHAR) In et Out.

• L’IOCTL devra établir la correspondance pour ces pointeurs chez l’appelant

• L’IOCTL lira le buffer In, le modifiera (passage majuscule vers minuscule), et le réécrira dans la zone Out


Driver (1)


Driver (2)


Driver (3)


Driver (3)


Driver : fichier .cpp fourni


Insertion

• Créer et insérer dans le projet le fichier des entêtes PTR.h

• Créer et insérer dans le projet le fichier PTR_DRV.def


PTR.h

#include <Windev.h>

typedef struct {

WCHAR *lpInBuffer;WCHAR *lpOutBuffer;

}MYPTRS,*PMYPTRS;

#define IOCTL_POINTEURS CTL_CODE( FILE_DEVICE_UNKNOWN, 2048,

METHOD_BUFFERED,FILE_ANY_ACCESS)


PTR_DRV.def

LIBRARY PTR_DRV

EXPORTS

PTR_Init

PTR_Deinit

PTR_Open

PTR_Close

PTR_IOControl


Structure du driver


Entête du driver

//includes// TODO

//définitions et réservations globales// TODO

//entrée du driverBOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ){

return TRUE;}


PTR_Init

DWORD PTR_Init(DWORD dwContext)

{

DWORD dwRet =1;

RETAILMSG(1,(TEXT("PTR_DRV: PTR_Init\n")));

//Initialisation du buffer de travail à zéro

// TODO

return dwRet;

}


PTR_Deinit

BOOL PTR_Deinit(DWORD hDeviceContext)

{

BOOL bRet = TRUE;

RETAILMSG(1,(TEXT("PTR_DRV: PTR_Deinit\n")));

return bRet;

}


PTR_Open

DWORD PTR_Open(DWORD hDeviceContext, DWORD AccessCode, DWORD ShareMode)

{

DWORD dwRet = 1;

RETAILMSG(1,(TEXT("PTR_DRV: PTR_Open\n")));

return dwRet;

}


PTR_Close

BOOL PTR_Close(DWORD hOpenContext)

{

BOOL bRet = TRUE;

RETAILMSG(1,(TEXT("PTR_DRV: PTR_Close\n")));

return bRet;

}


IOCTL (1)

BOOL PTR_IOControl(DWORD hOpenContext,

DWORD dwCode,

PBYTE pBufIn,

DWORD dwLenIn,

PBYTE pBufOut,

DWORD dwLenOut,

PDWORD pdwActualOut)

{


IOCTL (2)

//Réservations

// TODO

switch(dwCode)

{


IOCTL (3)

case IOCTL_POINTEURS: // TODO

//Récupération du handle de l'appelant //Mappage des adresses des pointeurs //Impression des valeurs des pointeurs

remappés //(RETAILMSG)…

// TODO //Lecture du buffer In

//Modification dans le buffer //Écriture dans le buffer Out

bRet = TRUE; break;


IOCTL (4)

default: RETAILMSG(1,(TEXT("PTR_DRV: erreur IOCTL \n")));

bRet=FALSE;

break;

}//Fin du switch

return bRet;

} //Fin Ioctl


Génération du driver


Création de l’image noyau & driver


Application PTR_APP

Préparation


Application à réaliser

• L’application créera 2 buffers prévus pour des textes codés en unicode : In et Out

• In contiendra un texte en majuscule• Out contiendra XXXXXXXXX• L’application passera au driver une structure

contenant l’adresse de ces 2 buffers• Un IOCTL modifiera le buffer OUT• L’application imprimera le buffer modifié


Application (1)


Application (2)


Application (3)


Application (4)


Application (5)


Application PTR_APP

Code


Entête de l’application

// TODO : Include et définitions

int WINAPI WinMain(HINSTANCE hInstance,

HINSTANCE hPrevInstance,

LPTSTR lpCmdLine,

int nCmdShow)

{


Création et initialisation des buffers

// TODO: définition du nom de la structure à passer

// TODO: allocation des buffers In et Out

// TODO: initialisation des 2 buffers (wcscpy)

// TODO: affichage du buffer Out (MessageBox)

// TODO: impression des adresses des buffers (RETAILMSG)


Chargement du driver

// TODO: inscription du driver (RegisterDevice)

if(hDriver == 0)

{

MessageBox(NULL, _T("Pb au chargement de PTR_DRV.dll"),_T("PTR_APP"),MB_OK);

return 0;

}


Ouverture du driver

// TODO: ouverture du driver en Read/Write

if (INVALID_HANDLE_VALUE == hPtr) {

MessageBox(NULL, _T("Pb Open driver"),

_T("PTR_APP"), MB_OK);

//TODO: déchargement du driver

return 0;

}


IOCTL

// TODO: appel de l'IOCTL pour modifier le contenu du buffer

// TODO: affichage du buffer de sortie modifié


Libération des ressources

// TODO: libération des buffers

// TODO: déchargement du driver et fermeture de tous les handles driver

return 0;

}


Génération de l’application


Exécution de l’application

• Télécharger dans la cible l’image du noyau avec le driver STR_DRV

• Lancer l’application

Target→Run Program→STR_APP


Début de l’exécution


Exécution


Messages dans la fenêtre se sortie


Adresses avant et après remapping

PTR_APP: InBuffer avant remapping:30050

PTR_APP: OutBuffer avant remapping:30260

PTR_DRV: InBuffer après remapping:12030050

PTR_DRV: OutBuffer après remapping:12030260


Target→Ce Processes


Conclusion

• Première approche de l’organisation mémoire• Exemple pratique de communication d’adresses

créées dynamiquement dans le slot 0 à un driver

Documents

Jc/md/lp-01/05Gestion mémoire : présentation1 Gestion mémoire Présentation